GCC 4.0 Preview

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.'"

Comments

OpenMP?

[Anonymous Coward]

What I'd like to see is features like OpenMP for thread-level parallalism.

Re:OpenMP?

[Anonymous Coward]

Sun has a nice summary of OpenMP here

It's pretty cool. You write a loop like this:

#pragma omp parallel for private(sum) reduction(+: sum)
for(ii = 0; ii < n; ii++){
sum = sum + some_complex_long_fuction(a[ii]);
}

and the complier will handle the creation and syncronization of all the threads for you. Here's a OpenMP for GCC project on the FSF site. Looks like it's still in the "planning" state, though, so I'm guessing it's not in GCC 4.X.

Re:OpenMP?

[multipart]

We're working on the necessary infrastructure to associate the pragmas with the syntactic constructs they apply to. Actually parsing the OpenMP directives was already implemented - twice - but GCC does not support pragmas with a lexical context yet. This is needed for a bunch of C extensions, so we're working on that. This is probably GCC 4.1 material. After that, actually generating concurrent code from OpenMP pragmas is next.

I just want C++ programs to COMPILE faster

[drinkypoo]

Is it just me, or is compiling C++ code an order of magnitude slower than compiling C code? (exaggeration) I'm sure there's a very good reason why this is so, but it still doesn't make me happy.

Re:I just want C++ programs to COMPILE faster

[Profane MuthaFucka]

It does take longer to compile C++. The solution to this is to keep Slashdot open in a browser. Back in the days before Slashdot, when compiling took even longer, programmers actually used to go ape-shit watching the compiler. We live in wonderful times.

Re:I just want C++ programs to COMPILE faster

[KhaZ]

Maybe someone's already said this, but look into three projects to speed up your compile:

1) make (or some equiv). Yes, I said make.

GNU make accepts a -j parameter, to thread builds. Only really useful on hyperthreading or multiprocessor boxes, however. That said, if you use:

2) http://distcc.samba.org/: distcc. You can distributedly compile your apps across other machines with a similar setup. Only really helpful if you have more then one box.

3) http://ccache.samba.org/: ccache. This is a C/C++ compiler. Only really useful for iterative development, and if you're doing a lot of make clean/make, as it'll cache things that don't to be rebuilt.

Just some suggestions. Also, check out prelink, to prelink anything using shared libraries (trade space-savings into performance) and make startup code run faster in some cases.

Hope that helps!

++Informative? Pwetty pwease?

Re:I just want C++ programs to COMPILE faster

[Rei]

using namespace name;

That's all you need to do. What's so hard? I use "using namespace std;" in the common include files of all of my home-built programs.

C++ is a different language. Not only is its syntax different, but the style of doing things is different. If you're expecting to not feel like it's an alien environment, you'll be sorely mistaken.

That doesn't mean it's bad; after a long time of resisting it for taste reasons, I started learning exactly *why* C++ does certain things, and how to put them to good use. And the differences can be staggering at times - templates are invaluable, destructors are invaluable, classed arrays (things like vectors instead of pointers) are invaluable, maps are invaluable, etc. These sort of things can knock out bugs you didn't even know were there, improve performance, drastically shorten, and clarify your code all at the same time. That's a rare combination of benefits in the programming world. You pay for it in compile time costs, but it's well worth it - especially when it comes to maintenance. You just have to accept that it's going to feel rather alien for a while, and during that time, you'll be asking yourself, "Why?".

BTW, Java 1.5 is becoming more and more like C++ every day. So, if you don't like the features of C++, you won't like them in modern Java.

Re:I just want C++ programs to COMPILE faster

[Anonymous Coward]

templates are invaluable, destructors are invaluable, classed arrays (things like vectors instead of pointers) are invaluable, maps are invaluable, etc.

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.

Re:I just want C++ programs to COMPILE faster

[Rei]

Amen. I used to think that C++ was slower because you would have to deal with the overhead of objects. Until I actually started using it, and found out that during compilation, you don't really experience much if any overhead. On the other hand, you tend to benefit greatly from the highly optimized operations in the STL library.

Const, operator overloading... all of it is great. Inheritance, too. There are so many things in C++ to help you keep your code small, easy to read, and clean. It feels a bit alien at first if you've been programming in C for a long time, but it's well worth it.

I have my faults with it, of course. I think streams were done rather poorly, for example. But overall, I'm glad I switched. :)

Re:I just want C++ programs to COMPILE faster

[Kihaji]

Real coders use nuttin' butt C, ADA, and ASSembly.

Funny, I thought real coders used the right tool for the job, or is that real smart coders?

Re:I just want C++ programs to COMPILE faster

[Malc]

I think that's specific to GCC. The Microsoft compiler doesn't have this issue. I remember building the TAO Corba ORB on my Celeron 366 w/128MB a few years under Linux - it consumed all memory and a load of swap and a gig of disk space. It compiled faster under NT4 on my work Pentium Pro 200 with 64MB, and didn't require so much memory nor disk space. Same code base.

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:I just want C++ programs to COMPILE faster

[mzieg]

I use "using namespace std;" in the common include files of all of my home-built programs.

It's generally regarded as a Bad Idea to place using directives in header files.

They propogate down into every .cpp that includes your library's headers, whether or not the calling programmer wanted to import the entire std namespace.

Some programmers may have their own classes called map, or string, or list, or a dozen other things, and a single using statement buried in a nested .h can cause unanticipated namespace collisions.

In general, it's safest and most polite to refer to classes canonically in header files (std::string, etc), and keep the using statements in your implementation files.

Sources: "Accelerated C++" (Koenig, Moo); comp.lang.c++ (sample)

Re:I just want C++ programs to COMPILE faster

[captaineo]

This has more to do with the habits of C++ programmers rather than the language itself. If you take a random piece of C code and compile it as C++, it will probably take no more than 2-3x more time (the slowdown being due to a larger compiler binary, more sophisticated type-checking, etc). However what is often considered "good C++ programming style" involves inlining far more code than is the norm for C. (e.g. some STL implementations are entirely inline, whereas it would take a pretty crazy C programmer to implement hash tables and heaps inline). That's what blows up the compile time (and binary size).

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:I just want C++ programs to COMPILE faster

[johannesg]

I think that's specific to GCC. The Microsoft compiler doesn't have this issue.

That's not true. Building C is much quicker with Visual C++ than building C++. I know, I do it every day.

However, it is generally speaking true that gcc takes more time to compile than Visual C++ does.

watch out

[fanblade]

"...software written in the C++ programming language should run faster--..."

Is this the programmer's way of saying it will run at some speed less than faster?

Re:watch out

[r00t]

No, that's a postfix "--" operator. This software will run faster. Other software, trying to be faster, will be at a disadvantage because "faster" has been decremented. This is really just a sneaky way to make other languages look bad.

C++ compiler

[pchan-]

But will it compile C++ any faster? The difference between compile times of C and C++ files is staggering. Compiling Qt/KDE takes forever with gcc 3.x.

Re:C++ compiler

[bill_mcgonigle]

But will it compile C++ any faster?

Yes, from here: "

GCC 4.0 features an entirely new C++ parser. The new parser is tremendously faster than the one in GCC 3.3 and will have a noticeable benefit when building C++ based projects.

Re:C++ compiler

[Surt]

It claims the c++ front end is as much as 25% faster.

Re:C++ compiler

[Anonymous Coward]

Apparently. Found via google:

http://people.redhat.com/bkoz/benchmarks/

Doesn't look public though.

Re:C++ compiler

[SlashThat]

And when they compile GCC 4.0 with GCC 4.0, it will be even fasterer!

Re:C++ compiler

[vsprintf]

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:C++ compiler

[multipart]

Actually, a substantial part of the new C++ parser in 3.4 was rewritten again for 4.0.

Mudflap

[SteelV]

"GCC 4.0 also introduces a security feature called Mudflap, which adds extra features to the compiled program that check for a class of vulnerabilities called buffer overruns, Mitchell said. Mudflap slows a program's performance, so it's expected to be used chiefly in test versions, then switched off for finished products." - from the article

I really love this feature, it will probably cut down on a great deal of problems. My only concern is that some devs will think running it all the time is OK (read: "Mudflap slows a program's performance"), so hopefully that's not the case.

More detailed information on the mudflap system can be found here.

Re:Mudflap

[idlake]

My only concern is that some devs will think running it all the time is OK (read: "Mudflap slows a program's performance"), so hopefully that's not the case.

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.

Re:Mudflap

[idlake]

C doesn't have a screwed up pointer semantics. It is perfect for what it does. You probably just don't understand it. Where are you getting the 3 to 5 factor? Anything to back that up? And the few percent is from what language?

I have been using C since 1980. I have seen dozens of attempts to fix C semantics since then. I published some papers on it myself. It can't be done efficiently. The best you can do is something like Mudflap, Purify, Cyclone, or Valgrind.

Where does the factor of 3-5 come from? From the Mudflap paper on the Mudflap web site--it has benchmarks.

Where do the "few percent overhead" come from? From comparing the performance of Pascal, Java, and Eiffel code compiled with safety on and off.

And you know what the real kicker is? Not only do C pointer semantics make it impossible to generate efficient runtime safety checks, they even inhibit important optimizations when no safety features are enabled. And because C programmers then have to jump through all sorts of hoops to achieve some kind of safety in the midst of this chaos, the software ends up being bloated, too. So, C is not only bad for efficient safe code, it is bad for efficient code of any form.

I am getting sick when C-hating posts like this one get modded up. Seems to be happening all the time lately.

I'm getting sick of the fact that ignorant fools like you have been holding back progress in software systems for a quarter of a century. It's even more annoying that you try to portray your ignorance and inexperience as some kind of principled stance. C was good for what it was 30 years ago: an on-board compiler for writing small, low-level programs on machines with very limited memory. C made a decent PDP-11 compiler for V7 UNIX, and it was usable on CP/M and MS-DOS. I have fond memories of it in those environments.

I'm starting to meta-mod again.

You do that. If you join forces with enough other idiots, you will probably be able to condemn us to another quarter century of bad pointers, buffer overruns, and bloat.

Re:Mudflap

[Hal-9001]

It took me all of 60 seconds to Google this link subtantiating the factor of 3-5 slowdown with Mudflap: http://gcc.fyxm.net/summit/2003/mudflap.pdf The performance data is tabulated on page 7: the average slowdown out of six test cases (three build case, three run cases) appears to be a factor of 4 or so, with the best case being 1.25 (in one run case), and the worst case being 5 (in one build case and in one run case).

Re:Mudflap

[idlake]

I just googled for mudflap performance hit and got nothing

You don't need to Google, you just need to follow the links at the top of the story!

How does the C sematnics make it hard for the complier to iperform checks on buffers?

Because, for practical purposes, C pointers have to be naked memory addresses that can point into the middle of an arbitrary sized chunk of memory. That means that, unlike implementations of other languages, a C implementation cannot simply get information about bounds or types by looking up data at a fixed offset relative to the pointer.

There are plenty ways to prevent buffer over-runs these days.

Yes, like using a decent language with a minimum of built-in error checking and a sensible type system. We have had them, oh, for about half a century. And nowadays, you can even choose among a bunch of mainstream languages like that: Java, C#, VisualBasic, OCAML, and Python, to name just a few.

Do you have any links at all to contribute?

I have no idea what your background is; you might high school kid that writes viruses in C in his spare time and thinks that C is the k00lest thing since Britney Spears. But if you seriously want to learn about this sort of thing, look at the Cyclone papers (you can find them on Google) and check their references, as well as references to them in the literature. You'll reach a large collection of papers on trying to make C safe. Pick and choose according to your interests.

Re:Mudflap

[marcosdumay]

The best you can do is something like Mudflap, Purify, Cyclone, or Valgrind.
Yes, it is, but C has other strengths that make it worth.

Where do the "few percent overhead" come from? From comparing the performance of Pascal, Java, and Eiffel code compiled with safety on and off.
But all those languages face a performance hit compared with C even with safety off.

And you know what the real kicker is? Not only do C pointer semantics make it impossible to generate efficient runtime safety checks, they even inhibit important optimizations when no safety features are enabled. And because C programmers then have to jump through all sorts of hoops to achieve some kind of safety in the midst of this chaos, the software ends up being bloated, too.
One need that optimixation when have no control of his pointers. But a well written program on C can be as fast without the compiler optimization. Also, a good design can avoid the bloat without compromissing security and also generate optimizations for the places where safety can be off.

I'm getting sick of the fact that ignorant fools like you have been holding back progress in software systems for a quarter of a century.
I am design a very speed sensitive library. Which "modern" language do you recomend me? On what language can I keep my arrays at the stack, like I'm doing on C for better speed? And on what language I can create an entire (less powerfull but faster) memory management library to avoid a bottleneck like I did with C (C++ actualy)? Think twice before you call most of the people out there idiots. Obvoulsy there are programs that worth the pay-off of using an easier language, but before you ban C, try to realize that there are applications that doens't worth it. And since some of them are the compilers of your "modern" languages, don't see how supporting C delay their developpment.

And, before you try to arguee, I belive on the better tool for the job. That is why I currently have 4 projects, one in C++, one in Java, one in Perl (learning) and one in Bash script. I am not a blind C overload.

Autovectorization

[DianeOfTheMoon]

One optimization that likely will be introduced in GCC 4.1 is called autovectorization, said Richard Henderson, a Red Hat employee and GCC core programmer. That feature economizes processor operations by finding areas in software in which a single instruction can be applied to multiple data elements--something handy for everything from video games to supercomputing.

Is it just me, or is this the first "we will make it easy to program the Cell" step that Sony and IBM were promising?

Re:Autovectorization

[s0me1tm]

Autovectorization is for SIMD, not for SMP

Re:Autovectorization

[iabervon]

Each of the APUs in a Cell has SIMD instructions. Also, the PU handles dispatch, so it's not all that much like traditional SMP from the compiler's point of view.

Screenshots!

[Anonymous Coward]

Screenshots, screenshots! I need screenshots people!!!

Re:Screenshots!

[SteelV]

Screenshot.

Knock yourself out, bud!

Re:Screenshots!

[Espectr0]

Ask and ye shall receive:
http://www.algorithm.com.au/albums/screenshots/lon g_gcc_cmdline.png

Re:Screenshots!

[devphil]

Point-by-point response:

• From "make --help" comes the answer:

  -s, --silent, --quiet Don't echo commands.

• All that information is available, but only if you let make echo the commands. :-) The directory is printed as make changes directories, the command is printed as it's run, etc, etc. You might try something like "make foo > make.log", which will still print stderr to the screen.
• Okay, well, you need to decide what you want to see. Some projects "echo gcc -f... -I... > Compile", and then the makefile rules and make output is just "./Compile foo.c" on each line.
• That's tricky to do. Which tool's responsibility is it?

Re:Screenshots!

[DeadMeat (TM)]

That's tricky to do. Which tool's responsibility is it?

colorgcc's.

boost, please ?

[savuporo]

Can we get Boost in standard library please ?

Re:boost, please ?

[devphil]

What does GCC have to do with this?

If you want something added to the standard, talk to the C++ standard committee. (Either the Library or the Evolution groups, in this case.) You'll find you're about the 10,000th person to ask for this. You'll find there's an extensive FAQ on this exact subject. You'll find that the committee is very keen on adapting large parts of Boost, as experience in the real world smooths the rough edges of Boost.

If you look a bit more, you'll find that some extensions have already been adopted (called "TR1") and are being shipped with GCC 4.0.

You'll also find that GCC does not get to determine what's in the standard. And -- speaking as one of the libstdc++ maintainers, although I'm largely too busy to do much myself these days -- GCC will not ship Boost. Or glibc. Or libAPR. Or OpenSSL. Or any of the other million very useful open source libraries out there, because that's not our job.

and how many times...

[Zapman]

And how many times will they break ABI, API and library compatability in THIS major release? Count stands at 4 for the 3 series, maybe higher.

The biggest challenge with Binary compatability across Linux distros is the GCC release (followed by the glibc releases, who live in the same ivory tower). I realize that things have to change, but I wish that they would not break compat between versions quite so often...

I'd really like to be able to take a binary between versions, and it just work.

This is one area where Sun rocks. Any binary from any solaris2 build will just work on any later version. With some libraries, you can go back to the SunOS days (4.1.4, 4.1.3UL, etc). That's 15 years or so.

Re:and how many times...

[tap]

C binary compatability is broken constantly, with every version of glibc. Anything compiled statically will crash using NSS if you compile statically and use a sligtly different gblic version. If you compile dynamically, then anyone who doesn't have this weeks version of glibc can't run your binaries.

I'm so sorry, ...

[kompiluj]

but the reason it takes forever to compile KDE lies in fact that it uses extensively the templates. While templates (a.k.a. generics) are a very useful language feature, they increase compile times. Including support for export template feature could help but only when anybody would use it in their code.
You can make an experiment and try compiling KDE with Intel C++ or Comeau C++ compilers, and see that not much can be gained comparing to GCC.

sane error messages when using templates

[kharchenko]

I wish the compiler would output sane error messages on compiling code that uses a lot of templates (i.e STL). At least fixing it so that the line numbers are shown during debugging would be a huge improvement!

Favorite quote from the article

[devphil]

It's not too much of a stretch to say GCC is as central an enabler to the free and open-source programming movements as a free press is to democracy.

Re:GUI

[ishmalius]

Visual C++ does not have an IDE built into the compiler either. Visual Studio is a GUI editor for a VC++ project which shells out to the command-line compiler.

Likewise, there are several IDEs that can nicely handle a C++ project which uses GCC. Eclipse is maybe the best example of these.

Besides, do you really want "Must have GUI to cope with compiler" on your resume? ;-)

From what I've heard

[Mad Merlin]

GCC 4.0 apparently does compile things quite a bit quicker, C++ in particular. This should be a nice boost for anybody who compiles KDE and such for themselves.

If you're interested, here's a (long) discussion which makes reference to many of the things coming in the new GCC.

Yeah, something that article does not bring up...

[PaulBu]

That GCC is the staple in the embedded world. They could've mentioned that most probably it is the compiler used for the proverbias Internet toaster, or maybe even something sexier, like Formula-1 engine-tuning app... ;-) Apparently the article is written to educate the "general public", would be nice to put this little tidbit into their minds..

Paul B.

Re:Shockingly better?

[bill_mcgonigle]

Have they found some new-fangled magical technique for compilation?

Actually, SSA trees probably count, which is new in GCC 4 (invented in the early 90's). Look here, scroll down to "Power Through Builds" for a list of improvements from SSA trees.

Of course, this claim may be due to no longer doing something shockingly inefficient.

Re:If GCC can compile C++, then...

[Kupek]

g++ is basically an easy way of calling gcc for C++. From the gcc and g++ manpage:

However, C++ programs often require class libraries as well as a compiler that understands the C++ language---and under some circumstances, you might want to compile programs from standard input, or otherwise without a suffix that flags them as C++ programs. g++ is a program that calls GCC with the default language set to C++, and automatically specifies linking against the C++ library. On many systems, g++ is also installed with the name c++.

Gentoo system rebuild!

[uujjj]

Can't wait!

(I'm especially excited by the possibility of random compiler incompatibilities!)

Re:Gentoo system rebuild!

[devphil]

We now actually detect when GCC is running on a Gentoo system, and will occasionally miscompile an inner loop, just to make you twitch. The biggest complaint we received from Gentoo users during the 3.x series was that GCC was too boring, so we threw this in to keep you on your toes.

Cheers!

Re:GUI

[Daedius]

First, you are missing view of an ideaology among many open source projects which is to create a very powerful and optimized that does not bind itself, its users, or any other projects that want to build on top of it to any particular GUI. Most programs do this by running in extremely flexible commandline interfaces, allowing library interfaces, or just being a library for external programs to reference. You do have a point, however, that there is a lacking of a good IDEs in the linux community. I don't think any of us can deny the tremendous effect of an extremely good IDE (Eclipse for java for example). I think within the open source community one of the biggest threats they have to people just picking up linux and wanting to program is a lack of a good IDE. Honostly, when i'm programming in .NET on Visual Studio 2003, I feel like i'm in heaven. I only wish I could have the same type of luxury within linux (Especially with the MONO project!). But with all things, it takes contribution.

Re:More incompatibilities on the way?

[ari_j]

It's been my experience that they only have a lack of respect for incorrect code. If your legacy code is incorrectly-written, then you assumed the risk to begin with, says me. Write to the standard.

Not much.

[devphil]

"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:Not much.

[devphil]

Execution speed.

The gcc/g++ driver's purpose in life is to rip through the command line, figure out what other programs need to be run (compiler, assembler, linker, etc), fork them all off -- possibly in a loop, if you've passed more than one file on the command line -- and clean up afterwards.

"gcc -> real-work-programs" or "g++ -> real-work-programs" is a much faster executation path than "sh parser -> gcc -> real-work-programs", especially when your makefile is repeatedly invoking g++.

Maintainence is not especially difficult; g++ isn't really a seperate program. The difference between gcc and g++ is one or two extra .o files that get linked into the final executable. (Same for other language drivers that can't get by with plain "gcc", like the Java one.)

Re:More incompatibilities on the way?

[gvc]

Yes, you've captured their attitude precisely.

Wrong.

[devphil]

Even the most cursory search of the GCC mailing list archives would disprove this.

Intel C compiler team

[zymano]

What do they do that makes their c compiler so much faster ?

Ahem.

[devphil]

I realize that things have to change, but I wish that they would not break compat between versions quite so often...

Have you tried maintaining a compiler used in as many situations as GCC? (If not, you should try, before making complaints like this. It's an educational experience.)

We added a "select ABI version" to the C++ front-end in the 3.x series. If you need bug-for-bug compatability, you can have it.

I'd really like to be able to take a binary between versions, and it just work.

Wanna know when this is gonna happen? Sooner, if you help.

Re:Ahem.

[marcelk]

I realize that things have to change, but I wish that they would not break compat between versions quite so often...

Have you tried maintaining a compiler used in as many situations as GCC? (If not, you should try, before making complaints like this. It's an educational experience.)


This is exactly the ivory tower thinking that the poster is complaining about. You are overestimating the maintenance cost und underestimating the pain for your users. This is typical for open source: think that what is good for the developer justifies major compatibility issues for everybody else.

Re:Ahem.

[Anonymous Coward]

You are overestimating the maintenance cost

How come you can judge the maintenance cost better than a GCC developer?

This is a troll, right?

[devphil]

The gcc team seem to have no respect for legacy code.

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.

Incompatible syntax changes

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. :-)

Re:This is a troll, right?

[Anonymous Coward]

Incompatible syntax changes? Yes, there are. Mainly, they are small defects to the C++ language.

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.

What?!?

[A nonymous Coward]

Hands up, everybody who remembers when "g++" was a shell script!

Are you going to rob us? At first I thought that was your joke, but the more I think about it, the more I wonder if, being a part of the gcc team, you are inserting insidious code to look for credit card and bank account numbers on the disk during compiles and use steganography to embed them in executables; no one else would know about them, and all you'd need is a robot crawling download pages, looking for binaries with some magic code somewhere ...

The little bit of extra disk thrashing during the combined compile and search would never be noticed, and no one looking at compiled machine lanuage ever wonders why it is so odd looking. They just assume it's because of some new fangled optimization.

My god you are devious rascals!

Performance on optimizations?

[jd]

There was an article not too long ago on a fabled isle of Techno-Guruism called Slashdot, in which someone benchmarked GCC 4 against GCC 3. GCC 4 produced slower binaries, in many cases. I'd want to know if those issues were REALLY fixed, before I became confident in the new technology.

GCC is an incredibly versatile compiler, with frontends for C, C++, Java, Ada and Fortran provided with the basic install. 3rd party extensions include (but are probably not limited to) Pascal, D, PL/I(!!) and I'm pretty sure there are Cobol frontends, too.

They did drop CHILL (a telecoms language) which might have been useful, now that telecoms are taking Linux and Open Source very seriously. As nobody seems to have picked it up, dusted it off, and forward-ported it to modern GCCs, I think it's a safe bet that even those interested in computer arcana are terribly interested in CHILL.

OpenMP as been discussed on and off for ages, but another poster here has implied that design and development is underway. OpenMP is a hybrid parallel architecture, mixing compiler optimizations and libraries, but I'm not completely convinced by the approach. There are just too many ways to build parallel systems and therefore too many unknowns for a static compile to work well in the general case.

Finally, the sheer size and complexity of GCC makes bugs almost inevitable. It provides some bounds checking (via mudflap), and there are other validation and testing suites. It might be worth doing a thorough audit of GCC at this point, so that the 4.x series can concentrate on improvements and refinements.

Re:Compiler

[That's Unpossible!]

Don't all compilers convert a program's source code into binary instructions?

Nope.

Oh, did you mean all SOURCE CODE compilers?

See, the word compiler was around before computers, and is only synonymous with "source code compiler" to geeks like us.

Therefore in your attempt to be pedantic, you clearly were not being pedantic enough, thus the joke is on you.

Ha-ha...

Major Features Dropped From GCC 4.0

[Qwavel]

At the GCC conference in Ottawa in the summer of 2003, there were two very interesting features presented that they said might make it into GCC 4.0.

- LLVM. Low Level Virtual Machine. This is a low level and generic pseudo code generator and virtual machine.
http://llvm.cs.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.

Re:Major Features Dropped From GCC 4.0

[devphil]

Yeah, heavy on the "might".

• Politics is what's preventing us from considering LLVM, let alone the long and torturous process of making the code work. The brutally short story is that GCC is operating under a certain restriction imposed by RMS since its inception, and LLVM -- or really, any good whole-program optimization technique -- would require us to violate that restriction.

  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.

• The compiler server branch is still being worked on, so it won't be in 4.0, but might be in 4.1 or 4.2 or... It's only a few people working on it, after all.

Re:Major Features Dropped From GCC 4.0

[eviltypeguy]

The brutally short story is that GCC is operating under a certain restriction imposed by RMS since its inception, and LLVM -- or really, any good whole-program optimization technique -- would require us to violate that restriction.

Care to tell us what this oh so mysterious restriction is?

Yes, it's true

[Sycraft-fu]

Not sure what you tried but in most compiler benchmarks Intel ranges from "just as fast as the others" to "devistatingly faster". It sometimes generates code that's faster than hand optimised assembly designed to do the same thing. The Intel compiler even generates better code for Athlons than other compilers.

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.

quote...

[Cryptnotic]

"They that can give up high performance to obtain a little temporary security deserve neither performance nor security."

--not Benjamin Franklin

Re:Nitpicking

[Mad Merlin]

From what I've seen, ICC is still ahead of GCC, but Intel has actually been putting a fair bit of work into GCC, and this is showing in the newer releases of GCC (mostly with Intel processors however, who would have guessed?), mostly compile time related, but also some optimizations for runtime speed. I'd provide hard numbers, but I don't have ICC or the articles that mentioned such handy.

No idea about MSVC, it doesn't build very good Linux binaries though anyways.

But if faster has been decremented...

[SuperKendall]

...would that not mean the speed other programs run at reaches "faster" more quickly?

Gcc killed fortran

[goombah99]

Gcc was what killed fortran. Gcc did not implement many fortran features forcing fortran programmers to use a pathetic subset of the language. For example in F77 they never implemented opening files read only (only open read-write) so you could never detect EOF's on pipes to fortran 77. But the real death knell for fortran was sung by g95 and its reduced language elements. Anyone who mistook g95 for F95 would indeed be right in concluding fortran was a dated useless language. Fortran95 does indeed have stucrtures, classes, pointers and allocatable memory contrary to widespread belief to the contrary due to g95. The irony is that fortan 2000 is actually a wonderful language for scientific programming in the coming age of multi-core processors. I would not write a wordprocessor in fortran but for sceintific programming its effieicient memory storage, implicit parallelism in the most basic elementes of the language language (for example for-loops that were allowed to iterate over their range out of order, and subroutines that declare which variables can have side effect) is perfect for the coming age of microprocessing. My favorite parts of fortrans are that one cannot overflow a buffer nor is it possible for a typo to compile. That last statment will elude understanding by most folks who never tried to write a line parser for fortran syntax but it's consequence is that hidden syntax errors that compile are impossible in fortran. (logic errors of course are possible in any language) one trivial example is you cant write = when you meant == or +=. Or the declaration of intent on calling arguments allows you to pass by reference without worrying that an array will be unintentionally modified. RIP fortran95, killed by g95.

Re:Gcc killed fortran

[beliavsky]

This post is nonsense. First of all, Fortran is not "dead" . There are about 10 Fortran 95 compilers, listed at http://www.dmoz.org/Computers/Programming/Language s/Fortran/Compilers/ , and compilers are adding features from the recently approved Fortran 2003 standard. Two reasons Fortran did lose much market share were
(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

[CatOne]

OS X 10.2 shipped with GCC 3.1 I believe -- a while before it was released.

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:Fortran???

[MarcQuadra]

Nope. GCC-4.0 has a totally new abstracted layer called GIMPLE, from the tree-ssa project. All front ends (C, C++, Java, FORTRAN) output to GIMPLE code, which gets optimized and turned into machine code. It should be MUCH easier to add support for new languages now, all yo have to do is write a front end that turns the input code into GIMPLE.

This is a dramatic oversimplification, but from what I've read on the GCC lists, it appears to be how it works.

how LLVM would harm gcc

[r00t]

It's a pretty far-fetched idea, but...

LLVM can be used as a GPL bypass. If this were to
become a problem, people would not feel as good
about contributing to gcc.

Well, that's how RMS thinks anyway. Never mind that
adding LLVM would enable some really neat stuff.

Re:Can anyone elaborate on this LLVM v. RMS issue?

[Anonymous Coward]

Over time, many companies have tried to make money off of portions of gcc without giving anything back to the community. For example, one of the Edison Group's C++ front-ends can be patched onto gcc, giving a "free" compiler for many platforms without giving a better C++ front-end to gcc. Currently, only an end user can patch gcc to work with that front-end. That restriction makes the product less attractive.

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...

for loop inside a printf -- gcc does it

[r00t]

printf("%d\n", ({for(i=2;i14;i++);i;}) );

No, here it is.

[devphil]

I didn't go into details because this has been covered elsewhere, and I'm tired of discussing it myself. But I didn't realize I would be accused of "uninformed slander". So. A bit of background info first.

Inside the guts of the compiler, after the parser is done working over the syntax (for whatever language), what's left over is an internal representation, or IR. This is what all the optimizers look at, rearrange, throw out, add to, spin, fold, and mutilate.

(Up to 4.0, there was really only one thing in GCC that could be properly called an IR. Now, like most other nontrivial compilers, there's more than one. It doesn't change the political situation; any of them could play the part of "the IR" here.)

Once the optimizers are done transforming your impeccable code into something unrecognizable, the chip-specific backends change the IR into assembly code. (Or whatever they've been designed to produce.)

Each of these transformations throws away information. What started out as a smart array class with bounds checking becomes a simple user-defined aggregate, which becomes a series of sequential memory references, which eventually all get turned into PEEK and POKE operations. (Rename for your processor as appropriate, or look up that old joke about syntactic sugar.)

Now -- leaving out all the details -- it would be Really Really Useful if we could look at the PEEKs and POKEs of more than one .o at a time. Since the compiler only sees one .c/.cpp/.whatever at a time, it can only optimize one .o at a time. Unfortunately, typically the only program that sees The Big Picture is the linker, when it pulls together all the .o's. Some linkers can do some basic optimization, most of them are pretty stupid, but all of them are limited by the amount of information present in the .o files... which is nothing more than PEEK and POKE.

As you can imagine, trying to examine a pattern of PEEK and POKE and working out "oh, this started off as a smart array class with bounds checking, let's see how it's used across the entire program" is essentially impossible.

Okay, end of backstory.

The solution to all this is to not throw out all that useful abstract information. Instead of, or in addition to, writing out assembly code or machine code, we write out the IR instead. (Either to specialized ".ir" files, or maybe some kind of accumulating database, etc, etc; the SGI compiler actually writes out .o files containing its IR instead of machine code, so that the whole process is transparent to the user.) Later on, when the linker runs, it can see the IR of the entire program and do the same optimizations that the compiler did / would have done, but on a larger scale.

This is more or less what all whole-program optimizers do, including LLVM. (I think LLVM has the linker actually calling back into the compiler.)

The "problem" is that between the compiler running and the linker running, the IR is just sitting on the disk. Other tools could do whatever they want with it. RMS's fear is that a company would write a proprietary non-GPL tool to do all kinds of neat stuff to the IR before the linker sees it again. Since no GPL'ed compiler/linker pieces are involved, the proprietary tool never has to be given to the community. Company wins, community loses.

End of problem description. Begin personal opinionating.

It's a legitimate concern, but many of us feel that a) it's going to happen eventually, and b) we do all GCC users a disservice by crippling the tools merely to postpone an inevitable scenario. As usual, there's a wide range of opinions among the maintainers, but the general consensus is that keeping things the way they are is an untenable position.