GCC 4.0 Preview 684
Reducer2001 writes "News.com is running a story previewing GCC 4.0. A quote from the article says, '(included will be) technology to compile programs written in Fortran 95, an updated version of a decades-old programming language still popular for scientific and technical tasks, Henderson said. And software written in the C++ programming language should run faster--"shockingly better" in a few cases.'"
OpenMP? (Score:3, Interesting)
I just want C++ programs to COMPILE faster (Score:4, Interesting)
boost, please ? (Score:4, Interesting)
Re:I just want C++ programs to COMPILE faster (Score:3, Interesting)
Demo (Score:2, Interesting)
Fortran??? (Score:2, Interesting)
Re:and how many times... (Score:2, Interesting)
You can still run software from 1981 on windows XP.
Take a look for yourselves (those in Windows) here [bricklin.com]
Yeah, something that article does not bring up... (Score:4, Interesting)
Paul B.
Not much. (Score:5, Interesting)
"gcc" will switch languages based on the filename extension. Many people compile C++ by calling "gcc".
"g++" suppresses that bit of logic and forces the language to be C++, which is useful if you have some C code that you want to be built as C++, or if you're feeding the C++ source from stdin (hence, no filename extension).
Linking C++, though, you want to use g++ instead of gcc, unless you really know what you're doing. The "gcc" driver doesn't know which libraries to pull in -- yes, this is something we'd like to change someday -- and the "g++" driver will correctly pull in libstdc++, libm, etc, etc, in the correct order for your linker and your system.
(Hands up, everybody who remembers when "g++" was a shell script!)
Re:and how many times... (Score:3, Interesting)
Can you run C++ applications compiled on Solaris 2 on any later version?
Compatibility is where Sun rocks, and it's also the rock that Sun is tied to. Most of the things that people hate about Solaris are kept that way because of their commitment to backwards compatibility. It becomes difficult to make signifigant changes if you focus on compatibility the way they do.
Linux and other OSS tools like GCC have advanced quickly partly because they have always been able to rewrite just about anything if they need to. Historically people were used to it, or okay with it. I wouldn't be suprised if at some point Red Hat and other Enterprise vendors forked a stable-ABI version of GCC, glibc, and Linux, because in larger environments backwards compatibility is very important.
Re:C++ compiler (Score:5, Interesting)
Re:and how many times... (Score:3, Interesting)
Now that the C++ ABI is standardized, there is NO excuse for not having backwards- and forwards- compatibility for ordinary C and C++ executables linked against glibc.
The Linux kernel v2 ABI has been mostly backwards- and forwards-compatible since its first release. And Linux kernel guts change a lot more often than the C/C++ standards!
Re:Autovectorization (Score:2, Interesting)
Re:Mudflap (Score:4, Interesting)
I'll agree with you on this much: C+Mudflap is not the way to fix buffer overrun problems. The problem isn't that runtime safety is costly--it isn't--the problem is that adding runtime safety to the C programming language post hoc is costly because of C's screwed up pointer semantics. That's why Mudflap costs you a factor of 3-5 in terms of performance on benchmarks, when runtime safety in another language really should only cost you a few percent overhead at most.
Mudflap will probably not be used much for testing (people already have good tools for that they don't use) and it has too much overhead for most production use. The biggest thing Mudflap will do is perpetuate the myth that runtime safety is costly.
Timeline? (Score:2, Interesting)
3 monts? 6 months? a year ? forever?
Re:PathScale... looks interesting... (Score:2, Interesting)
This is a troll, right? (Score:5, Interesting)
You've got to be fucking kidding me.
Have a look at the mailing list anytime somebody reports a bug, and the choice is between fixing the bug and changing the ABI. Watch the flamefests erupt.
(Watch them die down a few days later as one of the brilliant core maintainers manages to do both, with a command-line option to toggle between the default fixed version and the buggy old version.)
Wait a few months. See a new corner-case weird bug some in. Lather, rinse, repeat.
Such as...?
All the ones I can think of were GCC extensions long before they were officially added to the languages. In fact, their presence in GCC actually influences their presence in an official language standard, because that's what the standards bodies do: standardize existing practice.
The troublesome part is when the syntax as added to the language standard differs from the extension that was originally put in GCC. Then we have to choose which once to support -- because supporting both is often not feasible -- knowing that whatever choice we make, slashdot is going to whinge about it. :-)
Included with Tiger. (Score:2, Interesting)
Major Features Dropped From GCC 4.0 (Score:5, Interesting)
- LLVM. Low Level Virtual Machine. This is a low level and generic pseudo code generator and virtual machine.
http://llvm.cs.uiuc.edu/ [uiuc.edu]
This sounded fabulous, and the project appears to be progressing well (it's at v1.4 now). If I understand correctly it is only politics that has kept it out of GCC 4. Can anyone shed more light on this?
- Compiler Server. Rather than invoking GCC for each TU you would run the GCC-Server once for the whole app and then feed it the TU's. This would make the compile process much faster and allow for whole program optimization.
This would have been nice but perhaps they found better ways to achieve the same thing.
Yes, it's true (Score:5, Interesting)
It gets even more devistating on Fortran. Seems Intel has like the only good Fortran compiler in the world. That's part of the reason their chips do so well on SPEC, the FP part is all fortran code and their compiler just rules at it.
If you Google around for compiler benchmarks you'll find a number of them, and virtually all show the Intel compiler dominating. One of the best, which I can't find a link for right now, was a test done by Toms Hardware. They did MPEG-4 encoding with the P4 and found that it blew. Intel figured something was wrong, got the source and recompiled the program (was compiled with VC++ 6.0). The P4 almost quadrupled in speed (and got even faster with the SSE optimised modes they added), and even the Athlons showed a near doubling in speed.
Re:Nitpicking (Score:5, Interesting)
No idea about MSVC, it doesn't build very good Linux binaries though anyways.
Re:This is a troll, right? (Score:3, Interesting)
For inline assembly code, non-Lvalue parameters can no longer be given an "m" contraint. It used to be possible to have a parameter like (x+1) and use the most general contraint "m", register or memory. This way gcc could leave x+1 in a register, or spill it onto the stack if it ran out of registers.
In gcc 4 you have to define a variable to hold x+1 and gcc is forced to write the value into memory, even if it could be left in a register.
Re:C++ compiler (Score:4, Interesting)
But will it compile C++ any faster?
I don't care if it compiles any faster, just as long as it compiles correctly. We were in the middle of a port of a major system to Linux recently, and the sysadmins decided we really need to install some patches. I shoulda' known better. I shoulda' said no.
They applied the Red Hat AS patches (which included patches to gcc) on the target machine, and suddenly newly compiled programs that had been working for years had memory overwrite problems. Strings and char arrays would contain things that should be in adjacent memory. The most obvious difference was the newly compiled code was much smaller than that produced by the unpatched gcc.
Luckily, we had another Red Hat AS machine which had not been patched, and I moved all the development work there. Then I promised the admins that I'd go postal if they touched gcc on that box. So far, so good, but I'd really appreciate it if the gcc guys would get it right before releasing stuff. One of the promised results of the above mentioned patch was a significant reduction in size. They got that part right at least.
Re:Shockingly better? (Score:1, Interesting)
Some languages can be parsed directly into SSA form fairly efficiently; however, most compilers will probably do a pass to convert their own parse tree format into SSA so they can optimize in SSA form. They might have to convert it back afterwards though. I think the first versions of GCC to do optimizations on an SSA form used to convert back and forth a few times.
It would be nice to see a mainstream compiler that does ALL its optimizations in SSA form (and no, the SGI compiler doesn't count)..
Re:GUI (Score:1, Interesting)
I suggest you try KDevelop before you go spreading lies about the non-existance of a good IDE for Linux.
And no, KDevelop is not only for making KDE programs
Re:Autovectorization (Score:2, Interesting)
Could be, but auto-vectorization will help not only Altivec enabled architectures (PowerPC G4, PPC970 G5, Cell), but it should also help x86 architectures as well, since SSE, SSE2, and SSE3 are Intel's version of vectorization, or essentially applying the same mathematical operation to many bytes of data at the same time. I think all modern architectures should see a speed increase, especially with multimedia type applications like video encoding/decoding/transcoding.
Re:I just want C++ programs to COMPILE faster (Score:5, Interesting)
I'll add a couple things that have been _very_ useful in my experience:
- the const keyword: if you want to make your codebase a whole lot safer, and compile AND run faster, const is great. (Yes I know it finally became part of the C language with the C99 standard...)
- the STL. Some love it, some hate it. For my old job (game programmer), it was invaluable. We made extensive use of certain containers, and the algorithms are great. Sure I learned how to write various sort routines in college but I don't even have to think about it when the STL already has an optimal version.
- operator overloading. Once again, some love it, some hate it. Game programmers deal with vector math and quaternions all the time, so this feature of C++ is put to good use. It makes the code read more like a math equation, instead of stuff like:
result = vector1.add(vector2);
There are probably more things that have slipped my mind but those are the ones that jumped out at me right away.
Gcc killed fortran (Score:5, Interesting)
Re:Yeah, something that article does not bring up. (Score:1, Interesting)
Re:Gcc killed fortran (Score:3, Interesting)
(1) the slow arrival of the Fortran 90 standard, which added dynamic memory allocation, a full set of control structures, user-defined types and free source form, and which otherwise remedied the defects of Fortran 77.
(2) the lack of a free Fortran 90 compiler.
G95 does implement practically all of Fortran 95, including the features listed in (1), and gfortran is progressing towards that goal. It is obscene to accuse the volunteers of g95 and gfortran of "killing Fortran".
Apple has been on the "leading" edge for a while (Score:5, Interesting)
10.3 shipped with GCC 3.3, before 3.3 was released.
10.4 looks to continue the pattern. Apple takes a snapshot of GCC, forks it 6-9 months before the OS ships, tweaks/tunes/optimizes GCC, builds and ships with that version of the compiler, and then re-submits its changes, so future GCC builds (especially the PPC ones) get all the goodies.
And the compiler has had 6-9 months of QA from Apple, which is as good as the amount of credit you give their QA department
Re:Major Features Dropped From GCC 4.0 (Score:5, Interesting)
Care to tell us what this oh so mysterious restriction is?
Re:Major Features Dropped From GCC 4.0 (Score:3, Interesting)
Now, there are some of us (*waves hand*) who feel that RMS is a reactionary zealot in this respect, and would be more than happy to use the LLVM techniques, but we won't get into that.
Sounds like RMS is protecting gcc, good for him. Unless you have something more substantial than insinuated slander?
Phillip.
Re:I just want C++ programs to COMPILE faster (Score:4, Interesting)
So I've always wondered why GCC was so much more demanding. BTW, does GCC support pre-compiled headers now? That's what seems to provided the biggest build performance boost. Even more so than parallel compilation on an SMP machine.
Re:Gcc killed fortran (Score:2, Interesting)
Re:Fortran??? (Score:4, Interesting)
This is a dramatic oversimplification, but from what I've read on the GCC lists, it appears to be how it works.
Can anyone elaborate on this LLVM v. RMS issue? (Score:3, Interesting)
Re:Nitpicking (Score:2, Interesting)
Bollocks. They only wrote some stuff to support IA64 because they were desperate and no-one else would.
Re:and how many times... (Score:3, Interesting)
And if you statically link against libc on, I suspect, at least some other UN*Xes (Solaris being one of them), you'd better be prepared to handle the consequences as well. The same, I suspect, applies if you statically link against the kernel32/gdi32/user32 libraries on Windows, if you even can do so.
Thus, it's not even clear that this (problems with installing completely-statically-linked binaries on OS versions other than the one on which it's built) is any worse than it is on Solaris or Windows, except for the "this week's version of glibc" problem. That would be the real problem, although if the binary requires this week's version of glibc because it was written for this week's version of glibc and uses functionality of this week's version of glibc, then, well, if you choose to do that, be prepared to handle the consequences....
(Yes, this means that making system developers' lives better by making the lives of some application developers harder, well, makes the lives of some application developers, such as the ones who want to use the latest shiniest APIs but still deliver their applications on systems lacking those APIs, harder. So it goes....)
Re:Gcc killed fortran (Score:3, Interesting)
In the end, Fortran95 is fantastic for scientific computing and the only other language that comes close is C. C is just as fast, but (omfg) you can make a lot of mistakes that will just suck the time from you. No thanks.
Re:I just want C++ programs to COMPILE faster (Score:5, Interesting)
The extra compile time buys you more inlining (which can be either good or bad for performance, depending on cache behavior) and also type-safe templates which are not acheivable in C (without ugly hacks).
Re:Can anyone elaborate on this LLVM v. RMS issue? (Score:5, Interesting)
Because of this history, RMS does not want to make it easier for companies to take from gcc without giving back. LLVM would provide a clean interface between portions of gcc, and that clean interface could be so abused.
Remember that gcc has Objective-C support only because NeXT was forced to abide by the GNU GPL. Large portions of gcc were contributed by volunteers under the terms of the GNU GPL; their work was donated with the expectation that others' work would be made available. Many would see LLVM as a betrayal of that expectation. The next version of the GPL may address this issue...
Re:C++ compiler (Score:2, Interesting)
Well, that's exactly how GCC is built. It would use the existing compiler you already have on your system to build a portion of GCC enough to compile/build the version of GCC you're attempting to build.
Re:Apple has been on the "leading" edge for a whil (Score:1, Interesting)
Its so bad, that I don't even use Apple's GCC for any C++ development; I always start by building a GCC/G++ from FSF's released codebase.
Re:Mudflap (Score:3, Interesting)
There are many places where C is still used. There are many API's that are still in C. There's plenty of embedded systems programming that is done in C. So on and so forth. It has it's uses just like fortran has it's uses (and that's a rather ugly language IMHO).
A couple of years ago I was using C for embedded systems, due to the fact that the overhead incurred by C++ was just too large.
I still prefer C++ to the newer languages, along with the occasional assembler block for super critical performance code.
The newer languages certainly take a considerable amount of work out of the process (which I really like), but all those features come at a cost. And for those projects where the costs outweigh the benefits, "unsafe languages" will still be used.
I'd like one of the newer languages to have the power of assembly/C/C++ while still maintaining all their grace of memory saftey and management.
They're getting better, but they're not quite there yet.
~X~
for loop inside a printf -- gcc does it (Score:4, Interesting)
Re:Mudflap (Score:3, Interesting)
My only concern is that some developers will think turning it off for releases is OK. Anyone who thinks that any real-world software project is a "finished product" is deluding himself. It reminds me of a quote I read somewhere, which said basically, "Turning off assertions to ship is like practicing on the ground with a parachute and not wearing it when you jump out of a plane."
Jeremy
Re:OpenMP? (Score:3, Interesting)
The C compiler front end doesn't, but at least one other language front end does (i.e. Ada)
FS Delayed Allocation (Score:2, Interesting)
-2A
Re:This is a troll, right? (Score:3, Interesting)
Example 1: C++ standard defect
int func(int param=3);
int func(int param=3){
dosomething(param);
}
If you are like me, you copy the declaration to the definition, and have a working program in 3.0 and not in 3.3. And yes, the program is incorrect(the second =3 is not allowed), but this it is a stupid problem.
Example 2: Another C++ standard defect:
The keyword 'typename' is required at some positions in a template, and forbidden at other positions, altough they look very similar. I am not going to give an example, as the differences are so obscure that I don't even know them completely myself. Again, 3.0 allowed this and 3.3 didn't
Example 3: gcc bug.
There was something in gcc 2.7x about clobbering a returned register in asm statements. It was allright, but technically forbidden in 2.7x, WHICH WAS NEVER MENTIONED IN THE DOCUMENTATION! When upgrading to 2.9x, the code stopped compiling, and gave a very obscure error message (I believe it was 'Error:Register C has been spilled for class CReg' or something like that.)
All of these errors could have been turned into warning for some 'transitional' versions of gcc, which would have given me the time to fix them more easily.
Re:how LLVM would harm gcc (Score:2, Interesting)