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.

Re:OpenMP?

[Col Bat Guano]

...but GCC does not support pragmas with a lexical context yet

The C compiler front end doesn't, but at least one other language front end does (i.e. Ada)

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

[keesh]

A lot of it is down to templates. As soon as you use them or STL you're upping the compile by an order of magnitude and gobbling up a hundred megabytes of RAM... With great power comes a cost.

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

[drinkypoo]

I don't mind pissing away RAM, I'm willing to spend 200MB if they can just do it faster, maybe through aggressive caching?

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

[Gr8Apes]

Having just viewed C++ for the first time in 5 years, I must say, yuck! Namespaces in the STL are what drove me from C++ in the first place. I'm glad they got the STL to work, but namespaces are still ungodly ugly, and their pervasiveness within C++ make what used to look like an elegant language an ungainly loaded behemoth Pascal offspring, and compiling it pretty much brought down a decent SGI machine of the time.

I'd rather use straight C at this point than C++ with the STL. Java is ever more elegant, perhaps one reason it eclipses C++ in the general business environment. (OK, so there's the generally accepted benefits of built in memory management to prevent neophytes from stubbing their toes and bringing down the house....) But with the JDK improving performance with every release, and Java gaining many of the lacking items in the the 1.5 release (ok, so some are compile time only) it's easy to see why Java continues to be a favorite of developers.

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

[Anonymous Coward]

namespaces::have::a::lot::more::dots::than::packag es

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

[MighMoS]

I think it comes down to C vs sh. If its more complex than sh can handle, start it up with C. Of course, I don't maintain large projects, that's my $0.02.

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

[EugeneK]

I think even when you are on a single processor box, you can get a bit of speedup with -j2.

Hopefully, while one g++ process is writing out an object file to disk (waiting for disk io to complete) another can be using the CPU to parse or optimize.

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

[hobuddy]

I've found that for C++ projects on the low side of medium (say, around 50,000 lines), arranging the compilation so that all of the source code is lumped into a single "unit" accelerates GCC's from-scratch compilation times considerably. Of course, it also uses large amounts of RAM.

For example, direct GCC to compile one top-level .cpp file containing hundreds of
#include "other-source-file-0.cpp"
#include "other-source-file-1.cpp"
#include "other-source-file-....cpp"
#include "other-source-file-673.cpp"
statements, one for each .cpp file in the entire project.

This forces GCC to compile the whole program as a single unit, so it preprocesses the headers only once, and generates only a single object file.

This achieves approximately the same reductions in compile time as precompiled headers.

Come link time (which can be quite long even for a medium-sized project), instead of needing to combine hundreds of object files, the linker need only deal with one. On x86-Linux with GCC 3.4.x, at least, this accelerates the linking process, plus generates a much smaller and slightly faster binary. I assume that the slight acceleration in the generated code is due to the fact that compiling the entire project as one compilation unit has essentially the same cross-unit optimization benefits as link-time code generation.

Although this technique reduces from-scratch compile times considerably, it's of dubious value in most situations because:

a) Users compiling the software as part of an installation process might find it uncomfortable--or even impossible--to allow the compiler several hundred MB RAM.

b) The developer's changes in a typical edit-compile-test cycle are localized. This technique destroys the possibility of using previously compiled object files for those compilation units whose source code hasn't changed, since there's only one compilation unit for the entire project.

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.

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

[johannesg]

Back in the days before Slashdot, when compiling took even longer, programmers actually used to go ape-shit watching the compiler.

As I recall, before Slashdot we were all reading the Dilbert "List of the Day", which, believe it or not, wasted possibly even more time than Slashdot did.

And should Slashdot disappear I'm sure we'll find something else to occupy those idle moments while compiling. Maybe talk to that new cute secretary... Hmm...

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

[martinde]

> GCC 4.0 features an entirely new C++ parser. The new parser is tremendously faster than the one in GCC 3.3

[snip]

But it's the same parser as g++ 3.4. It is faster (and fixes bugs) compared to g++ 3.3, but calling it "tremendously faster" seems a bit of stretch.

Re:C++ compiler

[Anonymous Coward]

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

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

[RetroGeek]

I really love this feature, it will probably cut down on a great deal of problems.

It will create a false sense of security.

During developing/testing problems are found and hopefully fixed. It is the problems that are NOT found that create vulnerabilities.

Re:Mudflap

[bill_mcgonigle]

My only concern is that some devs will think running it all the time is OK

For some users and some classes of applications, it will be OK. Sometimes security is more important than performance, and you can't imagine the weird stuff your code sees when it's in the customers' hands.

Re:Mudflap

[dynamo]

Uh, doesn't this imply that testing itself creates a false sense of security? Sure, let's not bother testing. Great solution.

Re:Mudflap

[multipart]

No, propolice is something entirely different. That's a stack smashing protector. Mudflap is a bounded pointers implementation.

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

[Megasphaera Elsdenii]

check for a class of vulnerabilities called buffer overruns

Eerily reminiscent of VAX/VMS's "/ARRAY_BOUNDS_CHECKS=ON" option, around 1985 this was. Admittedly, this was for Pascal or somesuch.
Cool thing for gcc nonetheless. Don't forget to check Boehm's Garbage Collector for C and/or Bruce Perens' Electric Fence

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

[Xyrus]

While I agree that C's golden age has come and gone, it shouldn't be relegated to the dust-bin of history yet.

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~

Re:Mudflap

[Cryptnotic]

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.

Pretty much any of those newer languages (I assume you mean Python, Ruby, Lua, et cetera) provide a C API for adding module interfaces (useful for doing fast calculations, access to C libraries, low-level operating system or device communications, et cetera). You shouldn't be afraid of mixing languages. It's the only way to really get the best of both worlds.

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

[jemfinch]

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.

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

[WMD_88]

Autovectorization is a feature pushed by Apple. Since their AltiVec isn't being exploited like it *can* be, they've gotta push it into the compiler to give themselves a speed boost on G4/G5 (and rightfully so).

Re:Autovectorization

[illumin8]

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?

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: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!

[Merk]

Funny, but it does highlight something that annoys me. Make/gcc output.

For the last few weeks I've been compiling a set of apps that's about 5x bigger than just the Linux kernel (it includes the kernel too). Watching the make/gcc output scroll by I've decided one thing: I *hate* it.

GCC itself is fine. It only does something when there are errors. Make, on the other hand, spits out every command it runs and all kinds of things that I really don't care about.

Without the bloat of a full-fledged IDE, is there such a thing as a make-wrapper GUI? Here's what I'd want:

• Don't show me what commands are being run by default. 95% of the time, I don't care what commands make is running, I just want to know what went wrong. On the other hand, don't just throw out the output. If something goes wrong, I might need that output.
• Show me errors, but give me context. It's great to know that there's an "undefined reference to 'ide_xlate_1024'", but what's the context leading up to that? What directory was it in? What command caused that error? What was the first error in a series? What was the environment? What were the commandline args?
• If I *do* want to see the output of a command, don't just give me the raw commandline. When the commandline is 800 characters long, parsing all the switches with a Mark 1 eyeball is too damn difficult.
• Syntax highlighting! -I/dir could look different from -DEMBED which could look different from -Wall. Errors could be highlighted too: "Undefined reference" should look different from "warning foo redefined", which could look different from "conditional is always true due to limited range of operands" (or however it's phrased)

I'm sure I could come up with some more enhancements, but that would really make me happy. I know the 2.6 kernel has gone a few steps in this direction but it is far from enough.

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 ?

[yamla]

I'd love for boost to be in the standard library, but I'm not sure that complaining to the gcc folks is the way to get this done. Surely if we want this in the standard library, it should be included as part of the next version of the ISO C++ standard?

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

[LiquidCoooled]

Actually, MS are pretty good at that as well.

You can still run software from 1981 on windows XP.

Take a look for yourselves (those in Windows) here

Re:and how many times...

[ceswiedler]

You're talking about C++ binary compatibility, right? I don't think that GCC has broken C binary compatibility in a long time...

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:and how many times...

[captaineo]

YES this is a huge problem. More than half of my Linux troubleshooting time can be traced back to version skew issues in either GCC or GLIBC. (libstdc++ changes, pthreads changes, exception handling changes, etc...)

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

Re:and how many times...

[Guy Harris]

If you chose to go against the developers and statically link to Glibc, be prepared to handle the consequences!

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

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!

Re:sane error messages when using templates

[tgv]

I only suffer this problem when the line endings in an include file is not "native" to your platform. One include file with LF instead of CR endings is sometimes can be enough.

I don't know precisely about STL, since I avoid relying on it, but you might check all include files. If you're on a unixy platform, try to get the list of all include files (via a "depend" like command) and check 'm all for line endings (the "file" command can be helpful).

Re:GUI

[Trillan]

GCC is just the compiler. If you want an IDE that works with it, look around... there are a few. I don't really have any recommendations as I'm mostly working with other tools right now.

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.

Why not run it all the time?

[Anonymous Coward]

The protection from buffer overruns is valuable enough that perhaps it is worth including all the time. After all, who knows what vulnerabilities lurk after you "turn off" mudflap?

Besides, it might just be automating the addition of the same code that we would need to put in to fix buffer overrun vulnerabilities.

This is one case where I think it's worth "wasting" a small amount of performance (except perhaps in routines that need to be highly optimized) to give added security. Sure beats ray-traced-on-the-fly desktop widgets, or something, which you KNOW we're goingto see advertized in another decade. ;)

Re:Why not run it all the time?

[Anonymous Coward]

The instrumentation is apparently rather heavyweight, involving try-catch blocks and extra function calls around all "unsafe" pointer and array accesses. So the runtime cost would be prohibitive, except perhaps if it were selectively deployed, let's say around your API function handlers. But if you're going to bother making that selection, why not inspect the code in those key places and make sure there are no buffer overflow vulnerabilities?

So this is a nice debugging feature that might catch a few hard system bugs but I'm a bit concerned that the GCC folks are touting it as a security feature if it's rarely going to be used in production code.

Demo

[pjf(at)gna.org]

Does anyone have a LiveCD of this stuff? ;-)

Fortran???

[CrayHill]

My guess is that they are using f2c (translating fortran to C first, then compiling), rather than integrating and updating g77. I don't expect this to match most native Fortran compilers for efficiency.

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.

More incompatibilities on the way?

[gvc]

The gcc team seem to have no respect for legacy code. Incompatible syntax changes and incompatible dynamic libraries make me dread every new release.

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.

Re:More incompatibilities on the way?

[gvc]

Yes, you've captured their attitude precisely.

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.

Compiler

[linguae]

Almost all open-source software is built with GCC, a compiler that converts a program's source code--the commands written by humans in high-level languages such as C--into the binary instructions a computer understands.

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

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

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.

Latest Fedora-development has gcc 4.0

[utamaru]

$ gcc --version
gcc (GCC) 4.0.0 20050310 (Red Hat 4.0.0-0.33)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I've noticed it compiles a bit faster and the binaries are a bit bigger aswell.

Re:Latest Fedora-development has gcc 4.0

[Pros_n_Cons]

Apparently users of other distros still haven't learned how to close their mouth until getting facts.
FC4 is not due for release for 4 months
If gcc development slips so does FC4
gcc 4 is ABI compatible with gcc 3.4
gcc 4 is ABI compatible with gcc 3.4
See above two statements.
This is Fedora releasing in June (possibly) not Red Hat's next release which will be a year and a half from now.

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.

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

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 ?

Re:GUI

[sconeu]

Damn!

That's: g++ -o myapp file1.cpp file2.cpp file3.cpp

Timeline?

[Matt Clare]

Anyone know when 4.0 will be ready for the distros?

3 monts? 6 months? a year ? forever?

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?

Re:Ahem.

[IamTheRealMike]

He can't, but he can probably judge the user cost better than a GCC developer can. And it's a huge cost.

Re:Ahem.

[Per Abrahamsen]

As devphil said, GCC support bug-compatible ABI's. The GCC people are not the people who should judge the user cost, the distributors are. They are the people in contact with the users, and should select which ABI version to use.

Re:PathScale... looks interesting...

[multipart]

Unless things have changed recently, their front end is derived from gcc 2.96 (which, as most of you know, does not actually exist), and their backend is the Pro64/Open64 Itanium compiler retargeted to AMD64. And Pro64 is itself mostly SGI's MIPSPro retargeted to Itanium. The PathScale team leader is also the former SGI MIPSPro compiler team leader (Fred Chow). MIPSPro rocks, and PathScale is also pretty good. The best part is that the compiler is GPL'ed (but only v2, and with a patent infringement clause that actually violates the GPL itself *sigh*),

Re:Nitpicking

[SlashThat]

I don't know when was that last time you're refering to, but all benchmarks I've seen in the last couple of years clearly show Intel's compiler superiority. The generated code was up to 3 times faster.

I just hope that GCC closes the gap with 4.0.

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?

[tap]

Incompatible syntax changes

Such as...?

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: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!

Included with Tiger.

[Anonymous Coward]

From Working with Xcode 2.0:

At the very core of the Xcode 2.0 toolchain is the GCC 4.0 compiler, the next generation of the industry-standard compiler. This new compiler contains a number of advanced optimization techniques that are designed to make your applications fly. The most significant of these is the move to Tree SSA (Single Static Assignment) from RTL (Register Transfer Language). Tree SSA is designed to be both language and target independent and allows a level of analysis and optimization that is impossible with RTL. This brings state-of-the-art optimization technology to GCC and to all of your Xcode projects.

It's bizarre watching Apple skate along the bleeding edge of the open-source world...

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:Performance on optimizations?

[winavr]

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.

The list of other front ends for GCC also include Cobol, Mercury, Modula-2, FLIM, Shakespeare, and GHDL. Note that all are in different states of development.

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?

Re:Major Features Dropped From GCC 4.0

[horza]

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.

Sounds like RMS is protecting gcc, good for him. Unless you have something more substantial than insinuated slander?

Phillip.

Re:Major Features Dropped From GCC 4.0

[Per Bothner]

The compiler server branch is as far as I know not being worked on. At least I han't done any work on it since I left Apple. I've done some vaguely related follow-on and cleanup-work, such as adding support for column numbers for declarations, expressions, and rtl. However, no work on the compile server branch itself. I haven't noticed anyone else working on it.

It's a shame, since I think the compile server has major potential - and not only in terms of improving compile speed. However, there is still a significant amount of work without a guaranteed payoff, and I guess Apple decided to spend its resources elsewhere. Also, various issues make it difficult for me to work much on the project.

g95 is more mature than gfortran

[beliavsky]

At present, there are numerous features of Fortran 95 that gfortran (the gcc Fortran 95 compiler) does not handle correctly. G95 http://www.g95.org/, from which gfortran forked, is closer to being a full Fortran compiler. One can search the Usenet group comp.lang.fortran to confirm these statements.

If you just want a free Fortran 95 compiler use g95. Bugs reported to Andy Vaught are usually fixed quickly, and fresh Linux compiler binaries are posted almost daily. If you want to participate in the development of a Fortran 95 compiler, gfortran is more democratic.

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

[Aardpig]

Anyone who mistook g95 for F95 would indeed be right in concluding fortran was a dated useless language.

Dude, g95 isn't yet completed. Why the hell would one expect it to be fully-functional? Got an axe to grind about the g95/gfortran fork?

My favorite parts of fortrans are that one cannot overflow a buffer

Rubbish, you can do just the same stupid things that you can with C. The difference is that Fortran can implement arrays without the need for pointers, and most Fortran compilers support decent (but very slow) bounds checking on these arrays.

RIP fortran95, killed by g95.

Again, this statement is misleading and meaningless. There are plenty of other mature Fortran 95 compilers on the market, and -- upon their completion -- g95 and gfortran will add to to the selection. How has g95 'killed' Fortran 95?

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

Re:Gcc killed fortran

[zerus]

Fortran, like it or not, is still the de-facto basis for the vast majority of engineering modelling programs. MCNP, SCALE, FLUENT, or basically any type of monte carlo calculation is going to be based off of fortran 77 and possibly written in F90 or F95. When I started as an undergrad, I refused to learn fortran saying that it was a dinosaur and outdated by every new programming language available; however, when you get into the real world, you'll notice that the guys that have been doing that stuff for 20+ years don't want to change so new codes will come out but will still be written in good ol' fortran. Needless to say, I know fortran not because I want to, but because it's a necessity as an engineer doing computational methods.

Re:Gcc killed fortran

[Salis]

I've programmed in other languages, but I find I get more done in less time using Fortran95. Why? I only code for scientific computing and I can give a rats ass about 'features' such as garbage collection, strange usage of pointers, etc etc that Fortran95 doesn't have.

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:How about support for older levels?

[Aardpig]

A start would be sticking to ISO C. If you can possibly avoid it, steer clear of writing code targetted at a specific compiler.

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:How about support for older levels?

[MattWillis]

Alas, from experience I can attest that usually this is your own fault for writing nonstandard code targetting some particular feature of gcc. The best thing you can do to your code is to make sure it compiles on multiple compilers. Listen to your compiler's warnings; you ignore them at your peril.

Can anyone elaborate on this LLVM v. RMS issue?

[jjn1056]

Is there anyone who knows what this LLVM issue is about? Anyone out there who is not just ranting incoherently about RMS?

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

Re:Nitpicking

[akihabara]

>> but Intel has actually been putting a fair bit of work into GCC

Bollocks. They only wrote some stuff to support IA64 because they were desperate and no-one else would.

It's supposedly a GPL bypass

[r00t]

LLVM is sort of a mostly-compiled form of a program.
(like preprocessed, but more work having been done)

If gcc can convert C to LLVM, and LLVM to native,
then you could replace either half with something
proprietary. You could add a proprietary middle
step that optimized LLVM code.

Devphil is libstdc++ maintainer

[charnov]

Just thought I would point out that Phil is one of the people who have been in charge of the libstdc++ (GNU Standard C++ Library) for a long time. I realise that no one is used to actual subject authorities on slashdot.

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:how LLVM would harm gcc

[kwoff]

It's the same reason that RMS avoided adding dynamic linking support (for example to be able to add elisp wrappers around C libraries) to GNU Emacs, whereas this apparently exists in XEmacs.

Re:GUI

[(void*)cheerio]

For me, *NIX is an IDE.

MyIDE = xterms + vim + grep + make + svn + man + the browser + diff + io redirection +....

It's not as polished as an IDE, not as cool. But you get to organize it any way your want.

And besides, considering most of my time is spent manipulating text, any IDE that doesn't have vim integrated in it is useless, at least to me.

(NB: if you like, you can subst emacs for vim in the above)

my guess

[jbellis]

LLVM is written in C++, and RMS has dictated "Only C shalt thou write for gcc."

Re:distcc and ccache is better than compile server

[Per Bothner]

Should one respond to half-truths and flame-bait from Anonymous Cowards?

Saying that distcc is "less error prone" is a meaningless statement since you're comparing distcc against an unfinished project. The compile server can work "even when preprocessor tricks are used" - give us credit for having thought about the issues, and having come up with solutions, albeit partially implemented and not necessarily optimal.

Your compile server makes a lot of assumptions that many popular projects break.
So what? As long as many projects can benefit from it. If some projects benefit, that would encourage other projects to clean up their header files, which would be a good thing in itself. (A side benefit of the compile server is that it encourages clean design.)

I agree discc is far simpler, and it will be challenging to engineer a compile server that can detect and recover from header files that aren't "clean", without the checks taking so much time we lose most of the benefit. It's essentially research, and there is no guarantee that it would justify the investment needed. But it does have good potential.

Note there are some limitations for distcc. First, of course it assumes you have multiple idle machines you can spread your compiles to. That may not be the case in a home environment or when travelling. Second, shipping pre-processed source code all over the place is quite expensive. Distcc doesn't save you time in preprocessing, optimizing, or code generation. All it helps with is parsing and semantic analysis, so the best it can give you is a modest constant-time improvement. By this I mean that if you have M files that include N header files each, the compile-time with distcc is O(M*N), but with the compile server it could potentially be O(M+N).

for loop inside a printf -- gcc does it

[r00t]

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

FS Delayed Allocation

[x2A]

Many modern filesystems use something called delayed allocation, so (eg, temp) files that are written and deleted shortly after, are removed from the write queue, and never actually make it to disk. I think I recall reading it coming to reiserfs a few years back. So the effect is that /tmp already is mounted in ram.

-2A

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.

Classic example of /. modding...

[SlashThat]

Wasn't meant to be a joke... I know they build GCC with GCC, but I don't suppose they could have built the front-end with GCC 4.0 yet, due to the bugs still present. So current speed up is probably based on compilation with GCC 3.4.


Don't know why I bother writing this, none's going to read it now...

C++ compilation speed

[Per Abrahamsen]

Well, if your C++ code has

#include <iostream>

and your C code has

#include <stdio.h>

chances is that it is also compiling an order of magnitude more code. Using precompiled headers should help in that case.

And if you are using templates, you are actually using a compile time language, which obviously will slow compilation down.

But they do claim C++ compilation is much faster with 4.0:

When compiling without optimizations (-O0), the C++ frontend is much faster than in any previous versions of GCC. Independent testers have measured speed-ups up to 25% in real-world production code, compared to the 3.4 family (which was already the fastest version to date). Upgrading from older versions might show even bigger improvements.

Personally, I don't care much. Development seem to be restricted by link time, for a well organized project. And I always compile with full optimization.