Slashdot Mirror
GCC 3.0 Released
Phil Edwards, GCC Developer wrote in
to say: "The first major release of the GNU Compiler
Collection in nine years,
GCC 3.0,
is finished. There is a long list of
new features,
including a new x86 back-end, a new C++ library, and a new C++ ABI,
to pick my three favorites.
Note that the GCC project does not distribute
binary packages,
only source. And right now the server is heavily loaded, so if you
intend to get the source tarball, please /. one of the many
ftp mirror sites
instead. Plans for 2.95.4 (bugfix release), 3.0.1 (bugfix release), and 3.1
(more user-visible features) are all in progress." MartinG points to this mailing list message announcing the upload.
Be realistic... Any new major release, particularly something as complex as GCC, is -bound- to have a few bugs in it. There are only so many possible situations you can test something like this in before you call it 'good enough'.
Fortunately GCC handles having multiple versions installed simultaniously rather well, so you can have 3.0 installed to take advantage of all the new features, AND have 2.9x (your pick..) installed for kernels, system tools, and anything that absolutely must work right.
Their "New Features" page hasnt mentioned Alpha at all. Same stuff from 2.95.x ? Hopefully they just missed to mention it. Since the Gnu stuff does not compile cleanly with ccc and ccc is not available as source (make world with a binary-exception would suck, anyway), this would be a catasrthroy (as 2.95.x was on Alpha) ? Anyone Infos ?
...because I'm still using Red Hat 6.0 with GNOME and Enlightenment and emacs 20.3.1 with the recommended patches.
So I'm using the very best of 1999. So what? Everything works and it runs the Linux version of Alien Crossfire, so what else do I need?
People upgrade way too often. Staying several versions behind ensures reliability.
I'll probably upgrade to Red Hat 8.1 sometime in 2003, depending on what I'll need to run by then.
"please /. one of the many ftp mirror sites instead."
This ISN'T the kind of statement you want to make, now you have proof of a planned DDoS.
Go to the gcc 3.0 page at gcc.gnu.org for links to benchmarks.
It's not just KDE. A lot of GNOME programs contain C++ too, as does NS 4, Mozilla, the BB window manager, and many others. This isn't going to be nearly as bad as the glibc transition, but I do think it's going to be enough of a headache to warrant a clean install.
Just fine. I built it with a 3.0 snapshot last week. POOMA also gives your compiler a good workout.
I have been using Code Sourcery's GCC snapshots for a few weeks now. GDB has been working 100% for C++ code. In fact, it works incredibly well. We ported a Win32 app to Linux just so we could avoid the awful C++ support in MSVCs debugger (if I ever see that warning about a symbol truncated to 255 characters again, I'm going to punch someone; thank god for #pragma warning(disable:4786)). As a bonus, when you inspect a std::string with GDB you see the string as opposed to the MSVC debugger where you see a bunch of gibberish.
Realy? was'nt GCC 2.8 merged with EGCS into the GCC 2.95 series?
Yes. See the changelogs.
My guess is they are focussing on features and compatibility and being free as in beer and speech rather than heavily optimizing code and processes at this time. On the other hand good programming practices which they seem to be embracing are steadily bringing preformance increases. Sure it may not be up to MSVC in speed but you can bet that given enough time and versions it will.
Since you seem to have a technical inclination you might want to look at the source and see for yourself. Even a grep/diff between the present and last two versions may prove enlightening.
pingmeep
Try turning off optimization on files like that. Every C++ compiler I've used on UNIX systems is painfully slow at optimizing template code.
On the other hand, support for templates in MSVC++ is notoriously poor. For one thing, the MS compiler & linker don't support automatic template instantiation. You may not have noticed this because the IDE does the bookeeping for you and generates the template declarations needed by the compiler. For some reason, most compilers are faster when you turn of automatic instantiation and explicitly list the template instances you need.
Also, perhaps the MS compiler isn't performing some of the same optimizations on template code.
GCC, as most other compilers, bootstraps itself, that is, a small assembler program compiles a subset of the language in which a compiler for the whole language is then implemented (xgcc).
No, it doesn't. That would be grossly nonportable. It uses your existing C compiler to compile itself, without optimization, and then compiles itself with that (to get the benefit of its optimizations &c); then it recompiles itself with *that* and compares the last two. If you don't have a C compiler, you can't build GCC (equally, if you don't have an Ada compiler, you can't build GNAT).
hello world
0.01user 0.00system 0:00.00elapsed 142%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (52major+9minor)pagefaults 0swaps
3.0:
hello world
0.01user 0.00system 0:00.00elapsed 125%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (31major+11minor)pagefaults 0swaps
GJC is indeed cool, and it had the name before GCJ. Watch those acronyms. :)
BTW, gcj and gjc work together. :)
Well, it seems like all the upcoming Linux distributions are going to .0 now (Redhat 8.0, Mandrake 9!, SuSE 8.0) - as all the stuff are not backward compatible with 2.X (gcc 2.96 is also not compatible with 3.x nor 2.x)
Has anyone done any performance tests? some benchmarks maybe? it would be really interesting to see this GCC against the upcoming commercial Intel C/C++ compiler..
Hetz (Heunique)
You're telling me. About 3 years ago I wrote C++ code and wanted to use the standard stringstream class. But all they had was strstream, a rather buggy knock-off of it.
Now, stringstream still isn't in the standard library in Red Hat 7.1! One can only say that it's taken too long.
---
Right. This is the "control file" method I mentioned. IIRC, Cfront didn't implement this in a completely automatic way, though compilers that use this model have cleaned it up.
The overhead is not only in the bookeeping. The overhead is also in generating the instantiations. To do this the compiler has to re-parse the source and generate code (either by recompiling the entire object file all over again or placing just the generated template code in a separate object). Some implementations could avoid this by generating some sort of targeted template code (a la DyC or other runtime compilers), but I don't know of any implementation that does this. It's tough to know which dominates. It probably depends on how "integrated" the prelinker is (i.e. does it rely on external programs to analyze object files?).
Whoops! Yes, of course you are correct. This is a different model from the prelinker method. It does have the drawback of generating the same code over and over again, though it only has to parse each source file once.
I seem to recall that collect2 is only used on ELF systems. How does instantiation work for other object types? I do recall, in the early days of EGCS, a repository (.rpo) notion that never quite worked for me. Has this been implemented correctly now? I didn't see much about how this all works in the 2.95.2 info files.
It could be parsing speed, but that seems unlikely. It probably depends on how the other compilers implement "recompilation." There's a large design space trading off complexity and speed. Then again, maybe the prelinker bookkeeping really is expensive. I haven't seen any good numbers.
This is an excellent point. The SGI STL is pretty braindead in terms of implementation. I'm very interested to see the fruits of Andrei Alexandrescu's YASTLI (Yet Another STL Implementation) project. His plan (documented on comp.lang.c++.moderated) is to implement the STL (hopefully all of the standard library eventually) using all of the modern design techniques (policies, traits, metaprogramming, typelists, etc.) to create a super-efficient version of the library. No compromises will be made for non-standard compilers, so it will be a good conformance test. g++ should do well in that regard.
For those interested, his book Modern C++ Design gives some clues on what he's thinking. It's an excellent read and I highly recommend it for anyone interested in some of the latest C++ design techniques, especially concerning templates.
--
I did try my hand at some metaprogramming which used a bit of partial specialization. I was using (I think) 2.90.blah and it failed miserably. But that compiler was so old and buggy I'm sure it would work much better now.
--
That is very nice. It will allow better separation of interface and implementation.
I'm curious as to why you say this. Is it the amount of inlined code or the fact that it's something akin to magic? :)
--
I figured as much. Recently there was a discussion on comp.std.c++ on the STL's map interface. While not directly related to your concerns, I did get into an argument with Bjarne over the amount of time/money spent in trying to understand the standard library when a few simple changes could make life much easier for the average programmer. His viewpoint is that one must keep up with the latest techniques. I agree to a point, but understand the realistic situation you've outlined above, where not all members of the team can afford to live on the bleeding edge.
IMHO one of the larger problems is the lack of adequate tools to analyze and debug C++ code. Using gdb is a nightmare with g++ and as you indicated, it is incredibly difficult to debug template metaprograms. At least some people (e.g. Jeremy Siek) are working on techiques to improve compiler error messages (concept checks)!
--
I'm greatly anticipating the new C++ library. Finally we will have stringstream! For me the C++ library was the largest hole in the C++ implementation. The compiler itself has been quite good for some time, feature-wise.
--
This is not a bad thing. In fact, it is a very valid (I'd say good!) design decision. Explanation below.
The reason explicit instantiation is so much faster is that the compiler doesn't have to compile your code twice. Automatic template instantiation requires some sort of support outside the compiler proper. For all the gory details, I recommend Stan Lippman's Inside the C++ Object Model. It's a little out of date and inaccurate (or more properly, misleading) at times, but for anyone interested in why C++ works the way it does and what sort of decisions the compiler makes when generating code, it's a great book. It dispels many of the common myths about C++'s performance and makes an honest evaluation of the cases where performance is negatively affected.
But I digress. One of the most popular strategies for automatic template instantiation involves some sort of "collector" program. The basic idea is to collect all the object files that go into the final link and look for undefined symbols that refer to template code. The GNU collect2 program does this for g++. Once the symbols have been identified, the compiler needs some way of knowing how to recompile the source files that contain the template elements. Strategies include using control files generated by the compiler and collector, entries in the object files themselves (strings or symbols are common) or a combination of the two. Other strategies are possible as well. The driver script (the IDE in VC++) gathers this information and reinvokes the compiler to recompile the source files containing the needed template code, passing flags to tell the compiler to instantiate particular templates.
After having implemented some of this, I have to tell you that it is all a tremendous pain in the neck. It's also quite, quite convenient and necessary for the user. :)
As for the MS IDE, that's just another strategy for handling the problem. No compiler that I know of fully handles automatic template instantiation by itself. The closest that a compiler could come to this would be to aggregate the collector actions into the compiler as a separate phase. This is really no different that running a separate program and the "compiler" becomes the driver script (think g++), with the compiler proper (i.e. translation and transformation) being but one (usually, more than one) phase of compilation.
Is this not true under Windows? I'm curious, as they should have many of the same problems. Optimizing template code is expensive because there is a lot of it and most of it is inlined. Inlining is not as trivial one might initially expect and it has large implications for transformation (optimization). Inlining usually greatly expands the size and scope of functions that are transformed. There are more nodes, more symbols and more analysis bookkeeping to handle. Many compiler algorithms have complexity of N^2 or worse (lots are NP-complete!) so things get dicey as code size expands. Strangely enough, this is also why transformation can speed up compilation -- it often removes nodes and symbols from the program!
--
- build just the C portion of GCC using the system compiler using no optimisations
- move the freshly built gcc aside (bins and object files) into
./stage1
- using the compiler in stage1, build all of the selected language portions of GCC, this time with optimisations.
- move this second compiler (bin and
.o) into ./stage2
- using the gcc in stage2, build a third copy of gcc, with the exact same optimisations.
- compare the third copy of gcc with that in stage2, if they differ, bail out
- build aditional libs (stdc++, iberty, etc)
- (if specified) install libs and the stage3 compiler
A slow, painful process (esp when doing porting work), but it ensures that GCC is at least good enough to build itself as the installed compiler is an exact copy of the compiler used to compile it.Bill - aka taniwha
--
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
There's a nifty preprocessor hack you can use to get around this problem in compilers that don't properly support the standard:
#define for if(0);else forThis causes the scope of the for control variable to be correct, without affecting other control flow semantics. The only practical disadvantage is your compiler may warn about the constant value in a conditional. And your sensibilities may be offended by using the preprocessor to redefine a keyword. :)
AFAIK, gcc requires a *K&R* C compiler, as documented in the first edition of The C Programming Language. It need not support function prototypes or the void type (I think).
On UNIX systems that do not natively support and include gcc, one uses the system's C compiler to generate xgcc, which is GNU C (but not compiled by GNU C). One then uses xgcc to generate a GNU-compiled gcc. I don't know why xgcc is not normally installed and used, but I assume that it would be an ease-of-debugging issue (and you can also debug gcc-optimized code, which most vendor compilers will not do).
HP-UX natively includes a K&R (non-ANSI) C compiler. It is almost useless, but it will successfully compile gcc. On most other commercial UNIX systems, if you lack a compiler, you must rely upon someone who has a compiler to generate a verstion of gcc for you (which accounts for the popularity of packaged gcc versions on many platforms). This can also be complicated by licensing of the system include files and libraries.
Defend RedHat all you want, but it still turns out they shipped what basically amounted to a development snapshot as their compiler, and also didn't indicate in any way (in the initial versions) that it was not an official GCC release, and left the help indicating that the GCC team should be contacted in the case of bugs. They shipped a compiler neither compatible with 2.95.x or 3.x - they released a compiler that is not binary compatible with any release of GCC, ever.
But at least the release of 7.0 convinced me to try out Debian. Unfortunately it also pissed off a lot of people who equated RedHat to Linux, and now will end up taking a long time to give Linux another chance.
What about the following, surely it's good ?
#pragma once
It's not good, and don't call me Shirley.
Seriously, though, the gcc approach to this is, I think, better, if rather more verbose and awkward-looking. As I understand it, gcc looks for include guards, code like
#ifndef _MYFILE_H
#define _MYFILE_H
...
#endif
and if it finds it, it treats that like #pragma once for the given file. So there's no incompatibility with compilers that don't support #pragma once. Meanwhile, if for some necessary evil you need to include MyFile.h again, simply #undef _MYFILE_H and go.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Actually, you can get by with jikes for dependency generation at least.
sigs are a waste of space
It is the only major C++ fature not yet implemented.
... but I'm not sure they implement it exactly like GCC.
I'd prefer them to swicth to 3.0 at the earliest possible location, though.
It also compiles with GCC, with a warning. The code used to be correct, but the standard commite changed the rules.
Which means you must compile your C++ applications with the same GCC version as your C++ libraries.
I believe GCC 2.8 was only fully merged back into EGCS in GCC 3.0.
Yes. That is the point of the "gcc 2.96 Red Hat fiasco". The C++ library and ABI has been changed in 3.0 in order to conform to the C++ standard, as well as new cross-compiler C++ ABI standard, and to be much more efficient. The problem with the Red Hat release was that it was released half-way through that process, so it would be both forward and backward incompatible with the official FSF releases.
In most other ways, the unofficial gcc 2.96 is an improvement over 2.95, and for C code compatibility is as good as between any two releases of gcc. Mostly GCC 2.96 catches a few bugs that 2.95 failed to notice.
Programs that uses iostreams will tend to be slower, because of the new (ISO mandated) template based iostream implementation. In particular, a "hello world" program will tend to compile much slower, since it spend most of its time in the header.
Other programs can compile much faster or much slower, depending on what the bottleneck used to be, and what features they excersize.
There are several implementations of precompiled headers for GCC, which are likely to give a large boost in compilation speed when one of them is selected for inclusion.
GCC is basically a new name for EGCS.
I don't know about PGCC, but since GCC 3.0 has a brand new ia32 backend with focus on Pentium II performance, chances are that PGCC is no longer relevant.
It may be great for GCC that RedHat provided them with a wide-scale test of their software, but what about users of RedHat who were stuck with a buggy version of GCC for months?
--
Good point. Since at some point the first GCC had to be cross-compiled or bootstrapped from a non-gcc, non-gpl, and therefore probably commercial/proprietary compiler, does that mean that all off gcc is non-gpl derived?
So, since the original gcc was non-gpl derived, then everything built with gcc, while it may be gpl derived, is truly non-gpl derived.
So, if you wanna build an application based on gpl code and not distribute it does that mean it's okay?
(Yes...for the GPL or death people, this is a joke)
"The code you posted is legal (modulo the missing signs). The only current compiler I know which doesn't think so is MSVC++ 6, which is so far from the C++ Standard as to be a joke. "
Really? Do you use MSVC 6 much?
The single biggest problem that I've had writing x-platform code from MSVC was the for loop decl-init. This was with code written under MSVC and then recompiled on the Mac under Code Warrior. The next biggest was the use of exception specifiers, which most people don't seem to use anyway (MSVC ignores then and doesn't abort when exceptions that don't fit the specifier are thrown). Finally a couple of minor issues such as a semi-colon after the closing brace of a namespace (CW doesn't like them, MSVC doesn't care), casting in this form: uiVarB = unsigned int(ulVarA) - (MSVC was happy, CW wasn't), and scoping (CW needed more explicit scoping in some places than MSVC).
Except for the for loop variable issue, it's pretty easy writing ANSI C++ in MSVC. Your programming skills are a joke if you can't do it. Every C++ compiler that I've used deviates from ANSI C++ at some point, and some more than others. In the grand scheme of things, MSVC isn't really that bad for compliance, and what is more, it appears that they are still working on improving it.
Wow: they're really going to fix that bug? They've known about it for several versions of MSVC (4, 5, 6), but seemed unwilling to change it. Fixing it will surely break a lot of code and presumably require a new compiler directive to build old code unmodified. This bug has been irritating me for a long time as I've been writing code that must also compile on the Mac, and every now and again I slip up and forget to declare a loop variable before the loop, and then try to use it after the loop.
I remember try to build the TAO (the ACE ORB) a few years ago. Under Linux using GCC, a couple of files consumed all of virtual memory (requiring 250MB of memory). When I had sufficient, it would take my 128MB machine 45 to 70 mins to compile those particular files (lots of swapping). The same files under Windows with MSVC would take less than 20MB and thus compile in under a minute. What is GCC doing that requires so much memory? Is it me, or is this new inliner (that is such an improvement) still a memory hungry hog? Why? (Technical answers preferred).
Does anyone know when support for the C++ "export" keyword is expected? Is someone working on this already?
There is no such thing as luck. Luck is nothing but an absence of bad luck.
int main(int argc, char *argv[])
:)
{
int ary[atoi(argv[1])][atoi(argv[1])];
return 0;
}
Convenient, no? Instead of doing a for loop and malloc()ing through it?
But completely uncompilable on any sane compiler.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
C++ really doesn't have much to do with it. gcc's C and C++ front-ends are kept separate and have been for some time.
C99 does allow declarations to be mixed with statements in any order. See section 6.8.2 of the standard.
> Nothing to do with it. Everything after stage1 is a consistency check.
Not quite. Assuming GCC generates faster/better code than the native compiler, installing GCC compiled by GCC will make compiling other program happen faster.
Thanks for pointing out the consistency check going on with stage 3. I hadn't known why it was useful to build gcc again with gcc.
#define X(x,y) x##y
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
--
Care about electronic freedom? Consider donating to the EFF!
The Irix C++ compiler has this problem as well, but worse than VC++ because it produced an error if you declared a variable more than once (apparently VC++ silently allows this, which is why I was not even aware it did the scoping wrong until I tested it explicitly). The Irix problem meant that two for loops with the same "local" index variable would not compile, and since we also had compilers that obeyed C++ rules we have to insert the "int" declaration before the first for loop. This also broke a macro that relied on a local variable.
Fortunately the switch "-LANG:ansi-for-init-scope=ON" turns it on (they seem to have figured out how to be even more verbose than gcc, sigh...) I just recently learned you turn this off (ie switch to C++ mode) with
The first thing you do when you've released something is work your ass off to get it right.
This isn't supposed to take 3 months like M$ sometimes seems to think it should.
The way programmers are pushed today the first x.0 is mostly more of a beta than a release.
Not a problem realy if you got more time at bugfixing but since the company that's behing them don't earn money unless it's out there we won't see a change before that changes.
// yendor
--
It could be coffe.... or it could just be some warm brown liquid containing lots of caffeen.
VC++ 5.0 and 6.0 shipped with an old iostream library (iostream.h etc, global namespace) and a mostly standard C++ library including iostreams. The standard C++ library was provided (indirectly) by Dinkumware. Due to a legal dispute between Dinkumware and the company in the middle, this wasn't updated in 6.0 and so was not updated to match the standard (in any case, the VC++ compiler could not support all library features). This should be fixed in VC++ 7.0 (currently in beta, AFAIK).
Using macros to redefine keywords generally results in undefined behaviour (standard paragraph 17.4.3.1.1.2), so one's sensibilities should be offended. As a compiler-specific workaround this macro definition is obviously a necessary evil, but it should never be included in code that is meant to be portable.
The VC++ debugger will certainly show the contents of a std::string if you use the supplied standard library. I'm not sure how you would expect it to support replacement libraries.
I agree that gcc isn't very fast. You can
try -pipe, a lower -O setting, multiple
CPUs, and so on to speed things up.
However, that is a pretty bad way to set up
a project anyway. It should be split into
more manageable, seperately compilable,
pieces.
-Kevin
at least they say ahead of time that they will be releasing a "bug fix" version. Not like other programs that don't release bug fix versions for years ;-)
Hey, the same thing happened in the C standard, where common vendor extensions were explicitly taken into account when ANSI drafted the C standard. Things such as using /**/ in a #define to splice tokens were never defined by K&R, but were available in some compilers. ANSI C deprecated this common practice in favor of the new, well-defined ## operator.
If Standards Committees did not take into account current common practice, that would surely be madness.
--Joe--
Program Intellivision!
Yes, the ABI is the Application Binary Interface. This describes various aspects of the run time environment, such as how functions call each other (eg. how to place arguments of various types in registers or on the stack, etc), how scalars and aggregates are laid out in memory, how OS and library calls are made, etc. It's essentially a description of how a given function interfaces to the rest of "the machine."
Make sense?
Basically, two object files that are compiled with the same ABI can be linked to each other without any real fuss. If they use different ABIs, they potentially won't agree on even the simplest of assumptions (including, potentially, even what sizeof(int) is).
--Joe--
Program Intellivision!
I tried and it worked mostly alright. *HOWEVER* when I try to mount a FAT32 partition, it oopses. Plus, when I attempt to shutdown or reboot, it hangs when trying to umount. Other than that, it seems to be OK. ;-)
The very reason GCC 3.0 is out now rather than in 2005 is precisely because RH "jumped the gun" and submitted hundreds of bugfix patches to GCC 3.0 in the process. Meanwhile Redhat's GCC 2.96-81 is less buggy in my experience than 2.95.2 and the new features are great.
gcc 3.0 should compile kernels with no problems. Was linux kernel compilation not one of the release criteria for gcc 3.0?
It's true that the newer compilers reject a lot of broken code. However, what do you think of his take on binary compatibility ? Are C++ developers really supposed to ship static binaries ? What if the code uses dl-modules ? I think he's trying too hard in his role as apologist. If he'd stick to debunking the complaints about non-standard code not compiling, I'd almost take that page seriously.
GJC was used by the GJ compiler (Generic Java) which is going into JDK 1.5.
Talking about which, Generics needs to get into GCJ too.
-- Weiqi Gao weiqigao@speakeasy.net
Yeah, but now when we fix code we'll have a reasonable expectation that the compiler feature that's complaining works (less guesswork as to whose bug it is).
No, his comments on that are quite straightforward. GCC has never been binary compatible with itself across versions before. Redhat 7.x isn't binary compatible with *anything* because it uses glibc 2.2. 2.95.2 doesn't support IA64, one of the supported architectures of Redhat. Only needing to support one compiler across all architectures is much simpler.
I believe that those reasons pretty much account for both his reasons why it doesn't matter and why Redhat went with the decisions.
kgcc was included because the kernel was broken, not GCC. You can even look it up in the kernel mailing lists. Linus considered gcc 2.96 a good way to start getting Linux ready for gcc 3.0. Neither the gcc developers nor the Linux developers could have made it a "policy" that redhat had to include kgcc. Redhat did it because they knew that the kernel wouldn't compile on gcc 2.96 and they had to include a compiler that would compile the kernel.
Futhermore, even the gcc guys have admitted that using gcc 2.96 (which was really the name of the development branch) spead up development because of the bugfixes that were generated.
Why don't we all complain about them including glibc 2.2 as well? I mean, that breaks binary compatibility with all the other distributions too.
Slashdot already talked about this. (Actually the link is stating that 3.0 is rumored to be released soon)
Does anyone know the status of the 64-bit gcc for Sparc Solaris?
We all know that there is no chance of finding / fixing all bugs prior to release. Assuming that all monumental showstoppers have been addressed there are likely a whack of unknown "unintended features" as well as a few known defects that is not yet fixed.
Stating upfront that "we know about these bugs and plan to fix them in 3.0.1" is really professional behaviour. And it gets the compiler ot to a broader group for use/test...
Red Hat did ship the older compiler also. They just gave it a different name. If you wanted, there wasn't any problem in using it. If you used the new one, you were getting ready for now.
(Well, actually for a few weeks from now. This is a *.0 release, so I'll give it a bit of time to settle out, and use 2.95x for now.)
Caution: Now approaching the (technological) singularity.
I think we've pushed this "anyone can grow up to be president" thing too far.
I'd say they're just being realistic. No matter how good your QA process, the chances of catching and squashing every single bug before release are minimal. The best you can realistically hope to do is catch all the real show stoppers. (Assuming that you actually do want to release the product at some point, that is)
:)
Having said that, this is the first time (that I can remember) that I've seen an officially-planned x.0.1 bugfix release announced at the same time
Cheers,
Tim
It's official. Most of you are morons.
Not much, hopefully.
The only major thing that can affect the binary packages is the new C++ ABI. But for plain C programs, there should be no big difference. Most of the Linux programs and libraries are written in C and should not be affected significantly. This could be a problem for Qt and KDE packages, though.
See also the list of caveats on the GCC web site.
-Raphaël
It has been discussed many times, and there are some experimental implementations.
Or is it really so difficult to correctly implement it?
It is not only difficult to correct implement it, it is also difficult to agree on what it should do. People say "precompiled headers" but what the hell does that mean? What do you compile header files into? Do you compile a single header file into some kind of "precompiled header object file" (doesn't save you that much but is easy to use) or do you use some kind of pre-project data base (saves you more but may be more difficult to use) or what?
Note also that GCC developers use Makefiles, while most commercial Windows developers use an integrated IDE. It is easier to do all kinds of performance tricks when everything is integrated in one big program that you control.
I know there are many people interested in the problem, and I believe some may actually be working on it. It just isn't that easy if you want something that isn't a kludge. My impression (un-verified) is that many of the existing compilers that support pre-compiled header files use various kludges that may be useful but not necessarily well-designed. A pre-compiled header file solution for GCC has to be something we can live with for many years.
We did consider the name GJC (back in '96 when the project was started), but for some reason I don't remember (I think it was trademark-related) we decided on GCJ.
I'm very glad to see GCJ in a mainstream GCC release, and hope it will finally get the attention I think it deserves.
I doubt it. There *is* no C99 compliant compiler... and since C and C++ standards almost always seem to contradict themselves in one or two spots, it's unlikely that there ever will be one.
And it's not such a bad thing - the face="" paramater to the font tag is invalid HTML. I guess the web in general should be red in the face?
--
Evan "And I'll invent *another* dozen specs *after* lunch!" E.
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
I didn't even get the compile of 2.4.5 to finish. Died pretty early on in kernel/timer.c
Good thing I didn't put it on our production server (no I didn't really consider it).
--
You've got it backwards. MS VC has it wrong too. the declaration of i in your example is scoped with the body of the for loop. 'i' does not exist after the closing brace of the for-loop.
This is per the ANSI/ISO C++ standard.
--jdp Maintainer of VisEmacs
My problem with gcc's C++ compiler has been that there is no workable compiler for it. Gdb just falls to pieces when you try to debug C++ code (it can't find symbols, it can't handle user-defined operator overloads, sometimes it gets mixed up and gives you the wrong values for variables, etc.) Is there an update to gdb to go with the new gcc that provides reasonable support for C++?
It could be. If I'm understanding it correctly, many common operations have to be performed at runtime anyway (i.e. checking type safety for downcasts, which is usually the case if you use the collection classes, or checking array boundaries, etc.). Please also consider that critical sections are already implemented natively by the Java environments you can find out there, and I doubt these are going to gain anything...
There probably will be a speedup because of optimizations (i.e. inlining, or loop unrolling optimized for the specific platform), but I'd be far more cautios before making enusiasthic statements like that.
yes. but will you want to *run* the kernel once
it has compiled ?
Having said that, this is the first time (that I can remember) that I've seen an officially-planned x.0.1 bugfix release announced at the same time :)
Hence the spooky part.
Argh! When will this bloody BSD-bashing-bot stop posting this drivel in the hopes someone will take it seriously?
-- Wodin
Does gcc support compiling for 64-bit Solaris yet?
Hmm.. then I wonder why they decided to define:
...) S
...) S
...) S}
:-(
for (int i = 0;
as:
int i; for (i = 0;
rather than:
{int i; for (i = 0;
Oh, well!
Damn, so C99 is OK, but I'm going insane...
gotta learn to read... gotta learn to read...
Yuk! Does C99 allow nested scopes at all...
{
int i;
{
int i;
Is this legal, or a redefinition?
Does 3.0 fully comply with the standards for templates, I think it's the 99 C++ standard ?
I had a quick look but the information didn't jump out at me and perhaps someone here knows, but perhaps I'm just being optimistic.
In the gcc-v3 distribution they've been working for many months.
Exactly. Now, step back and think about WHEN Red Hat 7.0 was released.... Red Hat made a hard decision. They had to release a 1.5-year old C++ compiler that did not track the standard or the latest version of C++ off of the 3.0 development snapshots. They did the latter because they felt it would serve more of their customers' interests, and they had the technical staff to back that decision up.
Then, they got burned from both sides. The folks who were writing non-standard C++ complained because their programs no longer compiled. The folks who were tracking the GCC development and the ANSI standard complained that it did not go far enough.
The kicker is that, had they been Sun, releasing ACC, people would have groned because their code broke, put a bunch of #ifdefs in their code (or modified their autoconfigs) and gone on with life. But, because we have a porthole into the development process, we feel we're qualified to second-guess the distribution-creation process. Personally, I'm impressed that Red Hat (or Debian or SuSe, etc) can package a distribution at all, given the huge number of projects and no real coordination between them.
--
Aaron Sherman (ajs@ajs.com)
This is just not true. GCC 2.95 and was horribly out of date with respect to the ANSI C++ standard. The problem was always that GCC was one of the first C++ compilers, and so it's been evolving along with the C++ language. So, one of the major thrusts in 3.0 (or rather, something so radical that it was not entering the 2.x series) was to incompatibly change much of the C++ implementation to match the ANSI C++ standard (hopefully this will freeze most major work on GCC's C++ so that people can start to rely on source-compatibility with future versions).
Red Hat's 2.96 was a pre-release of 3.0, which they released because they felt that their customers needed many of those features, and that back-fitting them to 2.95 would be too large a task for too little return to the GCC effort (which, recall Cygnus is a MAJOR participant in).
--
Aaron Sherman (ajs@ajs.com)
Of course, they will do what they've always done (and every other commercial vendor with large customers does). They will distribute "obsolete" software until their next version, when they will go with the almost-latest-and-greatest that they can get to work.
You have to understand, Red Hat bowed to their customers. Many of their C++ customers told them they needed ANSI C++ compliance badly. GCC 2.96 offered that.
Red Hat has a history of working hard on the compiler, and distributing a custom version. They were the first distribution to ship egcs (remember, 6.2 ran egcs for the C++ compiler). They also did a lot of work on making egcs work for the Linux kernel.
--
Aaron Sherman (ajs@ajs.com)
Can some one please enlighten me about those 3 variations and their status? I assume EGCS and PGCC are integrated into GCC 3.0?
Is that right?
LInuxLover
without any conflicts or not having my system hosed.
Anybody knows how to fix it?
- german
For those of you who prefer a non-hacker announcement of the release, a press release is available.
binutils 2.11, the latest version, and prior releases are *incompatible* against gcc 3.0.
Wait until binutils 2.11.1 is released either tonight or tomorrow. Install that, then compile gcc.
Compile Mozilla from CVS with gcc 3.0 and you'll notice how amazingly fast it is!
Cheers,
Ghadi Shayban
Which is why I always code these sort of loops as:
...
...
Just to avoid problems on either compiler.int i;
for (i = 0; i < x; i++) {
}
for (i = 0; i < x2; i++) {
}
Just to avoid problems on either compiler.
Fear: When you see B8 00 4C CD 21 and know what it means
the scope of anything in C is defined inside the {} set or the semi-implied {...} that contains the whole program. Some early C compilers would gernate a new frame with every {. some embeded compilers still do.
So the int i should be in the outside scope.
But...
for(a;b;c) {x;};
is the same as:
a;
while(b) {x; c;}
so the int i should be in the inside scope.
does that clear it up in an unambiguous way?
I'm glad you see it my way (what ever that is)
Female Prison Rape in NY
My purely speculative guess is that there should even be speed up in non-natively compiled code (code *you* write), because the entire core API can be natively compiled, as opposed to being in Java itself (as Sun's is). This would mean you wouldn't break WORA, but once you flip the native toggle on the GCJ runtime, you should see vast improvements in speed.
It's 10 PM. Do you know if you're un-American?
" I've written in clean, attractive Java code (to do stuff like rename files"
er you wrote a Java program to rename files?
The best think about Java for Linux developers
is that we can get access to programs that
previously would have been only been Windows binaries.
GJC does not help that at all. I for one won't
be using it, the JDKs are faster enough for me
and I do more than rename files!
Is it safe to compile the Linux kernel with GCC 3.0 ?
{{.sig}}
There are some patches and plans for this, but they were put on hold until 3.1.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
My girlfriend just asked me this question. Here was my answer:
An ABI for a platform/language/environment combination specifies things like the byte sex, the location of certain global variables (global offset pointers, etc), which registers are used for passing parameters during a function call, whether it's the calling function or the "callee" function that saves and restores register contents during function calls (and which registers can be ignored), the order of parameters passed on the stack... basically all the things that have to be agreed upon at the bitwise level in order for you to use Compiler A to make foo.o, and me to use Compiler B to make bar.o, and then to be able to link foo.o and bar.o together successfully. Usually for C++ everything all had to be done with the same compiler because there wasn't an ABI that everyone could agree on. Now various vendors can use various compilers and this stuff will "just work" on IA-64 families.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
So how did they compile the first version of the GCC compiler? Seeing is that there was no prior GCC compiler first?
Ever heard about compat-* package ?
Does Jikes do array bounds checking by default? If not, then there's not really much difference.
------
They, and anyone choosing to use Redhat, have only themselves to blame if there are problems.
And it is the policy of the gcc developers, isn't it, and the developers of the linux kernel itself that Red Hat had to also supply their "kgcc" secondary system-space compiler for?
Or is there someone out there who thinks the people are obligated to support the "gcc-2.96-REDHAT" stuff?
That's what I said.
Or if Red Hat users will now be forced to continue to use what has become obsolete software?
How does the new x86 backend generated code perform in relation to previous compilers. I know icl (Intel C compiler) is coming out for Linux, and from the demoes of it I've used on Windows, it looks pretty damn spiff. (Stupid 30 limit...) Compile speed is fast too. If you look at the icl docs, you'll find that the optimizer on this thing is insane, it does all sorts of inter-intra function optimizations and prepiplines code and everything. I have only a vague understanding of what the hell that means, but it sure SOUNDS fast. Anyway, I'll try out the Windows version and see how it performs in relation to gcc. I'll post benchmarks when I get the chance. I'd appreciate it if someone would post Linux benchmarks as well, because as much as I like Windows, I can barely stand not having bash. (Ah... BeOS, where art thou?)
A deep unwavering belief is a sure sign you're missing something...
Comment removed based on user account deletion
Guess what? Everyone that complained about GCC 2.96 being broken (and not reading http://www.bero.org/gcc296.html) despite the fact that their code wasn't C99 complient STILL WON'T COMPILE. Now you can't complain that your code won't work because it's a developmental compiler, you'll actually have to fix it. Numerous examples of this are listed at the above URL, I'd highly suggest you try it out. I have a feeling quite a few people are gonna be red in the face over this one. ;-)
Interested in open source engine management for your Subaru?
AFAIK, gcc requires a *K&R* C compiler, as documented in the first edition of The C Programming Language. It need not support function prototypes or the void type (I think).
No, it does not require such a compiler; it is required to be bootstrappable with such a compiler.
And K&R did have void. They didn't have pointer to void.
On UNIX systems that do not natively support and include gcc, one uses the system's C compiler to generate xgcc, which is GNU C (but not compiled by GNU C).
Not really. xgcc is the name of the result of the stage1 and stage2 bootstraps; the stage2 one is created by the stage1 one (i.e. by GCC).
I don't know why xgcc is not normally installed and used
It effectively is, if you type "make install". The bootstrap process just ensures that the result of the stage3 bootstrap has identical object files as the result of the stage2 bootstrap, which formed xgcc. In other words,
that optimized GCC compiles itself into the same optimized GCC - a consistency check. Those binaries are what get installed, so it is effectively the same GCC.
but I assume that it would be an ease-of-debugging issue (and you can also debug gcc-optimized code, which most vendor compilers will not do).
Nothing to do with it. Everything after stage1 is a consistency check.
C99 standard. Overview.The Honorable Dennis Ritchie (father of C) on C99
Someone you trust is one of us.
From my lazy and half hearted poking around GCC's web page I didn't find information on ABI let alone why it is important to put in the compiler/compiled binaries. So what is ABI and why should people using the 3.0 compiler care?
The fact that RedHat used an earlier snapshot of this compiler allowed for extensive testing early in the development process, resulting in many bug-fixes being made to the snapshot as well as to the pre-3.0 GCC development code.
I'm sure this release came about sooner with a lot less bugs due to Redhat's move to use the earlier snapshot in their distro.
-Karl
So assuming that you don't have a built compiler (and thus require GCC)... what do you do? This is the only thing that I can understand needing binaries for, and it there isn't any. This don't make sense to me.
Better to stay silent, and let people think you're an idiot than to open your mouth and remove all doubt
I believe it does. Jikes (which I haven't used for about a year) was a quite amazing piece of code. The compiler itself was blazingly fast, and gave excellent error messages.
To my surprise, the Jikes version ran much faster, about 2X, than the native code. Only when I recompiled with GCJ with the option to skip array-bounds-checking, did the native version run at about the same speed as Jikes.
It was a snapshot, which was then QAed and patched selectively for some time before release - it was better than any other alternative at the time, as the compiler we shipped before was rather old, and 2.95.x was buggy. We also got support for IA64, so we didn't have to use lots of different compiler for different architectures.
The only thing wrong about what happened, was that we didn't properly communicate that this was a Red Hat, not an FSF, release. Other than that, it showed the power of free software by allowing us to do what we felt was needed and not being locked in- nothing wrong about that. It has served us well for two releases now - in the future, we will eventually move to gcc 3.0(.x?), but this was obviously not an available compiler back then.
PS: Since our initial release, Mandrake has done the switch as well.
It's a C++ compiler and all that's released is C++ source.
So how the hell are you supposed to use it? Of course, most of us just happen to have binaries of a previous version but still...
The C++ standard specifies that the for scope ends at the end of the for loop. The only compiler I know of that gets this wrong is Visual C++. That is a bug with Visual C++ and will be fixed in 7.0 AFAIK.
This post lists the non-compliance issues that VC7 will ship with. The for-loop scoping problem isn't there.
Normally, I'll snag most anything off the server to live on the bleeding edge, but not this time...
--
Actually, MSVC has a command line switch that turns on the correct behaviour (that i goes out of scope at the end of the loop). It's just that if you turn it on it can't compile it's own headers, so it's somewhat useless...
#pragma is evil.
The C Programming language was originally standardised in 1989, and this was known as C89 (and also as C90 - long story...) In 1999, the C language was updated with some new features and library functions. This is now known as C99.
#pragma is evil - anything after the #pragma is implementation defined. This means that #pragma blah on one compiler might do one thing and something else entirely on another. You can't conditionally use it per compiler since it's at the pre-processor level. (You can't #ifdef out #endif, for example.) _Pragma is nicer, however, as you can do: #if <test for GCC> #define BLAH _Pragma whatever #elif <test for other compiler supporting such enlightenment> #define BLAH whatever #endif BLAH Unfortunately I don't know of any other compilers that realise this, so you're sort of stuffed. Most of them allow #pragmas to be ifdef'd out which is nearly as good.
a) printf statements and I/O inside loops in a performance benchmark? hello, McFly... you aren't really testing the compiler there.
b) gcc only as source??? (see your installation media for any free unix to get binaries, cygwin for win32, etc. etc. GNU may only distribute source but other folks can and do distribute binaries, and I'm sure gcc 3.0 binaries will be released for your platform of choice Real Soon Now)
c) FP perf: what do those numbers mean? There is no explanation given of how they're arrived at or what scale they're on. "Naked numbers unlike naked ladies aren't terribly interesting."
d) Ease of Use/Installation: Totally subjective and totally irrelevant to the merits of the compiler. Just because a preteen could install VC++ doesn't make it's code any better.
e) "overhyped","not ready" gcc: ok, so you're a troll. Just try not to be flaming stupid while you're at it. If it isn't ready then why is the operating system I'm using to type this reply on built with it? Is gcc the best compiler ever, well, no, there's no such thing. Frankly I wish gcc supported something more recent in the fortran family than F77 (not that I like Fortran per se but as a scientific coder it's sort of common and stuff).
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX
What is Google?
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
No matter how good your QA process, the chances of catching and squashing every single bug before release are minimal
Unless you're Microsoft; then you're an incompetent, obnoxious, FUD-spouting dinosaur and every bug that escapes is an indictment of you, your business practices, design methodology, family heritage, preference for breakfast cereal, haircut and anything else associtated with you or anyone you have ever met, slept with, laid eyes upon, or casually passed on the street.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Did they manage to speed up g++ at all? In the prerelease versions, I was seeing compilation times that would put g++ 3.0 at about 2-3 times slower than 2.95.2. And 2.95.2 was significantly slower than any egcs version. Anyone know if there are plans to address this?
Certain compilers, including previous releases of GCC and Metrowerks Codewarrior allowed the following:
//scope of int i ends here so....
//...redeclaring int i doesn't blow up
for (int i = 0; i x; i++)
{
[....]
}
for (int i = 0; i y; i++)
{
[....]
}
Does GCC 3.0 still allow this?
The above code 'feature' is not allowed under the ANSI C++. Under ANSI C++, the int i variable scope will continue beyond the for loop. IMHO the ANSI standard does not make sense WRT this issue. This is commonly thought to be a bug in the ANSI C++ spec (or so I am led to believe).
I do not know about C++ 98/99/whatever standard. Any URLs anyone?
"GNU TOOLS FOR LINUX: BECAUSE LINUX USERS HAVE A RIGHT TO CLEAN, ATTRACTIVE, EFFICIENT OBJECT ORIENTED CODE, TOO."
First GCJ is not for Linux only. Second compiling Java to native machine code does not guarantee performance improvements, and memory consumption could be even worse than for a JVM (I tried a famous object to native code compiler on NT, the memory consumption was at least twice as much for an application compared to just JVM).
Just like with any language Java code is not always clean and attractive. Java does not guarantee clean and attractive code. Nor does any other programming language.
<FLAME> And since when do object oriented and efficiency go together? Just look at Mozilla or KDE for example. Bloat, bloat, bloat. </FLAME>
Kuro5hin ran a story on this.
-Dave
The code you posted is legal (modulo the missing signs). The only current compiler I know which doesn't think so is MSVC++ 6, which is so far from the C++ Standard as to be a joke.
Why you think there's a problem with the Standard is a mystery to me. It's well-defined, and has been for years. There's no controversy.
g++ has a feature which allows broken code which assumes the old rules (extended scope) to work with a warning, but it always prefers the new, Standard rules.
It's the last of the Standard features to fall. Comeau C++ is allegedly close, predicting that their compiler will support export before the end of the year, but I haven't heard anything on the gcc developer's mailing list about g++ supporting export anytime soon.
see Options Controlling C++ dialect in the manual.
The gcc 2.96 stuff was a RedHat-only f.u.b.a.r. mess. They took a development snapshot, called it 2.96 and released it to an unsuspecting public. Don't blame the gcc folks for RedHats probably very unwise decision.
Why would a groups plans to fix a .0 release spook anyone? Who do you know that released a .0 verison of something and didn't have bugs?
Why do I keep typing pythong?
"...or get attacked by a pack of rabid dogs just because you're using an older version of gcc."
Rats. There goes my idea for one HELL of a denial-of-service.
Honorary Member of Jackie Chan's Kung Fu Process Servers
gcc...yum
---
Does the new C++ ABI affect solaris? Will my KDE/etc. stop working if I update from 2.95.3 to 3.0?
that's kewl that there's an hc11 and hc12 port now, since those are some nice little microcontrollers... i wonder how easy/hard it would be to port it to other hc## chips, anyone know? i mean would it be just a matter of using the hc11 or 12 port as a template and swapping a few opcode names & values and recompiling? (since i've never gone as far as constructing a full fledged compiler, just some simpler parsers).
I see language changes (Java integrated, Fortran improvements), but I kind of miss the years old Gnu Pascal project?
The Chill compiler is not included in GCC 3.0, because of the lack of a volunteer to convert it to use garbage collection.
As in, "Chill, to the next episode/version"
Check out Althea for a stable IMAP email client for X. Now with SSL!
This is Java 1.0 at its worst -- this is not some magic box (yet) that takes your Java 1.3 app and makes it native.
...
:^D
... before
getting too excited! ;^)
Here are some quotes from the gcj FAQ, just for context.
> What Java API's are supported? How complete is the support?
>
> Matt Welsh writes:
> Just look in the 'libjava' directory of libgcj
and see what classes are there.
> Most GUI stuff isn't there yet, that's true, but many of the other classes are easy to add if they don't yet exist.
> Considering that AWT support isnt here yet there is no chance of getting Swing running.
> Once we have AWT support the Swing 1.1.1 may be useable and even redistributable,
> but JFC will be another issue...
This quote means that we're talking Java 1.0. Don't bother asking about Java3D yet!
> GCJ supports all Java language constructs as per the Java language
> Specification v1.0. Recent GCJ snapshots have added support for
> most JDK1.1 language features, including inner classes.
(bold mine, natch)
Looks like "faceless" apps should compile, but don't expect much else.
So check out... gcj FAQ
the gcj site
For more info on AWT and gcj, check out the peerlib work. Not much has happened in a while from the looks of it.
So gcj might be integrated with gcc, but as any two-bit Java programmer like myself can tell you, this ain't my Java. This is several generations behind any other platform. You'd be writing code for the absolute lowest denominator, using deprecated methods in today's Java world. You'd nearly be teaching yourself COBOL, if I can put an exaggerated spin on it. No GUI, no XML API, no Collections, no...
Ruffin Bailey
It's all 0s and 1s. Or it's not.
> #pragma is evil - anything after ....
What about the following, surely it's good ?
#pragma once
This time with an official release of GCC, not the broken development release they used in RH 7.0...
--
What ? Me, worry ?
Actually what is happening is that as the tools we create and use become more and more sophisticated (and thus more lines of code in use), the harder it becomes to catch all the possible things that could go wrong in an application. With big projects like the Linux Kernel, GCC, Mozilla (now in beta), KDE, Gnome, XFree86- it is just realistic to assume that even though the developers worked very hard for a stable release, people will find bugs.
I miss the Karma Whores.
This being the first "major" release of the gcc in years, the big question is "how much stuff is this going to break?" Are we going to have a repeat of the gcc-2.96-REDHAT fiasco? I can see it now: "Sorry, this package compiled with gcc-3.x, you appear to have a 2.95 based system, please upgrade." Or the other way around. Download a source tarball and see "this code written specifically for gcc-3.x. You need at least that version to compile."
Actually, your example is how it should be. It's not a bug in ANSI/ISO C++, and C99 adopted that behavior too. My guess is you're comparing it to MSVC6, which incorrectly allows the scope of i to be extant outside of the for block.
I use a lot of JAVA, and it looks like we will finally have a full JAVA front-end for gcc with dependency generation (for automatic makefiles).
... the chicken or the egg. I egged the chicken and then I ate his leg." Beastie Boys - Pauls Boutique - Eggman
Sorry for the high geek quotient in the previous message, I think the five cups of coffee injested since the news of GJC have kind of warped my perception of, well, anything. In my zeal, I forgot to paste a link to this HELL LEET COOL BITCHIN SWEET ASS new GNU tool...http://gcc.gnu.org/java/.
GNU & JAVA: The Network is the OS.
Hey freaks: now you're ju
I was referring to MY code...it's efficient and object oriented, and now I can give it to you Linux chaps as well. Consider yourselves lucky.
This ego trip brought to you by a succesful compilation of the new GCC under Mac OSX.
Hey freaks: now you're ju
GNU JAVA COMPILER!
I can finally write in Java and not get made fun of by my elite C++ hax0r friends!
In case you weren't aware, GCJ is the first Gnu toolset for Java, and it's not just a nasty rehash of Sun's stuff...it's JRE, JIT and NATIVE CODE COMPILER rolled into one. They have an odious refutation of the Write Once Run Anywhere creedo which I don't necessarily agree with (the guy must be writing some pretty fierce code if he's had problems like he mentions, I've done distributed Java with the Swing libraries for about a year and never had a problem that wasn't related to Netscape sucking). What I care about, though, is the speed ups. Finally, all my keen little utility programs I've written in clean, attractive Java code (to do stuff like rename files, play music and so on) will run as fast as OS level stuff. I intend on compiling the sweet ass netbeans ide as soon as they get AWT working. Maybe I'll finally be able to get it to run as fast on my shitty Celeron windows machine as it does on my MACOS lappy.
GNU TOOLS FOR LINUX: BECAUSE LINUX USERS HAVE A RIGHT TO CLEAN, ATTRACTIVE, EFFICIENT OBJECT ORIENTED CODE, TOO.
Hey freaks: now you're ju
It's been a while since I've used GCC, does anyone know if it has inline assembly support for SSE and SSE2 on the intel side?
===> An eye for an eye makes everyone blind - MG
What is the C99 standard?
So with a new ia32 back end concentrating on Pentium II performance, has anyone done any benchmarks to see what kind of improvement we can get from nothing more than a recompile?
Hallelujah! Praise the Lord! Woohoo!
The only C++ standard is the one from 1998, ISO/IEC 14882:1998(E). The next major revision of the standard, not due for a couple of years yet but now under discussion, is currently known as C++0x.
According to the existing standard, the for-loop scoping you showed is standard. In the following code, the variable i is in scope throughout the for-loop, but no further.
for (int i = 0; i < 10; ++i) {
std::cout << i;
}
The fact that MS haven't bothered to fix this most basic piece of functionality in their compiler by default doesn't mean that it's not standard, it just means that MS's compiler isn't standard-compliant by default. There's actually a switch you can set at the command line to change this, but of course it will break MFC, so few people who use VC++ actually use it...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
So when's Mandrake going to incorporate this into their distribution?
With Mandrake 8.0 problems with Adaptec SCSI Controllers, I'll be staying with 7.2 until they get it fixed up and hopefully include this new compiler..
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com