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

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

[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]

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

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

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.

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

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

Re:More incompatibilities on the way?

[gvc]

Yes, you've captured their attitude precisely.

But if faster has been decremented...

[SuperKendall]

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

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.

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?

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