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?

[Anonymous Coward]

This looks oddly familiar.

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?

[Anonymous Coward]

Wow. Cool! Thanks for your reply (I thought I was trolling)!

PS: Is OpenMP the nicest approach for this type of feature? I love the concept of threading-from the compiler - but always thought pragmas are kinda ugly.

Re:OpenMP?

[Anonymous Coward]

There has been some discussion of the this. Search the mailing list for the various sides. Scott Robert Ladd has some posted some things that you might want to read.

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)

Re:OpenMP?

[Anonymous Coward]

Highly niche. I'd prefer gcc made a decent compiler before screwing around with things like this.

Re:OpenMP?

[RupW]

I don't recognise "multipart" so I can't see who you really are, but -

If you're with GOMP, do you know what Scott Robert Ladd (a.k.a. ChaoticCoyote) is up to? He hasn't been here, or his blog; his website's down and he's been missed on the GCC list a few times.

Obviously everyone'll wish him all the best if he's moved on but can only hope nothing terrible's happened instead :-/

Re:OpenMP?

[Anonymous Coward]

Highly niche.

Not for the serious Fortran world. And in any case remember multicore is coming to PC desktops soon.

Re:OpenMP?

[Per Abrahamsen]

Problem is that OpenMI was created by people who knew a lot about paralelism, but nothing about language design. It is hard to add to the compiler without further obfuscating the code for everyone.

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

[lederhosen]

No, it really is _much_ slower to compile c++

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

[joto]

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

If you eat a lot of RAM, it will take some time to fill that RAM with interesting stuff, process it, and get even more interesting stuff out of it. And even now, gcc will happily eat 200MB for "modern C++" templatized source code.

Aggressive caching? How about ccache?

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

[drinkypoo]

ccache only helps on subsequent compiles of the same code, which is not very exciting to me since I don't generally compile the same version of something repeatedly.

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

[Anonymous Coward]

How are namespaces any different than packages?

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

[Profane MuthaFucka]

namespaces.don't.do.much.to.satisfy.some.people's. dot.fetish

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

[Anonymous Coward]

Java is ever more elegant, perhaps one reason it eclipses C++ in the general business environment.

You, sir, are the reason all of my business apps run so slow! Real coders use nuttin' butt C, ADA, and ASSembly. Java is cool (I like that self-modifying code), but mostly it's the kiddies who learned it in school who see it as God's gift to code monkeys. Personally I prefer Pascal to Java, but whatever floats your dinghy. I like my code to run fast even on slower computers.

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

[Anonymous Coward]

Namespaces::need::twice::as::many::seperator::char acters::and::are::harder::to::read::in::some::type faces::because::the::glyph::is::taller.

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

[Anonymous Coward]

You, sir, clearly haven't seen the memo about the JVM winnebago driven by the 300 pound XML chick.
Real coders may use real tools, but real sales and profits are made by jacking the hardware requirements an order of magnitude for an arguable improvement...somewhere.
XML begat RPC begat WS-* and it's still a right flog-ex. I can't wait to see the next 'savior technology' sent to redeem us from this baked situation.

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

[alan_d_post]

Yes, C++ takes bloody forever to compile (standard example: Mozilla). This is because C++ is a horrifically complex language, and uses textual inclusion of source code as a standard mechanism. For many applications, ocaml is a suitable replacement for C++. Your source code will be shorter, more correct, and compile much more quickly.

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

[Anonymous Coward]

Oh God yes.

Please, I know C++ is slower to compile than C but the compile speed of C++ has been degrading for so long now (at least since 2.9x).

Please, have mercy.

Improve the compile time!

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

[menace3society]

You can look at C++ doing everything with macro definitions. That is, one can overload function arguments, operators, and things, but the price for this is that the compiler has to translate all of these things that have the same name in code to things with different names in object files. Overloaded operators are typically pretty quick, since they don't involve much overhead, but things like templates slow compiling down a lot: it has to find every place where the function is called with different arg types, and create a "binary" function that appropriately changes the function and its instructions as necessary. So other, run-time-ish OO languages like Objective-C compile faster, but they do suffer a slight performance hit in comparison to C++. You pays your money and you takes your choice, I guess.

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

[Anonymous Coward]

Wow, it's quite an eye-opener...in 2005. Not only Java borrowed "generics" from C++, so did C#. The most curious combination is VC++ 2005 (still to come), in which you can use both C++ templates,...and VC++ generics, in managed code, of course.

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

[justin_saunders]

Duh!

Didn't you read the article? Just compile your compiler with GCC 4.0.

cheers,
j.

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

[Anonymous Coward]

That "final" keyword in Java is what drove me away from it. Yuck! It's so ugly!
Dork.

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

[Anonymous Coward]

All good advice (copied from someone else), but irrelevant to grandparent post. He said he put it in an include he uses for all of his home projects, not in header files for libraries he creates for others at work.
Or were you just karma-whoring?

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

[Anonymous Coward]

++Informative? ... so you want the informative mods before the comment is read?

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

[Anonymous Coward]

Generics in Java and C# are more borrowed from languages like ML (except for the syntax), and they're quite different from templates in C++, which is why they're called "generics", not "templates".

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

[Anonymous Coward]

The reason has more to do with GCC being unsophisticated in comparison to other C++ compilers, like Intel's and Microsoft's. The lack of support for precompiled headers also is a problem.

For most applications, O'Caml is a poor replacement for C++. Good luck developing shared libraries in O'Caml, using reflection, or building plugins without using a bytecode engine or an interpreter. Good luck getting decent performance out of anything that needs to use the full word length of a platform.

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

[nate nice]

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

One key difference that will never change and is important is C++ is weakly typed and Java is strongly typed. This means types are guaranteed at compile time where as in C++ you can do all types of great/terrible things.

Honestly, C++ and Java are really different languages. Sun designed Java so it had a similar general syntax to C++ but semantic things are much different in many regards. Also, once you go deeper into Java you see that only the base syntax is similar and it starts to diverge (for the better I think) deeper into the language.

Although I still prefer C++ as a general programming language but am leaning towards Java for some reason lately. Must be getting lazy!

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

[nihilogos]

Namespaces in the STL are what drove me from C++ in the first place

What namespaces? All STL classes are included in a single one called 'std'. And you can just write 'using namespace std' in the appropriate scope and be done with it.

Java is ever more elegant, perhaps one reason it eclipses C++ in the general business environment

I'm not sure the business environment has ever based its choices on elegance.

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

[aichpvee]

Change the type face and half your problems are solved. I'll be happy to accept my +informative moderation now.

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

[Anonymous Coward]

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

err.. was i the only one that saw 'C ADA('s) ASS'?

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

[Profane MuthaFucka]

If you're nesting namespaces in C++ like that, you are definitely doing something wrong.

But, it's par for the course in Java. 99% of the time in C++, you're just going one level and that's it.

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

[KhaZ]

return (1);

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

[sproctor]

What is so hard with developing shared libraries in O'Caml? I've used them, but never actually worked on them.

WRT performance, there's a nice comparison run by the Debian project at http://shootout.alioth.debian.org/great/ Why would getting good performance out of of things that require using the full word length on a platform be a problem? Sys.word_size gives the size of a word, and there are 32 and 64 bit modules.

I can't speak to reflection or building plugins as I've never had the reason to work with them using O'Caml.

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

[Anonymous Coward]

Except that all Java containers contain Objects and even with generics, a Container is a Container with auto-casts to Foo. This means that in Java you can do awful things with types that compile fine, look like they should work, and then throw exceptions at runtime.

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

[alan_d_post]

That's odd, using cl.exe for many years, compiling things seemed pretty slow to me. Of course, that was using VC++ 5, so perhaps it's gotten amazingly better.

Precompiled headers has always seemed to me like a brittle kludge, but hey, if they can get it to work, I guess I have no substantive complaint.

What would be an example of a software-libre for which plugins are vital?

What do you mean by reflection in the context of a C++ program?

For what tasks do you need to use the full word length, but not in an array?

And about run-time performance: ocaml is slower than C, but if you use STL with GCC, C++ is often even slower. And for many applications, performance isn't the most important thing -- correctness and programmer productivity are important too.

So no, I would not write a database or a kernel in ocaml, but why not (for example) a word processor?

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

[nate nice]

"...and then throw exceptions at runtime."

That's key though. Hopefully you're using try-catch-finally where as in C++ (although you can use this mechanism also) you generally end up with a segfault....if you're lucky.

But yes, Java (and really any language) allows for a programmer to be rather stupid. The key is how stupid do you have to be to be really stupid. The harder the better, obviously.

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

[Anonymous Coward]

FYI, the 'const' keyword was part of C from the first C standard, in 1989.

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

[Brandybuck]

On a single CPU system, the compile is still I/O heavy, so that a -j2 can make an appreciable difference in compile times. Another tip is to mount /tmp on a ramdisk, or at least mount it on a different disk drive than the source.

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

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

[alan_d_post]

Why would getting good performance out of of things that require using the full word length on a platform be a problem?

I believe the issue the poster was referring to was that unboxed integers in ocaml are one bit smaller than the equivalent C integer. If you want a real word-sized integer, it needs to be wrapped up for the GC (aka "boxed"). Though an array of such values only needs to be wrapped up once, so this is only an issue for using word-sized integers on their own.

But I'm not convinced that this is a serious problem in practice.

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

[chgros]

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.
You're quite right, and the main reason is the quantity of headers, containing templates: templates usually have their code inside the headers, so if you use STL or boost or similar, each of your file will be preprocessed to a file 100000 lines long, with a lot of code that's hard (slow) to compile.
I believe gcc has precompiled headers since 3.4, which should improve things a lot (e.g. Visual Studio compiles very fast with pch), but I haven't tried them yet.

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

[Malc]

Eh: sorry I wasn't clear. I wasn't referring to C builds being faster than C++, but rather GCC's space and speed performance in general. I wouldn't expect C++ compilation to be as quick as C ;)

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

[Anonymous Coward]

does GCC support pre-compiled headers now?

Yes. I think they were introduced in 3.4, if my memory serves me.

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

[Anonymous Coward]

No, you're missing the point. Namespaces are in C++ to support large projects which might have the same name in multiple namespaces. "using namespace name" is the worst advice you can give to a beginning C++ programmer because it doesn't support any form of clash resolution.

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

[Viol8]

"I believe gcc has precompiled headers since 3.4,"

Thats not always a good thing. Sometimes you need to view header source to get info that simply isn't in the man pages, eg the type of some variable or the default value of a parameter.

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

[Anonymous Coward]

Bla bla bla C++ fanboy excuses.

Why is Microsoft Visual C++ so much faster at compiling then? (Not to mention creates just as fast code)

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

[mzieg]

Part of my job is to teach fresh CompSci graduates the difference between "college programming" and "real-world programming." Entry-level C++ programmers might look at his post and think, "oh, that must be a good idea, because in one shot it makes all those compiler errors go away." That kind of misinformation makes my job harder.

If you see a bad practice documented anywhere, why not take a second to refute it, or at least provide alternatives? "Every drop raises the sea," and all that. If "teaching" equals "whoring" where you come from, then I wouldn't want to live there.

Isn't that what open-source contributions are all about? Isn't that what this thread is about? People providing C++ tools free-of-charge to a world of users. I'm sorry you considered it off-topic to relay C++ best-practices in a discussion about C++ compilers.

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

[FedeTXF]

Compiling is a CPU intensive task (al least when I compile the linux kernel), so the thread context switch will make you spend more time compared to a single thread. Specially if you have 4 or more threads. I had an IO intensive task (reading 100,000 image files form disk and adding data about them to a DB) and with 2 threads (half images each) it took longer then with 1. With more threads it took even longer. When I added a CPU intensive task (decompressing the JPEG and GIF images) it took even longer but still the threaded version was slower. I had plenty of ram and only 1 CPU.

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

[Ripat]

If you want to speed up C++ compiletimes you should take a look at using precompiled headers. Be careful when you use this technique together with ccache though since they doesn't seem to work well together.

Take a look here: http://www.linuxquestions.org/questions/showthread .php?s=&threadid=292688

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

[arkanes]

If you're getting segfaults when you cast in C++ you need to smack yourself. dynamic_cast is there for a reason.

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

[Anonymous Coward]

That's why in Visual Studio you have precompiled headers as well as source code for browsing code for debugging.

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

[Rei]

It's the best advice you can give to someone whose biggest problem with the language is having to deal with namespaces. Sure, if you're making a library that others will be including you don't want to do that, for the include files of the library, but that's hardly a general case situation. In most cases, "using namespace std" is harmless.

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

[chgros]

Thats not always a good thing. Sometimes you need to view header source to get info that simply isn't in the man pages, eg the type of some variable or the default value of a parameter.
Precompiled header != "binary-only" header
Usually you do the precompilation yourself, you just don't need to do it for every single file you compile.

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

[Anonymous Coward]

BTW, does GCC support pre-compiled headers now?

Yes but they're fairly limited. AFAICT, only the first #include in a given file may be precompiled, among other restrictions.

Better than nothing, but not on par with other compilers yet.

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

[jaavaaguru]

So where does Perl fit in?

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

[jgrahn]

One key difference that will never change and is important is C++ is weakly typed and Java is strongly typed.

People keep saying this, and I fail to understand why. C++ has a few implicit conversions: bool/integers, different integers to each other, char/integer, and one-directional between enums/integers and std::strings/const char *. And probably some more. That's a tiny, tiny fraction of all types used in your typical C++ program, and it's IMHO not enough reason to call the language "weakly typed" -- if this phrase has a meaning at all.

This means types are guaranteed at compile time where as in C++ you can do all types of great/terrible things.

Some of that is actually more common in Java than in C++, I think -- casting up from type Object to the type you think is right, and catch any problems at runtime.

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

[jgrahn]

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

Yes, const is immensely useful. It's compiler-enforced documentation: "Hi, ny name is foo and I'm a function. I take this terribly complicated object as a parameter, but I don't intend to change it one bit, and I can prove it".

But it's not new in C99. It's in the C language since 1989. Just look at your not-exclusively-C99 <string.h> for examples.

If memory serves me right, it wasn't introduced into C until early C++ implementations had played around with it and shown that it worked, though.

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

[Gr8Apes]

Go back in time when the STL was still under development. The namespaces were first seriously used with the STL, and the compilers I was using on the SGI box were unable to handle the resulting 255+ character munged namespaces.

I'm not sure the business environment has ever based its choices on elegance.

I'd have to agree with you there - COBOL would finish that argument. ;)

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

[cakoose]

One key difference that will never change and is important is C++ is weakly typed and Java is strongly typed. This means types are guaranteed at compile time where as in C++ you can do all types of great/terrible things.

I realize that a lot of people say this, but I think you mean "unsafe" rather than "weakly typed." The C++ type system is rather powerful, actually; much more powerful than the Java type system before generics. Java's runtime guarantee of type integrity just means it is a "safe" language/runtime.

I suppose that you could say that type safety isn't strictly enforced by C++ compilers, but this isn't the case for Java either. Though the overall integrity of the VM-managed data is maintained through dynamic checks, Java lets you do a lot of stupid things with types.

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

[cakoose]

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

Compiling is a CPU intensive task (al least when I compile the linux kernel), so the thread context switch will make you spend more time compared to a single thread [blah, blah, blah]

Try it. It's faster.

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

[Anonymous Coward]

GCC 4.0 compiles C++ code 25% faster than 3.4.x which previously held the GCC C++ compiling speed record.

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

[Rei]

The other possibility is that your code was always broken but was simply not crashing under the old gcc. Did you investigate the bugs? It sounds like memory leaks.

Re:C++ compiler

[pchan-]

I don't care if it compiles any faster, just as long as it compiles correctly.

It goes without saying that correctness is most important. A compiler that doesn't compile correctly is worthless. Having said that, if I'm working on a big project and a compile takes one minute instead of two, it will save me a couple of workdays of wasted time by my thousandth compilation.

Re:C++ compiler

[sketerpot]

A compiler that doesn't compile correctly is worthless.

Show me a compiler without bugs, and then I'll concede that you aren't dismissing all compilers as "worthless".

Re:C++ compiler

[Anonymous Coward]

> GCC ... 3.4.x ... previously held the GCC C++
> compiling speed record.

You got a link to any stats to back that up? According to my stats 2.95 holds the compile time record and GCC has been going downhill since then.

Am I wrong?

Re:C++ compiler

[Anonymous Coward]

Sadly, some Gentoo users seem to think just that.

"If I recompile my compiler with --fucking-stupid-but-I-think-it-makes-it-fast flag will make my programs run faster!"

Lots of stuff to love about Gentoo. Hate some of the community.

Re:C++ compiler

[vsprintf]

The other possibility is that your code was always broken but was simply not crashing under the old gcc. Did you investigate the bugs? It sounds like memory leaks.

The particular piece of code I'm talking about has worked for years under various *nix systems. Purify says it's fine. Would it make any difference if I ran valgrind and came up with exactly the same results? The only problem came from one gcc patch. You still think it's broken code with memory leaks? That's what I love about the Slashdot help desk: Blame it on the messenger. It's the same way at work. :)

Re:C++ compiler

[IWannaBeAnAC]

Ok, the funny mod is, well, funny, but it is actually quite true!

Re:C++ compiler

[Anonymous Coward]

The new parser was in 3.4.

Re:C++ compiler

[akihabara]

No, you're spot on. And 4.0 is not really any faster than 3.4.

Re:C++ compiler

[vsprintf]

It goes without saying that correctness is most important. A compiler that doesn't compile correctly is worthless. Having said that, if I'm working on a big project and a compile takes one minute instead of two, it will save me a couple of workdays of wasted time by my thousandth compilation.

Okay. Sure, all things being equal, faster is better if the end result is the correct expected end product. Recent experiences with gcc (under Red Hat at least) lead me to believe that the promised faster/better/smaller results may not work with non-trivial programs. In that case, gimme that ol' slow-time religion every time - just make it work.

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

[okigan]

If you dig a bit more from the above link you find this .

Which in short shows that execution time is exactly where it was a year ago. I can understand it's an overall test which does not take into account specifics, but it also shows that "entire realm of open-source software could get a performance boost" will not going to happen (makes me think that that "could" is there on purpose).

Another clue is that the article begins with "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". First reaction: "Doh!, i knew that", and at this point it hits me, today is Monday and as you know magazines (online or not) must publish articles to survive.

What's a bit more disappointing that old-trusty /. swallows the bait, if you dare to check gcc website you'll notice that there are no changes as there are no news (real people are actually working and update it when job is done).

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

[IWannaBeAnAC]

Read the comment again: the AC is saying that gcc will compile programs faster if it is itself built with gcc 4.0. That is a completely correct statement.

Of course, gcc 4.0 should produce identical code no matter what compiler was used to bootstrap it, but I don't think that is what the comment was about.

Re:C++ compiler

[lorien420]

Qt/KDE programs are actually compiled twice. Qt code is not valid C++, and it must be translated into something that a C++ compiler can handle through the MOC compiler. This is why it's so slow.

Re:C++ compiler

[Piquan]

So far, so good, but I'd really appreciate it if the gcc guys would get it right before releasing stuff.

The gcc guys are often better about this than the Red Hat guys. Red Hat has gained a certain amount of notoriety by releasing broken patches to the compiler toolchain.

Re:C++ compiler

[Rei]

All I said is that it sounds like a memory leak. Talk about shooting the messenger... And yes, broken code *can* run just fine on some compilers and not others. Other possibilities in addition to memory leaks include things like reading from uninitialized memory.

Some compilers and versions may zero your memory or select different chunks of it. Some compilers allocate a little extra padding at the end of arrays while others don't. Etc. All I ask is that you stop and consider the possibility that it's your code because - and I know you don't want to hear this - but it probably is your code.

Re:C++ compiler

[multipart]

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

Re:C++ compiler

[Anonymous Coward]

The Red Hat guys pretty much are the GCC guys these days, doing the bulk of the development.

Re:C++ compiler

[x2A]

The usual build process for GCC has actually been to do this - ie, build once, then rebuild using the newly built compiler (and I think there's a third phase too?). So the final build is a compiler built using itself, so you do get that full speed benefit :-)

-2A

Re:C++ compiler

[Anonymous Coward]

A make bootstrap for Gcc produces a three stage compile:

1. Using the system-provided C compiler, compile a very simple version of gcc. The system provided compiler may not be Gcc. It may not even be fully ANSI compliant.
2. Using the tiny Gcc built in stage 1, built a complete version of Gcc.
3. Rebuild Gcc using the complete Gcc built in stage 2. This is done to get the best possible optimisation; the final Gcc binary can be optimised by Gcc itself.

Re:C++ compiler

[Xiaran]

I agree with Rei here(but only if your name is a reference to Evangelion). Usually its the code. Ive found I think about 3 bugs in compilers generating dodgey code. One was in gcc a long long time ago, another was in Watcom 10.X and the third was in MSVC which was only fixable if you turned of optimisation(to be fair... MSVC used to have the buggiest optimisation ever back in the day).

As to the resulting new build being much smaller. Could that be the old "usuing new shared libs for mysterious reason and having those new(patched you said) libs being buggy" deal ?

Re:C++ compiler

[sjames]

Of course, gcc 4.0 should produce identical code no matter what compiler was used to bootstrap it, but I don't think that is what the comment was about.

It comes down to the goals of each step. The initial compiler could be nearly anything and may support only a subset of C. It's optomizations may be broken. So, First a very simple stripped down minimal gcc is built without any optomization capability in order to minimize the chances of the build failing with an unknown compiler.

That compiler is known to be able to build the full gcc compiler without fail, so it then compiles a full version of gcc which has all of the optomization features included, but it's own binary uses none of it. It will produce fully optomized binaries itself, but will run slow.

So, finally, that version compiles the full gcc again, but with optomizations turned on. The final gcc produces code no better or worse than the one that compiled it, but it runs faster.

Re:C++ compiler

[vsprintf]

All I ask is that you stop and consider the possibility that it's your code because - and I know you don't want to hear this - but it probably is your code.

I didn't spend over twenty years in this craft without learning that 99.9% of problems with my code is my code. I have also learned to identify the 0.1% that are not my fault, and I'm really surprised not to have had more problems with gcc given its infamous reputation for bugs. As I said, I love the Slashdot help desk. :)

Re:C++ compiler

[vsprintf]

Red Hat has gained a certain amount of notoriety by releasing broken patches to the compiler toolchain.

Hmm. That's something I hadn't heard and a possibility I hadn't considered.

Re:C++ compiler

[Piquan]

One data point you can use is the mplayer FAQ.

Re:C++ compiler

[Per Abrahamsen]

I see Code Sourcery and Apple adresses at the development lists as often as Red Hat adresses.

Re:C++ compiler

[Per Abrahamsen]

You probably also have noticed by now that 99% of the people who *claim* in public fora that the compiler is broken actually have broken code themselves. Often including people like Linus.

You might be the other 1%, but blaiming the /. readers for suggesting that maybe you belong to the 99% case is silly.

Re:C++ compiler

[Per Abrahamsen]

Valgrind and purify should find uninitialized memory.

However, the new aliasing rules can give rather subtle bugs like that. That has hit the Linux kernel

Re:C++ compiler

[Anonymous Coward]

I see Code Sourcery and Apple adresses at the development lists as often as Red Hat adresses.

And a lot of the people with Apple addresses used to have Red Hat addresses.

Re:C++ compiler

[Anonymous Coward]

Hmm. That's something I hadn't heard and a possibility I hadn't considered.

That's because it's twaddle.

Red Hat chose to base a distribution on a CVS version of GCC. It was essentially CVS GCC plus the subreg patch for Sparc64. It *WAS NOT* broken per-se - most problems arose because a lot of code violated the C standard's aliasing rules. You could get around this with -fno-strict-aliasing, or you could fix your code.

Obviously in the GPL world Red Hat can fork and release whatever they like as long as they're willing to support it. The one thing they did wrong, IMO, was call it GCC 2.96 without the GCC people's permission to use 2.96. There was nothing wrong with the compiler, almost everyone who whinged about it had broken code.

Re:C++ compiler

[Anonymous Coward]

apparently in those 20 years you became smug and lost all capabilities of dealing with others.

heres a tip: never start a sentance with "i didnt spend 20 years of my life..."

no one takes you seriousely because you come off as an asshole who "knows it all"

Re:C++ compiler

[fizbin]

If you have the time and the gcc compiler that's breaking things, try compiling your code with both -fstrict-aliasing and -fno-strict-aliasing. My bet is that -fno-strict-aliasing will produce code that works. (and conversely, if the "correct" compiler is version 2.95.2 or later, using -fstrict-aliasing will produce a broken executeable)

The thing is that some interesting optimization strategies were introduced in gcc during the 2.95.1 to 2.95.3 period. These strategies are perfectly valid things for a compiler to do to the code according to the C spec, but because they can be tricky to work out were not done in almost every other C compiler out there.

-fno-strict-aliasing explicitly turns these optimizations off. (by telling the compiler that your code might do some certain things which are against the C spec but still very common in practice)

-fstrict-aliasing (available in gcc 2.95.2 onwards) turns these optimizations on by asking the compiler to be clever about which pieces of memory can never be pointed to by pointers of a certain type.

I don't completely understand what in the C spec (which, I'll admit, I've never read) is being violated by code that produces bad results with -fstrict-aliasing, but the symptom (data wandering to a memory location it shouldn't be in) sounds very much like other strict-alias bugs I've heard about.

Re:C++ compiler

[cimetmc]

The alias issue results from casting pointers from one type to another.
The background is the following:
pointers make it very difficult for a compiler to optimize redundant memory loads or stores. In fact, when a program access data through a pointer, the compiler may not know what other variable gets modified by the pointer access. So all variables for which the compiler cannot prove that they are not accessed through the pointer cannot be kept in registers accross pointer operations.
Because this is so penalizing to optimizations, at some point, the C standard has introduced stricter rules as to what variables can be modified by what pointer operations. This essentially boils down to the rule that a pointer access through a certain type (let's say int) is not allowed to access a memory location that is associated with a variable of a different kind (let's say float). So if you take the address of a floating point variable, and store that address in an integer pointer and then access the memory through that integer pointer, the compiler will not notice that in fact the floating point variable gets modified. So the compiler can decide to keep the floating point variable in a register and any access through the integer pointer may not change the floating point variable if you compile with optimization enabled and with strict aliasing.
The strict aliasing rules are implemented in all GCC 2.95 and éater versions, but for GCC 2.95, the default options used changed between the different releases based on long and heated discussions whether this kind of optimization should be enabled or disabled by default. So there was no major code change between GCC 2.95.1 and 2.95.3, but rather just the default optimization options changed.

Marcel

Re:C++ compiler

[vsprintf]

You probably also have noticed by now that 99% of the people who *claim* in public fora that the compiler is broken actually have broken code themselves.

I guess that would depend on your definition of "broken code". There have been numerous arguments about correct implementations of *the standard* and breaking working code, but that's another discussion.

You might be the other 1%, but blaiming the /. readers for suggesting that maybe you belong to the 99% case is silly.

If you accept programming advice from 99% of the readers on Slashdot, that's silly. I've also previously identified a couple of bugs in the MIPSPro compiler after exhausting the possibilities with my own code. The admins didn't believe me either until SGI admitted the problems. I'm getting used to the catcalls and thinly veiled insults. (I probably shouldn't be saying "compiler" when really talking about the whole compiler package, but it's standard usage.)

Re:C++ compiler

[vsprintf]

apparently in those 20 years you became smug and lost all capabilities of dealing with others.

Thanks for notifying me. I'll immediately advise the wife, kids, other family, and all the people at work.

heres a tip: never start a sentance with "i didnt spend 20 years of my life..."

Boy, am I ever glad I didn't write that then. I suggest you read the relevant sentence; it's an admission of fallibility. Here's a tip: Don't learn how to spell on Slashdot - you won't be taken seriously.

no one takes you seriousely because you come off as an asshole who "knows it all"

Nobody who actually read the whole comment would think that, but even so it's still better than being a pontificating rectum who can't spell "here's", "sentence", "seriously", or use the proper form of "capability". You probably need to work on your communication skills.

Re:C++ compiler

[vsprintf]

If you have the time and the gcc compiler that's breaking things, try compiling your code with both -fstrict-aliasing and -fno-strict-aliasing. My bet is that -fno-strict-aliasing will produce code that works. (and conversely, if the "correct" compiler is version 2.95.2 or later, using -fstrict-aliasing will produce a broken executeable)

This is interesting since there is a linked library that uses some unions and a related cast to get a string in one of the affected programs (although we're talking about a single gcc 3.2.3 patch). There is no way I'll be able to recompile and test that stuff within the next two weeks (new release in the works), but I have printed out your comment and will keep it in view. After the next release is done, I'll try to test it. Maybe I'll have to retract my remarks about the Slashdot help desk. :) Thanks.

Re:C++ compiler

[vsprintf]

This is the second time someone has responded with an indication that the problem could be a certain flag. If there's a problem here you could help document, then why respond as AC, which will get little credence? And again, there is the question of proper standard implementation versus breaking working code.

Ahhhhh... Time to start compiling all overagain...

[Anonymous Coward]

To think I just got GCC 3.4.3 cross-compiling for my AVR and Coldfire chips, and I get to start all over again.

Progress. I love it!

Shockingly better?

[Anonymous Coward]

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

Re:Shockingly better?

[bill_mcgonigle]

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

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

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

Re:Shockingly better?

[multipart]

See also this older LWN article for an explanation - kind of- of what SSA is: http://lwn.net/Articles/84888/

Re:Shockingly better?

[Anonymous Coward]

SSA is an interesting representation to do optimizations on. Each "variable" is only assigned to from one static place in the program, making use-def chains easier to reason about. SSAPRE (Partial-Redundancy Elimination) is one of the most general optimizations, and has some big advantages (and some disadvantages) when compared to the old-style bit-vector PREs. One big advantage is you don't have to implement different local and global versions of your PRE to get decent performance.

Some languages can be parsed directly into SSA form fairly efficiently; however, most compilers will probably do a pass to convert their own parse tree format into SSA so they can optimize in SSA form. They might have to convert it back afterwards though. I think the first versions of GCC to do optimizations on an SSA form used to convert back and forth a few times.

It would be nice to see a mainstream compiler that does ALL its optimizations in SSA form (and no, the SGI compiler doesn't count)..

Re:Shockingly better?

[Anonymous Coward]

Would it have killed you to make it a link? (BTW, your link doesn't work.

Re:Shockingly better?

[Anonymous Coward]

You can't do ALL optimizations in SSA form since it does not provide ALL information you need. The SSA chapter in "The compiler design handbook" talks about what can and what can't be optimized in SSA.

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

[0racle]

So... GCC4 has a propolice look-a-like.

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

[Trillan]

I dunno. I think if a programmer has a misunderstanding of security like that I'd rather have a slower, more trustworthy program! But yes, competent programmers would be best.

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

[fitten]

What about valgrind? (I guess mudflap will work everywhere and valgrind is x86 is the advantage.) I use valgrind all the time, it's a great tool.

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

[Tim Browse]

Hmm...it's hard to tell from that wiki info, but I would have thought that something that detects buffer overrun exploits is exactly the kind of thing you'd want to leave turned on in the release version. I mean, usually there aren't many crackers in your test labs. They're usually found on the big wide internet.

Unless it's a more general memory corruption debug library.

Re:Mudflap

[RetroGeek]

Where did I say that?

The testing environment should be as close as possible to the production environment.

Remember, developers only fix the problems they know about.

Re:Mudflap

[Anonymous Coward]

Valgrind is an entire virtual machine. Massive overkill for simple bounded-pointer guard implementation. You don't run valgrind in production.

Re:Mudflap

[dusanv]

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 am getting sick when C-hating posts like this one get modded up. Seems to be happening all the time lately. I'm starting to meta-mod again.

Re:Mudflap

[TelJanin]

Mudflap tells you when you've done something stupid, so you can fix it. It's not there to fix things for you without your knowledge.

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

[Anonymous Coward]

Don't blame the tool, blame those misusing the tool. Every tool has it's place, and unfortunatly any tool we may see as a fix all is usually useless in one context or another.

Re:Mudflap

[smittyoneeach]

Big bottom
Big bottom
Talk about Mudflaps
Valgrind's got 'em...
</spinal tap moment>

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

[downbad]

There is no mudflap website...

Re:Mudflap

[dusanv]

Good googling skillz! That is slow. But it's only pre-release software and those are synthetic benchmarks. Let's see what happens. In any case, if you think C is bad, nobody (me especially) is stopping you from using whatever language you want...

Re:Mudflap

[FlyByPC]

What next, a ShotgunRack class?

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]

Use your mouse, follow the links in the Slashdot story, and you will come to a web site and a paper describing the Mudflap implementation. I know it's pretty uncommon to actually follow the links from a Slashdot story before commenting, but you can do it.

Re:Mudflap

[Greyfox]

And I'm getting sick of bozos like you implying that simply changing the language we use will suddenly make software secure. Because for every shop that switches from C to java, there's some fuckwit using static members to store username and password in the webapp's user authentication code.

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

[idlake]

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.

True, which is why I also still use C occasionally. But being widely used doesn't make it a good design.

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.

That has always been a myth. C++ has been designed from the start not to impose any overhead above and beyond C: you only pay for what you use.

I still prefer C++ to the newer languages, along with the occasional assembler block for super critical performance code.

Well, unlike C, in C++, at least it is possible to write reasonably safe code if you are meticulous about data abstraction. That's an OK trade-off for small, single programmer projects, but it introduces lots of extra management hassles for larger projects--you have to be constantly alert that developers don't start using unsafe or dangerous constructs.

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.

There have been many such languages. Look at Modula-3, Sather, or Oberon, for example. Modula-2, Ada, CLU, Cedar, Mesa, and Object Pascal also were far safer than C (although they had some other problems/limitations).

Java, in many ways, was a step back, because, while it supports safety, it fails to support systems programming. C# as a language combines runtime safety with the ability to perform low-level manipulations; unfortunately, its CLR/CLI-based implementations are bloated and complex. Let's keep our fingers crossed for a gccsharp compiler.

Re:Mudflap

[Panaflex]

Just a few ideas...

One really easy thing you can do to extend C/C++ is use a garbage collector (even ObjC I hear has a port).

I have successfully benched the Boehm GC in a largish (100k LOC) threaded SOAP application server written in C, with the degredation being only 3%.

And, in fact, since our code enforced strict memory managemet (and thus lots of overhead) - I would imagine that a less strict management scheem would be quite a bit faster.. i.e. allocate, use, forget.

Personally, I would love a native C# compiler.. no JIT. I understand the benifits of JIT, but in reality those benifits are a tradeoff for being able to just distribute an application without a 20MByte download to run it.

Pan

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

[downbad]

Buddy, that is not a website. That's an unprotected wiki page, and the vast majority of its content is command like options.

Re:Mudflap

[ltbarcly]

nobody (me especially) is stopping you from using whatever language you want...

So long as he is the sole propriator of whatever projects he works on.

And since most employed programmers have to work with, you know, other people and code that is already written, there is someone who is making him use C. But when he sits down at night and works on his magnum opus, he's perfectly free to use any language he wants... as long as he does it by himself.

Re:Mudflap

[ltbarcly]

Oh, I forgot to point out that your post is equivelent to "Who knows what the future will bring, just because there is strong evidence that what you say is true, it MIGHT turn out different, and you can always use something else so don't say bad things about C."

"The sky probably will be blue tomorrow, but who knows let's wait and see before we make any hasty judgements. And just because there are serious problems with fossil fuels, nobody is making you use them so they're ok after all."

Re:Mudflap

[rs79]

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

No, that's where it came from not where it's going.

If C goes away people will have to use assembly instead. It's not going anywhere. Mutations of it. like C++ may come and go...

Interestingly there were two langauages that came out of the Bell Labs post C era. Muttey Hill did C++ and Napierville did C+@ (pronounced "Cat"). The Napierville guys claimed "the east code boys never did understand objects properly".

The langauge ended up in the hands of the guy that ran ihnpss.UUCP. BS was good armerketing.

The C+@ compiler, written in C+@, fits on a floppy. I have a copy here someplace.

Re:Mudflap

[Anonymous Coward]

Since it apparently exceeds your mental capacity to follow a single link to a page that references a PDF (under "Further Reading"), here is the link:

http://gcc.fyxm.net/summit/2003/mudflap.pdf

The benchmarks are on page 63 (which is the 7th page inside the PDF).

Re:Mudflap

[Anonymous Coward]

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.

Hm, is there anything stopping an implementation from making pointers twice as large as a memory address? Then you could use a base and an offset, storing the array size before the base of the array. (You can certainly simulate this in C++) It would hurt performance, but no more than any other method for checked pointers.

The only real problem I see with this sort of this is that there's a lot of code that assumes that pointers are really fast. Changing that doesn't break the language, it just breaks how people traditionally use it.

Re:Mudflap

[Brandybuck]

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.

I've used some of those languages, and a few others besides. But I'm still waiting for one that will compile down to native machine code without the overhead of a massive runtime library. As an embedded developer I don't have the option of writing bloatware.

Re:Mudflap

[Anonymous Coward]

Hm, is there anything stopping an implementation from making pointers twice as large as a memory address?

That is within ANSI specs (that's why I said "for practical purposes") and people have tried such implementations, but they don't work well: they are far slower than other "safe pointer" implementations, and they break backwards compatibility.

You can certainly simulate this in C++

Yes, there was a company in the late 80's/early 90's that sold a preprocessor transforming pointers into such smart pointers in order to give you runtime safety. They were killed by Purify and tools like that because those tools just work better.

It would hurt performance, but no more than any other method for checked pointers.

It actually hurts performance far more than other, better methods for checked pointers.

But all of those are just covering up symptoms. The real problem is that C uses "pointer" to stand for many different kinds of data types that happen to have the same representation. That means that a simple call-by-reference or array access pays the same price (in safety or speed) as a pointer into the middle of an array. The way to fix that is to introduce multiple different pointer types (like Cyclone), but you can't do that backwards-compatibly.

Re:Mudflap

[Anonymous Coward]

Java has an embedded version with a tiny runtime library, and it is being used extensively for embedded systems.

In any case, Java isn't your only choice (and probably not even a very good one). Modula-2 and Ada are other classic choices for embedded development, and there are lots of other languages for embedded systems with long traditions and significant user communities.

Re:Mudflap

[dunkelfalke]

if you are into win32 programming, take delphi. great language, great safety, fast code

Re:Mudflap

[Anonymous Coward]

And I'm getting sick of bozos like you implying that simply changing the language we use will suddenly make software secure. Because for every shop that switches from C to java, there's some fuckwit using static members to store username and password in the webapp's user authentication code.

We're not clamining that. All the classic mistakes will still be there. We are claiming though that making a C program secure is hard. You have to be an expert not to screw up. And if you slip just slightly, you end up with an exploitable condition. Just look at all the libraries that are plagued by security problems.

That's not true of modern languages such as Erlang to pick just one example. You really have to be ignorant or make an honest to god mistake to screw up.

Not all interfaces are created equal. Whether they be programming languages or aircraft cockpits.

Re:Mudflap

[yRabbit]

"then switched off for finished products."
If someone's goal is to turn Mudflap off in the final version of their program, um, I certainly hope they turn it off while they're still in the "test version" stage, you know?
That way they can actually try to catch their buffer overruns, instead of suddenly having them show up in the "finished product" because they turned the extra security off for it...

Re:Mudflap

[Anonymous Coward]

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.

Are you just talking about C programmers now, or the entire FSF? :-)

Re:Mudflap

[Anonymous Coward]

That doesn't solve the problems with the C language. Read the excellent papers on Boehm GC and it will tell you plenty about limitations in it due to the way C works.

Secondly, a good language should have a GC, yes. Patching a GC on to C solves that problem, but leave so many other problems unsolved.

Re:Mudflap

[Ed Avis]

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.

Interesting... can you give some examples of the extra overhead? C++ advocates (including Stroustrup) usually claim that apart from the runtime support for exceptions, which can be turned off with many compilers, C++ has the same minimum overhead as C.

Re:Mudflap

[Anonymous Coward]

Two Words.....

Objective C

Oh Wait!..is C a word?

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.

Re:Mudflap

[Anonymous Coward]

I've used some of those languages, and a few others besides. But I'm still waiting for one that will compile down to native machine code without the overhead of a massive runtime library. As an embedded developer I don't have the option of writing bloatware.

Ok. Use Java and compile to native with GCJ (which supports quite a few embedded platforms). Eliminate anything you don't need from the class library. (or don't use it at all)

It's been done.

Re:Mudflap

[Anonymous Coward]

> There are many places where C is still used

There are many places where DOS is used. I have zero problems in relegating it to the ashcan of history.

Re:Mudflap

[Greyfox]

Writing secure code in C isn't the hardest thing to do in this industry. In general, programming is hard. Coming up with a flexible, robust and useful library is hard. Sun's implication is that programming in Java is easy and secure and that if you switch your shop over to Java then you will be able to replace all of your high paid programmers with chimpanzees. This is still not the case.

My concern is that if you lower the bar, so to speak, then the next generation of programmers will be more mediocre. Although in truth it would be quite a stretch to make a more mediocre generation of programmers. Rather, why not teach C and the good practices in C that let you avoid those security issues? A lot of those same practises map quite well to other languages too, and you'll end up with programmers who can actually deal with full expressive freedom when it's handed to them.

Re:Mudflap

[DimGeo]

Do you have a link or something? I'd like to have a look at it, but I just don't know how to fool google do find it for me :( .

Re:Mudflap

[Anonymous Coward]

Well, that was hasty posting. I found something: here.

Re:Mudflap

[yason]

Many bounds-checking and memory-leak tools have been obsoleted by Valgrind. In my opinion, it's truly great piece of software and when working on PPC, I often find it worth the effort to make sure my code compiles on x86 too just to get it running on Valgrind.

Re:Mudflap

[stripes]

Interesting... can you give some examples of the extra overhead? C++ advocates (including Stroustrup) usually claim that apart from the runtime support for exceptions, which can be turned off with many compilers, C++ has the same minimum overhead as C.

I can't speak for idlike, but I can't think of any C++ overhead that isn't related to virtual functions. If you avoid them, you avoid the overhead. You also avoid most of C++ though. Oh, and to a smaller extent the same is true of templates, but replace "overhead" with "code bloat", and "debugger nightmares", and "symbol table overhead".

Virtual functions with normal run time systems give you a pointer's worth of overhead per allocated object (class/union/struct) that has a virtual function, and then another pointer or more (function pointer, or maybe a jump instruction plus a target address) per defined object type. Then there is a little more overhead for typeid support and similar things (structs/classes with no virtual functions have no overhead, and also no typeid support).

If you were going to code up virtual pointer like things in C you would probably get the same sort of overhead, even if you just keep a "type byte" in the object, and then use a switch to manage the dispatch. If you do that more then once you likely have more overhead then the normal C++ way.

However normal C coding style won't lead you to doing that very much. Normal C++ coding style will lead you to doing a fair bit of that sort of thing. You can't really blame the language for that.

As for templates, I firmly believe that C++ could do a much better job there (for example recognizing that some templates or even template functions only vary depending on the size of a type, and using the same expansion for anything with the same sizes). So the code bloat might just go away with smarter compilers.

Personally I use C++ rather then C when given the choice, and if performance is likely to be a big issue I try to be careful about how many of my classes or structs have any virtual functions at all. However since "time to write and debug" is always an issue I don't shy away from templates, even if it is just boost's shared_ptr template.

Re:Mudflap

[stripes]

Rather, why not teach C and the good practices in C that let you avoid those security issues?

Because the constant high level of care and attention that needs to be payed is pretty much impossible to sustain forever.

Look at how many buffer overruns there have been in ftpd. I think even OpenSSH has had one, but I might be confusing that with an integer overflow that had a privilege escalation effect.

If you look at the last years worth of CERT advisories I'll bet over half of them wouldn't have happened with a bounds checked safe pointer language.

My concern is that if you lower the bar, so to speak, then the next generation of programmers will be more mediocre.

I doubt it. Or at least I hope you are wrong, because we have already added function prototypes to C and I'll bet most modern C programmers aren't as good at finding "type width errors" as people that programed pre-C89 systems. In fact I'm pretty sure I'm not as good at that as I was in 1987. My compiler spots them, so I have stopped looking. I suspect I'm using that little bit of attention for something else, I couldn't really say what.

But if it is true that having the language take care of nitpicky details makes people worse programmers then we are in trouble. I mean very few people still code in assembly any more, and none of them deal with laying out instruction addresses so the drum has rotated to almost the right spot anymore...

We must be an awful lot worse at this programing stuff then the folks in the 1950s were.

Or maybe we have more time to spend on other parts of the art of programming. Or maybe just in writing more programs. Or solving more complex problems.

Re:Mudflap

[Panaflex]

Preachin to the choir here!

I'm not arguing that C is without it's limitations.. only that there are some simple things to ease the pain. I've been developing in C for 16 years.. still bites me.

Like I said.. I would love for some of the advanced languages like C# to come down to native code. I know there's a java compiler, but it doesn't play well with the rest of GCC.

-Pan

Re:Mudflap

[Anonymous Coward]

Umm, How about Ada95?

It is safe, easy to read, efficient, and intended for embedded systems. Oh yeah, it is also object oriented, if you like, and supports template programming. You also get a more natural syntax for multi-threading than pthreads built into the language. Ada2005 is adding STL-like containers and the interfaces mechanism from Java among other improvements.

GCC 3.4.x has a pretty decent free implementation, and you can start getting good tools at http://libre.adacore.com/. Aonix and Green Hills make good compilers for RTOSes and bare-metal, safety critical stuff.

Re:Mudflap

[Per Abrahamsen]

The same technique that can remove most of the overhead in languages like Java (value range propagation) can also remove most of the overhead in C.

Re:Mudflap

[Xyrus]

I don't really have a lot to add to that. :)

But, like you, when given the choice between C and C++ I always choose C++.

~X~

Re:Mudflap

[Anonymous Coward]

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 don't understand the logic behind this thinking.

'ls' doesn't need to be fast, since it's I/O bound. I'd easily make my /bin apps (save /bin/vi) 100x times slower if it would make me more secure.

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

[fwice]

I'm guessing that it's going to be similar to the vectorization capabilities of matlab. for example:

% create a vector of numbers from 0->2pi
x=[0:pi/4:2*pi];

% take sin of values
y=sin(x);

which will take all of the sin values of the y, as opposed to the for loop:

for m=1:1:length(x)
y(m)=sin(x(m));
end

the vectors run much faster...

Re:Autovectorization

[Anonymous Coward]

For things like the Cell processor, you'd be better off with something like OpenMP that is designed for spreading threads across multiple execution units such as those in the Cell processor. All autovectorization does is help with things more like MMX.

Re:Autovectorization

[Duncan3]

"autovectorization" has been in the works for about 30 years longer then Cell has been on the roadmap.

In thne shorter term, GPU's have been pushing this line of research hard for a few years as well.

Re:Autovectorization

[s0me1tm]

Autovectorization is for SIMD, not for SMP

Re:Autovectorization

[oliverthered]

SIMD
MMX unroling loops that kind of thing.

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

[Anonymous Coward]

Ah...

But don't you see that the multiple cores in Cell can be used like the extra MMX instructions?

The Cell's 8 cores can be used as independant proccessors, but for desktop-like situations they will probably not be.

The Cell has a extra 128 instructions added onto the normal PPC and Altivec ISO. Those extra 128 registers represent the extra 8 'vector' cpu 'cores' in the Cell.

So if GCC is able to 'autovectorize' the machine code to use as much as those extra 128 registers as possible (the extra 8 cores can run also integers and other datatypes, not just floating point) then code for some applications (games, multimedia) can be optimized very well to run on Cell.

Another clue if you looking into the funding and the technology (look for whitepapers in google) behind the autovectorization and related software technology in Gcc you'd see one name over and over and over again..
IBM
IBM
IBM
IBM
IBM...

So remember that Cell, while multicore, is not multicore in the same sense that it's SMP like Opterons will be.

Each Cell would be seen as one cpu (or realy 2 cpus since the Cell is SMT-capable), with the extra 'vector' cores seen as extensions like MMX/SSE/Altivec are.

Re:Autovectorization

[temojen]

It also applies to the Pentium MMX. MMX, 3dNOW!, SSE, SSE2, Altivec, etc. are all vector units of varying capabilities. The Cell processors are stream processors, not vector processing units (Although they include an AltiVec vector unit).

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.

Re:Autovectorization

[imroy]

I doubt it's just Apple that's pushing autovectorization. What about SSE/SSE2 on Intel and AMD CPU's? The UltraSPARC (IIRC) also has some vector ops, as did *sniff* the Alpha.

Re:Autovectorization

[Creepy]

I'd agree with you, but Apple IS pushing autovectorization (whether the others are, as well, I don't know). Tiger is supposed to ship with auto-vectorization on (see XCode 2 section), although everything I've read so far says it requires a compiler flag (something like -GCC_AUTO_VECTORIZATION). Since Tiger is shipping with 4.0 and not 4.1, they appear to be wanting to get this in use a point release before gcc does.

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!

[Anonymous Coward]

Oh man, I think I just messed my pants...

TISSUE!

Re:Screenshots!

[Mad Merlin]

Well, it's not GCC, but here's Vim for Women (TM). Note that you can't actually edit anything...

Re:Screenshots!

[Geoffreyerffoeg]

% gcc-4.0 -o helloworld helloworld.c

%

Re:Screenshots!

[Look KG486]

Oh, man! I'm gonna have to wipe down the window in my booth...errr...monitor in my cubicle.

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!

[Anonymous Coward]

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.

make > makelog.txt

That will put all the normal output into makelog.txt, but errors will still appear in your terminal. TA! DAHHHHH!!

Re:Screenshots!

[FuzzyBad-Mofo]

My eyes! What is that hideous clash of colored text supposed to be?

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!

[Anonymous Coward]

omg this guy has hacked slashdot! i havent seen anyone posting pics here since that goatscii

Re:Screenshots!

[KiloByte]

What about doing it the way the kernel does?
That is, the whole command line is hidden, replaced by: the command being run ("CC") and the target being built.

On the other hand, it can log the whole thing with full details to a file.

Re:Screenshots!

[alan_d_post]

rep-gtk!!!

Are you using sawfish? Or does some other program exist that uses rep-gtk?

Re:Screenshots!

[dusanv]

Also, stick an @ at the beggining of each make command and it won't echo the command it's running. Like this:

all:
@gcc -Wall -W something.c > something.o

Re:Screenshots!

[DeadMeat (TM)]

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

colorgcc's.

Re:Screenshots!

[ink]

Yes, you could code all of that into make/gcc; but you could also simply do:

make 2>&1 >./make.out

less make.out

From there you have full regexp searching; you can back-step as far as you want, etc. If you want to get tricky, you can even do cool things such as:

((make | tee make.out) 3>&1 1>&2 2>&3 | tee -a make.out) 2>/dev/null

Which will save all output to 'make.out' and only put errors on the screen. See Linux I/O Redirection Tutorial, which is really just a Bash tutorial, for more information. The very nice aspect of this is that it applies to all commands, not just make/gcc.

Re:Screenshots!

[Profound]

make > build.log

Keeps the errors going to the terminal but standard out is silently sent to a logfile.

Re:Screenshots!

[pair-a-noyd]

Here ya go!

Re:Screenshots!

[zozzi]

Adding an "@" in front of a command in the Makefile causes that single line to be silent.

Re:Screenshots!

[Anonymous Coward]

Hehe, nice one. Good old .bat-days.

Re:Screenshots!

[ndogg]

You might want to look into KDevelop. It does a lot of the things that you mention, and does them really well.

Re:Screenshots!

[Anonymous Coward]

If you think the output from Gcc and Make is useless or annoying, you havn't ever had to work with a large codebase. The output during compilation is invaluable, provided you log it correctly.

Re:Screenshots!

[ArsonSmith]

less make.out

The more you code the less you make.out.

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 ?

[Anonymous Coward]

Read the site you just linked:

Ten Boost libraries will be included in the C++ Standards Committee's upcoming C++ Standard Library Technical Report as a step toward becoming part of a future C++ Standard.

So yes. Eventually, anyway.

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.

Re:boost, please ?

[zbyte64]

i find boost is really ugly... mainly cuz template programming was never meant to be used that way. Now OpenC++ is a very nice project where u can modify/generate code at runtime using relfection like principles. It is very extensible and the limits are far from seen. http://opencxx.sourceforge.net/

Re:boost, please ?

[Anonymous Coward]

I'm sure being a loudmouth prick isn't your job either, but you seem to be doing an awful lot of it.

Re:boost, please ?

[Anonymous Brave Guy]

Surely if we want this in the standard library, it should be included as part of the next version of the ISO C++ standard?

Which at least significant amounts of it is likely to be. Check out the standards committee Library Working Group's web pages for more details. You can find a list of proposals that have already been accepted into the library TR here.

Re:boost, please ?

[Anonymous Coward]

mod parent up

Re:boost, please ?

[Anonymous Coward]

Boost sucks.

Re:boost, please ?

[snorklewacker]

OpenC++ is nice, but Boost solves some real problems right now. OpenC++ is lacking for any real-world examples. This isn't to say it's useless, as I have seen it used for real projects, but it doesn't exactly have much of a library, whereas Boost *is* a library.

I suspect they would work well together -- imagine something like:

counted vector<int> *foo;

translating with openc++ to use the appropriate code from boost.

Re:boost, please ?

[zbyte64]

welll with openc++ there really isnt a new to use boost, but ya you could i suppose. Its really nice since you can actually use C++ code to modify C++ code :-p The end result could be truely amazing. Have openc++ read an xml file describing a database and have it adapt a person's objects to that database and auto resolve all needed functions and handle all the relations. End result - fast development, fewer bugs, major runtime performance increase

Re:boost, please ?

[drxenos]

Some of the Boost libraries will be part of the next version of the C++ standard, though I don't know the specific ones.

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

[Anonymous Coward]

Anything that changes parameter passing will make anything using old libraries fail at new ones, or any new programs fail at old libraries. Probably the same for any stack-size changes (which mudflap probably does).

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?

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

[GreyWolf3000]

Just out of curiousity, do you lfs? Err, more specifically, did you lfs before book version 5?

Re:and how many times...

[cortana]

That's a problem with Glibc, not GCC. If you chose to go against the developers and statically link to Glibc, be prepared to handle the consequences!

Re:and how many times...

[molo]

Yes, GCC has had many ABI changes, However, GLIBC since version 2.1 has not. They maintain what is called "versioned symbols" so that when something changes, they can provide two implementations, and the correct one is selected at load time during symbol resolution. This is EXACTLY the scheme that Solaris uses (its part of ELF, which Sun had a significant hand in). If you want your binary to be portable, build it against an older version of glibc and it will run on all newer versions.

-molo

Re:and how many times...

[Master Bait]

I wish they would rethink nss. To get a static nss-supporting binary, you need to compile glibc with...

--enable-static-nss

Then when you compile your binary...

-static -Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group

Notice there is no support for nis, nis+ or hesiod (whatever that is).

Re:and how many times...

[Anonymous Coward]

Can you run C++ applications compiled on Solaris 2 on any later version?

Sun's binary compatibility is in general (within the same CPU architecture, of coures).

I've worked with Solaris since 2.6 or 2.7 and remember only one issue in upgrading and that had to do with the location of one minor library which was fixed trivally by adjusting one environment variable. That's it. That's about how bad Solaris gets for the average user.

I'm sure there are edge cases that are worse, but most people should be just fine.

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

Re:and how many times...

[Eravnrekaree]

There should be no problem with being able to change the ABI while also keeping backwards compatability as well, you simply include previous copies of glibc, which older binaries are linked to, and link all new binaries to the new version of glibc. The new version doesnt have to keep backwards compatability with the old versions, just keep the old copies of glibc on the system. This is probably a better idea than trying to include backwards compatability in every glibc library. This is what FreeBSD does. You can run FreeBSD binaries back to 3.0 at least, and as well you can run Linux binaries on FreeBSD.

Re:and how many times...

[paroneayea]

Binary incompatibility is just one way the GNU project makes sure software stays free!
It's a feature!

Re:and how many times...

[tap]

That a circular justification if I ever saw one. Static linking doesn't work, therefor static linking isn't allowed, therefor it's ok that static linking doesn't work, since it's not allowed.

In order to reach a large fraction of Linux users with binaries, you either need to use libc5, or have a dozen different binaries. New binaries are needed on a monthly basis. Trying to distribute binary software of Linux is a nightmare (now, it was fine pre-glibc), much worse than for other operating systems.

Of course the glibc maintainers and the distribution providers don't like binary software, so they consider this a good thing for political reasons.

Re:and how many times...

[IamTheRealMike]

Actually it's not nearly that bad, though given that binary distribution on Linux is basically undocumented I can see why you might think that. Come talk to us on #autopackage sometime and we'll sort you out. Hint: we're succesfully distributing binaries of complex apps like Inkscape, AbiWord (both written in C++) and Gaim with no issues. We have written various tools to help work around glibc/gcc compatibility brain damages.

Re:and how many times...

[Anonymous Coward]

Do you apply security patches to all these different versions?

Re:and how many times...

[Anonymous Coward]

Versioned symbols are great, but the system can break down if you use runtime loading of dynamic objects E.g. dlopen(). dlsym() doesn't understand versioned symbols. There are some workarounds (E.g. dlvsym() on platforms that use GNU ld.so) but they're not portable.

Re:and how many times...

[Anonymous Coward]

Often the abi of the c library changes without the api changing. There are lots of macros and stuff thaat make that happen even if your code didn't change.

Re:and how many times...

[Guy Harris]

Often the abi of the c library changes without the api changing. There are lots of macros and stuff thaat make that happen even if your code didn't change.

If the ABI of the library changes in a fashion that can break programs built with older versions of the library, no matter why it changed or whether it was a consequence of an API change or not, then the major version number of the library should change, and if whoever's supplying the system with that C library cares about binary compatibility, they need to keep supplying the older version of the library. (If they don't care about binary compatibility, they should make that clear, so that anybody who does care knows that they're not going to get release-to-release binary compatibility from that system.)

Re:and how many times...

[cortana]

Bullshit. The reason you can't statically link Glibc because the developers don't think it's worth their time to solve the NSS dynamic module version skew problem (read the Glibc FAQ for details).

But why does it matter? Libc6's ABI/API has been stable for ages. Link against something old like 2.1, and your binary will work almost everywhere. You say you need to link against libc5; I don't know about that, but AFAIK, every distribution moved to Glibc years ago.

A new binary every month? Please. Here's a hint--you can pick between static/dynamic linking for each library you link to! If you want to use experimental/unstable library libvolitile, you can link that in statically, while still dynamically linking to Glibc and other stable libraries.

This came up recently on debian-devel; read http://lists.debian.org/debian-devel/2005/03/msg00 347.html for more.

Re:and how many times...

[molo]

If you're dlopen()-ing glibc, I think you have bigger problems.

-molo

GUI

[stud9920]

Come on ! Visual C++ has had an IDE for what, twelve years ? and Borland C++ 15 ?

Open source just does not cut it for any serious developer.

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.

Re:GUI

[Taladar]

In Open Source UIs for development are usually not for a single programming language or compiler since the needed features are usually not so different for different languages and why reinvent the wheel over and over again. Oh, I see, to sell courses for the new GUI for 1000 bucks a day...

Re:GUI

[Anonymous Coward]

There are like a dozen GUI/IDEs that can use GCC as the backend compiler, even as a cross-compiler / debugger.

The Eclipse IDE, Source Navigator and KDevelop are just three that come to my mind. DDD and Insight are two popular debuggers that work via GDB.

Check Freshmeat.net / Sourceforge.net for some other IDEs.

Re:GUI

[Lisandro]

Come on ! Visual C++ has had an IDE for what, twelve years ? and Borland C++ 15 ?

This one is quite good...

Ahhh, the old Borland C/C++ IDEs... i recall programming in BC/C++ 3.2, and the IDE was something i really missed when i moved on. Sometimes you felt like you were running QBasic - the debugger was so well integrated...
TASM was nice aswell.

Re:GUI

[devphil]

I believe I speak for all my fellow GCC maintainers when I say: why, exactly, is an IDE our responsibility?

Oh, that's right, it isn't. Piss off, troll.

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? ;-)

Re:GUI

[Anonymous Coward]

it's a compiler not a gui!!

if you want an ide, try something like kdevelop, emacs, or if you're on a mac, xcode. You can even get it to all integrate with a gui front end to gdb. (GNU Debugger).

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

[man_of_mr_e]

While it's true that the GUI shells out to the compiler, there are hooks in the compiler to make certain operations more atomic from the GUI perspective. One really nice feature is the ability to pass multiple source files on the command line so that a new process need not be created for each source file (compile one file, exit, spawn new process cycle).

This makes it really easy for the GUI build system to drastically improve performance of the compile. I wish GCC would develop an option to do something similar.

Re:GUI

[Anonymous Coward]

Good thing we have unserious developers working on Linux, Firefox et al! Apparently "serious" developers only develop for windows...

Re:GUI

[sconeu]

file1.cpp file2.cpp file3.cpp

Re:GUI

[sconeu]

Damn!

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

Re:GUI

[Anonymous Coward]

have you eevn tried?

Re:GUI

[MrCawfee]

Borland has an IDE that can be used with gcc, called C++BuilderXI have found it a really good IDE, although the personal version is missing some of the features that i liked in C++Builder.

Re:GUI

[Anonymous Coward]

Your low number and your resume are two reasons you should have know better than feeding the troll

Re:GUI

[Anonymous Coward]

Hah! Now the dumb fuck thinks that he has the right to order people around because he's a developer.

Go fuck your mother up her wrinked, dried up pussy you worthless piece of shit.

Re:GUI

[Anonymous Coward]

one of the biggest threats they have to people just picking up linux and wanting to program is a lack of a good IDE.

I suggest you try KDevelop before you go spreading lies about the non-existance of a good IDE for Linux.

And no, KDevelop is not only for making KDE programs

Re:GUI

[Anonymous Coward]

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

To bring this back on-topic: Eclipse is compilable to native code by GCC 4.0.0. (and runs very fast) A natively-compiled package is scheduled for inclusion in Fedora Core 4, which will also include GCC4.

So what's stopping you from using Eclipse? (It is not Java-only.)

Re:GUI

[LnxAddct]

Just a few quick notes... alot of java and swt can be compiled fine with gcj now a days thanks to the hard working engineers at Red Hat. Also, Eclipse has pretty extensive support for C++ and its improving greatly. But my main point has to be, being dependant on a gui for developing is horrific and cripples many programmers. There is nothing that you can't do with Vim and GCC that you can't do with vs.net. You may be thinking, well what about gui interfaces.... gui's designed on the command line after properly being designed on graphing paper almost always turn out to be far more consistent and better then those made with graphical tools. Even Mozilla prototypes interfaces using nothing but ascii art. Graphical tools are okay for prototyping but for anything serious, you ought to be spending 95% of your time at the command line. Even the developers of MS Office dont use gui tools to design the interface... they just aren't very extensible otherwise. In addition, living with the command line allows you to be very efficient and never have to take your hands off the keyboard, its quite nice. Another perk of programming on the commandline is that no matter what platform you may be developing on, you'll always feel right at home. If your only target is MS Windows I guess thats not an issue.
Regards,
Steve

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)

Re:GUI

[Anonymous Coward]

Real professional, buddy.

Re:GUI

[BreadMan]

The profiler from that time was excellent as well!

Re:GUI

[m50d]

I'd suggest KDevelop, it's really nice looking and has tons of integrated tools.

Re:GUI

[barrkel]

It would be great if GCC (or more to the point, GDB) didn't pessimize the co-development of an intelligent IDE, and in particular, a good debugger. That would require a lot of stability for debugger symbol formats along with lots of extra symbol table information, such as class structures etc.

Re:GUI

[mormota]

I basicly agree with your point that it is not desireable for programmers to become dependant on GUI tools, but I think this is no excuse for not having a good C++ IDE on linux. :-) I think smart GUI tools can, and should be used in program development to aid programmers in producing better code faster.

Good IDEs sort of "understand" the code that is typed into them, and based on that understanding they support the programmer with coding/refactoring aids, "real time" (instead of compile time) error checking, style checking, solution proposals for detected errors, etc.

The Eclipse platform could be brought up as a good example of an IDE for the _Java_ language. It saves the programmer a lot of typing (automatic import, suggested solutions for errors), a lot of time (recompile only the needed files in the background, method signature tooltips; very useful when working with unknown classlibs, easy documentation lookup, simple refactoring, etc.). It really makes working with Java easier. (although running it on my laptop with 256 megs is no fun at all :-)

So for Java there is Eclipse but I am still looking for a good C++ IDE. Tried Eclipse/CDE kdevelop and anjuta without luck.

Re:GUI

[mav[LAG]]

For me, *NIX is an IDE.

Thanks for this definition - I was trying to explain to a Windows friend the other day why I'm so productive in *nix and it didn't occur to me to describe the whole environment as an IDE.

MyIDE = xterms + vim + grep + make + svn + man + the browser + diff + io redirection +.... ..Nods head..+ strace + ddd + ipython + glade + lyx + whatever else I need.

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.

Amen to this. Or you can bring elements of an IDE into vim and use them there like TList.

Shocking...

[templest]

And software written in the C++ programming language should run faster--"shockingly better" in a few cases.'

I doubt that anyone is going to be rushed to the emergency room for this one.

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.

Re:I'm so sorry, ...

[Anonymous Coward]

Nonsense. You can compare recent versions of GCC with earlier versions of GCC and see performance differences. And there are performance differences between Comeau, Intel, and GCC as well. In some cases I have seen differences of a factor of 10 on real projects that use templates, STL, etc. just by switching the compiler.

Re:I'm so sorry, ...

[Anonymous Coward]

lies in fact that it uses extensively the templates.

Does it also set us up the bomb?

Re:I'm so sorry, ...

[Anonymous Coward]

Including support for export template feature could help but only when anybody would use it in their code.
Now that's the feature I want! "Warning: Keyword export not implemented" makes me want to hurt someone.

Re:I'm so sorry, ...

[Anonymous Coward]

Templates are not true generics dude.

Re:I'm so sorry, ...

[Anonymous Coward]

set up us the bomb

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

[scotch]

Is that the suicide solution?

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:sane error messages when using templates

[Anonymous Coward]

Use STLFilt.

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:Favorite quote from the article

[The_Wilschon]

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.

Yes it is. The analogy is not parallel, because saying that GCC is a central enabler to FOSS is like saying that (ie) the Dallas Morning News is a central enabler to democracy. A far better statement would be "It's not too much of a stretch to say that a really deucedly good free compiler (of which GCC is an example) 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.

Re:Why not run it all the time?

[Anonymous Coward]

No, it functions quite well in production code. In everything except for tight loops the performance hit should be negligible at worst. Take a look at determina SecureCore for a commercial example of this kind of technology. SecureCore even has additional overhead because it's instrumenting compiled binaries.

Re:Ahhhhh... Time to start compiling all overagain

[lintux]

Why would you have to use GCC 4.0 for those platforms? I used GCC-3.x for the AVR platform and it did everything I needed... (Which isn't a lot on those machines, I'd say.)

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

[jez9999]

... what's the difference between gcc and g++?

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

[The One KEA]

g++ is a companion program which adds half a dozen magic switches to gcc and does other magical things to provide extra C++ features that are implemented in the system libraries.

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

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

[Anonymous Coward]

Also, gcc stands for GNU Compiler Collection, as well as GNU C Compiler - so there are two "gcc"s out there.

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

[Anonymous Coward]

... what's the difference between gcc and g++?

You're confusing GCC the command-line program with GCC the software package.

GCC (as in GCC 4.0.0) is the GNU Compiler Collection. It has compilers for several languages; C, C++, Fortran, Java.

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

[beelsebob]

gcc stands for gnu compiler collection and is a set of compilers, while g++ is a C++ compiler.

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

[drxenos]

I can't believe that everyone that replied to this is wrong! gcc is a frontend for all the languages in the collection. It use to stand for Gnu C Compiler when it was just C. Now it stands for Gnu Compiler Collection. gcc is not a compiler. It will execute the correct compiler based on file extension. g++ is the actual g++ compiler. It will not only compile the source as C++, but will automatically link with the C++ library (if necessary). If you compile from gcc instead of g++, you most explicitly pull in the library yourself.

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

[drxenos]

No, the later name was replaced by the former when more langauges were added to GCC.

Demo

[pjf(at)gna.org]

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

Re:Demo

[openglx]

Interesting? The ones who moderated this INTERESTING should receive a kick.

At least if they are not talking about his sig... really interesting sig :)

Re:Demo

[snorklewacker]

> At least if they are not talking about his sig... really interesting sig :)

Try it. It doesn't actually work.

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

[RWerp]

AFAIK f2c is a separate project. gfortran is working like g77, it's a frontend to gcc.

Re:Fortran???

[Anonymous Coward]

Guess again. Gfortran is an entirely new compiler frontend and runtime library. Andy Vaught undertook the enormous task of writing a Fortran 95 compiler from scratch. An early version of Andy's work was integrated into GCC and we have been working on bug fixes, completing a few missing pieces, and backwards compatibility with g77. Use google with g95 and gfortran keywords. BTW, gfortran beats g77 on some of my private benchmarks.

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.

Re:Fortran???

[devphil]

Yep, you got it.

If any of you have heard of the SIMPLE language, GIMPLE is an adaptation of that.

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:More incompatibilities on the way?

[multipart]

And you want to compile your legacy code with the latest-and-greatest compiler...why? If you write code that is standard conforming, then GCC can compile even K&R C without trouble. If you rely on obscure, non-standard features, do not expect them to work. Your fault, not GCC's. Solution: Use an older GCC. They still work, you know.

Re:More incompatibilities on the way?

[Bloater]

Their attitude is that code that is incorrect was unpredictable in its behaviour at the time it was written. If they let it break, then it's *still* unpredictable in its behaviour, so those crappy programmers have lost nothing, and the rest of us get a better compiler.

Re:More incompatibilities on the way?

[ari_j]

A compiler that ignores syntax errors isn't really "better."

Re:More incompatibilities on the way?

[vsprintf]

And you want to compile your legacy code with the latest-and-greatest compiler...why?

I'm not the GP, but machines get upgrades. In a work environment, you often have little choice about what compiler you use. If your code is open source, you have the same problem.

If you write code that is standard conforming, then GCC can compile even K&R C without trouble.

Wow! gcc can even compile K&R C? Now, that is truly above and beyond the call of a C compiler.

If you rely on obscure, non-standard features, do not expect them to work. Your fault, not GCC's.

I maintain a large app (one of many), composed of about fifty files and written in vanilla C. It has worked for over seven years on a variety of *nix platforms, but a recent gcc patch broke it on Linux.

Solution: Use an older GCC. They still work, you know.

That's not a solution - it's a copout. There have been too many instances of gcc breaking compliant code for your comment to have any real meaning.

Re:More incompatibilities on the way?

[dcam]

I waiting for an explanation of how this is a problem.

Re:More incompatibilities on the way?

[Anonymous Coward]

Well, what part of "undefined behavior" and "implemenation defined behavior" do you have a fucking problem understanding?

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.

Re:From what I've heard

[Stevyn]

For most people, that isn't going to benefit them. I use gcc only by way of portage to compile the software I use...kde, xorg, qt, mozilla stuff. I wouldn't care if it takes longer to compile if the binaries are more efficient and the programs run faster. I can understand some of the posts I've seen so far that it's frustrating to wait hours for big packages to compile. A simple solution I've found is to compile at night so when you wake up it's finished.

However, if I was a developer and I had to deal with slow compilations on a daily basis, I'd probably not be too happy with it. Most people who use software compiled by gcc, however, aren't the ones who compiled it. So for most people, gcc 4.0 is going to benefit them in terms of application performace. I have seen compile time decreases from 3.3 to 3.4 so I'm sure they'll speed things up with 4.0 as well.

Re:From what I've heard

[UnseenEnigma]

Try running a webserver, desktop, vnc terminal server, router, dns, fileserver, pxes boot server and lots of other shit on a gentoo box with 64 megs of ram. Compiling kde (everything) takes 3 days (niceness of 12). I need every bit of efficiency I can get and ram heavy "optimizations" like -O3 (compile and runtime) kill my system performance.

Re:From what I've heard

[Anonymous Coward]

Try running

No.

Nitpicking

[mike260]

A better-established GCC competitor is Intel, whose compilers are recognized to be the gold standard for software running on x86 chips.

Is that actually true? Last time I tried a head-to-head comparison, the Intel compiler came a distant third to GCC and MSVC.

Re:Nitpicking

[fitten]

Strange... MSVC and Intel's compiler are usually the top and gcc is lower, for me. Most benchmarks I've seen on the web follow my experiences as well...

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.

Re:Nitpicking

[Anonymous Coward]

Is that actually true? Last time I tried a head-to-head comparison, the Intel compiler came a distant third to GCC and MSVC.

Intel is faster on x86. I haven't seen a benchmark which says otherwise. Even the GCC folks themselves are prepared to conceed that Intel is faster.

But so what? GCC supports far, FAR more OSes and hardware platforms. You can't be the best at everything all the time.

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.

Re:Nitpicking

[Nasarius]

Unfortunately so. Of course, ICC and MSVC have the advantage of only needing to concentrate on one architecture (x86), whereas GCC compiles for pretty much everything.

Re:Nitpicking

[gatkinso]

Not true - VC++ compiles for Alpha and PPC. Not that these versions are sold any longer, but they still exist.

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.

Re:Nitpicking

[Anonymous Coward]

There's a current version of VC++ for PPC. It's a part of the Xenon Development Kit

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

[sconeu]

No. Early C++ compilers translated C++ into C.
MATLAB has a compiler that turns MATLAB into either C++ or C.

Re:Compiler

[QuantumG]

heh. Depends what you mean by "binary". Obviously everything on a modern computer is "binary" in some sense. It's due to this confusion that it's better to say "native instructions" when you want to distinquish the output of something like GCC to a compiler like javac (which you would say produces "bytecode instructions") or a pascal compiler (which produces "pcode instructions"). So no, not all compilers produce native instructions. Some compilers don't even produce instructions, for example, a database schema might be "compiled" into a listing of tables and foriegn key constraints. Quake mapping tools often have a compiler which converts brush information into bsp trees. A compiler is simply any tool which converts data from a "high" level of abstraction to a "low" level of abstraction. A decompiler does the opposite of a compiler. With that definition the more interesting question is: what is abstraction? Martin Ward has the answer.

Re:Compiler

[Chris Burke]

Are you being a Grammar Nazi, or do you really not recognize a phrase intended for the portion of the audience that doesn't know what a compiler is?

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

Re:Compiler

[Anonymous Coward]

What about those crappy java versions of Matlab?

Re:Compiler

[vsprintf]

No. Early C++ compilers translated C++ into C.

But then that C++ preprocessor generally called the C compiler and produced a binary executable as the end product.

Re:Compiler

[menace3society]

No true compiler does this. A compiler compiles a high level language (C, fortran, etc) into assembly language format. The assembler (which is distributed with gcc) then assembles the assembly instructions into machine code.

Then, the linker links the machine code from the assembler to the system libraries and the head and tail files, and turns the whole thing into an executable program. :-)

Re:Compiler

[Anonymous Coward]

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

Nope:

1. javac compiles Java source code into bytecode, which while it is binary, is not machine code. (I suspect by "binary" you mean "binary executable", or "machine code", or even "assembly language", but not all binary instructions are machine instructions.)
2. yacc (and bison) convert a context-free grammar into a table (expressed as C source code) that an automaton (also expressed as C source code) can use to parse the language specified by yacc's input.
3. On the Mac, Apple has a resource compiler which takes a text file and converts it into a resource file (which is a sort of binary file equivalent of a two-level associative array, with the keys both being fixed-length integers). A similar facility exists on several systems for making Palm ResourCe files (PRCs) that contain Palm OS executables.
4. Database servers usually contain a compiler of sorts that takes a SQL statement and compiles it into an optimized query. This never gets translated into a file full of instructions, but it does presumably get translated into some sort of abstract syntax tree data structure that the database can analyze to optimize the query.
5. The Perl compiler compiles into an internal bytecode type of thing that it then interprets. Because it has an exec function, it must incrementally compile. It may feel like an interpreter, but it's actually a compiler that compiles to a different sort of data structure which is then executed by a big main loop (if I understand it correctly).

Re:Compiler

[cpghost]

What about p2c, the Pascal to C compiler?

Re:Compiler

[Walterk]

Actually, the word `compiler' has two meanings:
compiler
n 1: a person who compiles (or writes for) encyclopedias [syn: encyclopedist,
encyclopaedist]
2: (computer science) a program that decodes instructions
written in a higher order language and produces an
assembly language program [syn: compiling program]

These days the former may also be regarded as the latter, as the compiler sifts through information (source code) and makes it into binary code (their computer database). Using this interpretation, he is right.

Ha-ha...

Re:Compiler

[That's Unpossible!]

Actually, the word `compiler' has two meanings:

Actually, the word compiler has one meaning: A compiler is simply a person or thing that compiles. It does not define what they compile. It is not specific to source code or encyclopedias, however those may be the two most common usages today.

These days the former may also be regarded as the latter, as the compiler sifts through information (source code) and makes it into binary code (their computer database).

Uh huh..............

Re:Compiler

[Anonymous Coward]

> ... high-level languages such as C--into the binary instructions

Actually, C-- is a very low level language...

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.

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

[Pop69]

You mean RH has shipped another incomplete beta compiler ?

That sounds familiar for some reason.....

Re:Latest Fedora-development has gcc 4.0

[man_of_mr_e]

I thought Red Hat had learned their lesson with the RH7/GCC3.96 debacle. I guess not.

Re:Latest Fedora-development has gcc 4.0

[multipart]

But the binaries are smaller if you use -Os. Most FC packages compile with -O2 and higher, and that means "compile for speed". Compile for size (-Os) is entirely different. See http://www.csibe.org/s-i686-linux.php for some nice graphs. The first data points are roughly GCC 3.4. The later ones are GCC 4.0. Ignore the final two data points, they are for GCC-4.1-to-be).

Re:Latest Fedora-development has gcc 4.0

[andreyw]

GCC 2.96, FYI. And yeah, apparently no... they haven't learned a thing.

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:Latest Fedora-development has gcc 4.0

[Mr. Frilly]

No, this time they're giving you beta packages of gcc so that you can test things out if you want. The packages are labelled gcc4, and the installed binary is gcc4, so there's no chance you'll compile things with the beta compiler unless you explicitely want to. The default compiler is still gcc 3.4.

What created the gcc 2.96 fiasco was that RedHat made it the default compiler on the system and expected everybody to use it, even though it wasn't ready for prime time yet (and wasn't even an official gcc release). In fact, they even provided a kgcc package (which was just gcc-2.95) because the kernel couldn't be compiled with their 2.96. As a developer who uses RedHat, it was a total nightmare. And if I remember right, Mandrake did the same thing.

If you look through configure scripts, you'll still find programs that check for 2.96, and then either refuse to compile or turn off all optomizations.

Re:Latest Fedora-development has gcc 4.0

[Mad Merlin]

I was looking through the kernel source the other day, and in init/main.c found this nugget:

/*
* This is one of the first .c files built. Error out early
* if we have compiler trouble..
*/
#if __GNUC__ == 2 && __GNUC_MINOR__ == 96
#ifdef CONFIG_FRAME_POINTER
#error This compiler cannot compile correctly with frame pointers enabled
#endif
#endif

Re:Latest Fedora-development has gcc 4.0

[Anonymous Coward]

What a moron. Since when is FC4 out?

FC4 will include the relase version of GCC 4.0.0, and it will slip to follow it, unless the GCC release is too delayed, in which case they will revert.

Source.

Re:Latest Fedora-development has gcc 4.0

[gnuman99]

It is in Debian experimental as well. Unlike Fedora, this is NOT the default compiler.

~$ apt-cache policy gcc-4.0
gcc-4.0:
Installed: (none)
Candidate: 4.0-0pre5
Version Table:
4.0-0pre5 0
1 http://http.us.debian.org experimental/main Packages

Re:Latest Fedora-development has gcc 4.0

[x2A]

gcc 4 is ABI compatible with gcc 3.4
gcc 4 is ABI compatible with gcc 3.4
See above two statements.

Loop unrolling, how very apt! ;-)

-2A

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:Gentoo system rebuild!

[MyDixieWrecked]

man........ I just had to rebuild my system TODAY. grrrr. maybe I should have waited...

(I had a problem with /lib/ld.so.1 throwing SIGSEGV signals in random programs... namely tar... so that means I couldn't emerge stuffs.)

Re:Gentoo system rebuild!

[Anonymous Coward]

LOL... just DOWNLOAD tar somewhere, rebuild tar, and discard your temp binary.

omg

Re:Gentoo system rebuild!

[BobNET]

Don't forget to link it statically this time, either.

Re:Gentoo system rebuild!

[evilviper]

The biggest complaint we received from Gentoo users during the 3.x series was that GCC was too boring

Not true, just throw an -O3 in there, and several different versions of gcc3 will optimize out certain functions entirely :-)

Just ask any of the developers of media players on Unix (MPlayer/Xine/etc) what they REALLY think of GCC3.

Re:Gentoo system rebuild!

[Anonymous Coward]

Just ask any of the developers of media players on Unix (MPlayer/Xine/etc) what they REALLY think of GCC3.

Well if they have a problem why don't they file regression bug reports? They are taken *very* seriously.

Or are you just trolling?

Re:Gentoo system rebuild!

[evilviper]

Well if they have a problem why don't they file regression bug reports?

They do... Many of them...

They are taken *very* seriously.

Just because you say it, doesn't make it true.

I've seen MANY responses from gcc bugreports that almost make me laugh. Things along the lines of: Just because it's ANSI C, doesn't mean it will work

I've never seen a more arrogant bunch of people on an open source project.

Re:Gentoo system rebuild!

[Anonymous Coward]

Just because you say it, doesn't make it true.

OK, how about if the GCC 4.0 release criteria says it?

In general, regressions where the compiler generates incorrect code, or refuses to compile a valid program, will be considered to be sufficiently severe to block the release, unless there are substantial mitigating factors.

Re:Gentoo system rebuild!

[MyDixieWrecked]

I did. didn't fix it.

Anyway, there were like 4 different programs in the end that were crashing out.

PathScale... looks interesting...

[kompiluj]

Quote from the article: A start-up called PathScale offers an open-source compiler that's compatible with GCC 3.3. "Our company is trying to be the GCC alternative for people who care about high performance," said Len Rosenthal, vice president of marketing for PathScale..
From this page and their claims about GCC front end (source code) compatibility I infer that their compiler is just an back-end (code generator) to GCC using GCC's front-end. I think that writing full C/C++/Fortran front end with GCC compatibility would be no small feat (especially that most big companies use Edison Design Group front-end, developing only their back-ends).
What looks a little bit suspicious are PathScale's performance claims. It looks like the PathScale compiler for x86 generates much faster code than Intel's own in-house compiler (which is being developed by people hired from KAI known for creating a very high performance compiler) or the industry-famous Portland Group compiler. I would be more than happy to see that PathScale's product delivers what is promised.

Re:PathScale... looks interesting...

[beliavsky]

PathScale is slightly faster than Intel on the AMD Opteron Linux platform for Fortran 90 programs according to numbers from Polyhedron http://www.polyhedron.co.uk/compare/linux/f90bench _AMD.html

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*),

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.

[sik0fewl]

Wow, I just noticed now that you changed it to a Perl script:

^?ELF^A^A^A^@^@^@^@^@^@^@^@^@^B^@^C^@^A^@^@^@@~R^D ^H4^@^@^@~P~K^@^@^@^@^@^@4^@ (and so on)

Seriously, though, why not still have it as a shell script?

Re:Not much.

[devphil]

Execution speed.

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

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

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

Re:Not much.

[millette]

Well, considering the first c++ was a c preprocessor, I'm not surprised.

C++/Java Compiler Comparisons

[Doc Ruby]

C++ will be "much faster", so it's now "much slower" than it can be. What about the comparative efficiency of the Java bytecode it will generate? If the Java compiler is already getting more of its maximum theoretical efficiency, doesn't that mean that Java code might be faster than C++? If the Java efficiency isn't as close, doesn't that mean that any comparatively lower performance compared to C++ executables could be overcome by developing the Java compiler further? In fact, doesn't the fact that even C++ compilers as mature as GCC at this late date can get big performance increases with better programming, mean that all the C++/Java performance comparisons are really more about the compiler and its language module optimization?

Re:C++/Java Compiler Comparisons

[k98sven]

I don't quite understand what you mean.. Are you talking about VMs running bytecode or GCJ-compiled native code?

What about the comparative efficiency of the Java bytecode it will generate? If the Java compiler is already getting more of its maximum theoretical efficiency, doesn't that mean that Java code might be faster than C++?

GCJ does not produce the most efficient Java bytecode out there. But it depends on the VM exactly how efficient the bytecode is run, so I can't see how that's relevant here.

Java code (compiled to native) is unlikely to ever be faster than well-written C++. Garbage collection, for instance, will slow the Java down, but the difference is rather small.

In theory, a JIT VM can be faster than natively-compiled code. But I can't see how that's relevant, since GCC (currently) doesn't include a JIT. It can compile to native, and it can interpret Java code.

There are valid arguments both for JITs being faster than natively-compiled and vice-versa. It depends on the application.

If the Java efficiency isn't as close, doesn't that mean that any comparatively lower performance compared to C++ executables could be overcome by developing the Java compiler further?

If you mean bytecode, the performance benefits of producing better bytecode are small, and there it's up to the VM. If you mean native code, then you can theoretically get as close as GC and such will allow. (Which is less of an overhead than some seem to think)

Re:C++/Java Compiler Comparisons

[Anonymous Coward]

Too bad Java systems suck even worse than C++ compilers. Dream on, come back when you know what you are talking about.

Re:C++/Java Compiler Comparisons

[Doc Ruby]

What is it with the Anonymous moron Cowards today? All they've got is spittle for my windshield.

Re:C++/Java Compiler Comparisons

[Doc Ruby]

I'm talking about GCJ. Even the most efficient JVM is only as good as the bytecode it gets. Just like the most efficient (microcode, pipelines, etc) x86 is only a good as the compiler.

Re:C++/Java Compiler Comparisons

[Anonymous Coward]

LOL, you are pretty wrong about the JVM only being as good as the bytecode it gets. Java code cannot be statically optimized- functions can't be inlined in the bytecode, etc. That is what makes JIT compilation so attractive to java bytecode.

There is some more spittle for your fucking windshield you fucking mororn!!!

Re:C++/Java Compiler Comparisons

[k98sven]

I'm talking about GCJ.

That doesn't clarify things. GCJ can both compile java to bytecode, and java to native code (Without going through bytecode. Indeed, compiling to native directly gives significantly better optimization).

Even the most efficient JVM is only as good as the bytecode it gets. Just like the most efficient (microcode, pipelines, etc) x86 is only a good as the compiler.

That is not a valid comparison, because a processor will always execute a given instruction in the same amount of time. The compiler can know for certain that a certain piece of code is faster than another equivalent one.

That is not true of a JVM. One JVM may execute a certain set of instructions faster than another set, whereas a different JVM might produce the opposite result. JIT will complicate things further, since some parts will be JIT-compiled and some not, and what might hold true for the interpreted bytecode might not hold true for the JIT-compiled bytecode. And so on.

Re:C++/Java Compiler Comparisons

[omb]

OK, discussions on /. are getting more Dillbert like and un-informed by the day

What is going on here is that gcc is improving, and quickly as serious investment is now taking place

This takes many forms: (a) parsers, started as, (f)lex + yacc|bison (parse valid source) and are now (A) hand crafted --> better compile & run-time error messages; (b) newer technologies eg TSSA v RTL allow better generic optimisations in the middle-end, (contrary to some popular belief some real academic work on optimization has been done since the 1980s)

(c) changes in development fashion mean that development effort is better focused, eg C++ templates+namespaces are now stable and Java now has generics as well,

(d) the run-time semantics have stabalised, and the specifications are unlikely to change in the sort term,

(e) the MPU landsacpe is clearer, and simpler, than it has been in two decades.

This all makes it easier for the compiler writers --- give it a little time to settle down and do _NOT_ chase the compiler.

Re:C++/Java Compiler Comparisons

[m50d]

I think that the Java compiler is pretty close to maximum efficiency, because there have been lots of people working on it. So yes, Java code should be faster than C++, except that Java sucks and is being interpreted by the JVM, so there's a massive overhead which more than counters the better-compiled code.

Re:C++/Java Compiler Comparisons

[Doc Ruby]

More people have worked on the java compiler than have worked on the C++ compiler?

Re:C++/Java Compiler Comparisons

[m50d]

Oh yeah. Possibly less experienced people, but Java has been the "cool language" for several years now, and open source has been a lot bigger in those years than in the ones preceding them.

old languages

[Anonymous Coward]

Ada jokes, riiiiight after me !

hmm....

[ajaf]

"And software written in the C++ programming language should run faster--"shockingly better" in a few cases."

What about compilation times?

Re:hmm....

[PitaBred]

Like it matters? As long as it's not orders of magnitude slower, it'll be a win overall. People usually spend more time running software than compiling it. Gentoo users are an exception.

Re:Ahhhhh... Time to start compiling all overagain

[Anonymous Coward]

It's not a "Have to use..." it's a "Well, will GCC 4.x make my programs fit better in 2048 bytes."

What about export?

[Anonymous Coward]

When is GCC going to support the 'export' keyword? You will never be able to claim to fully support ISO C++ until then.

Decades old?

[pjdepasq]

If Fortran 95 was released in '95, and it's now 2005, isn't it a decade old language? Let's not get ahead of ourselves here....

Re:Decades old?

[Anonymous Coward]

Read it again. He is referring to the Fortran language in general. Fortran dates back to 1955
or so. There have been 5 official standards Fortran 66, Fortran 77, Fortran 90, Fortran 95, and Fortran 2003. Yes, that's right! Fortran 2003 is the newest international standard for any language.

Re:Decades old?

[Anonymous Coward]

So why is a NEW fortran compiler not conforming to the latest spec?!?!?

Re:Decades old?

[Anonymous Coward]

The newest spec was ratified in November 2004. It contains some fairly significant enhancements that will take gfortran several months/years to implement (eg., OOP features). Fortran standards are backwards compatible to at least the immediate past standard, so a conforming Fortran 95 program will be a conforming Fortran 2003 program. I also note that even commercial compiler vendors have not released a fully conforming Fortran 2003 compiler. It does take time to actually understand the standardese and write code.

Re:Decades old?

[anon mouse-cow-aard]

The standard that defines fortran 95 is ISO/IEC 1539-1997... last four digits being the year it was actually approved. It beats Debian for release dates, but not by much.

Wrong.

[devphil]

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

Why?

[oliverthered]

Most Linux distributions and users have the ability to re-compile everything from source, upgrading to the latest GCC is only a day away for me (the time it takes to rebuild my system).

Designing to last is a different issue, and I think there should be less brackages because the software should be designed properly in the first place.

Re:Why?

[Anonymous Coward]

Most Linux distributions and users have the ability to re-compile everything from source

What an incredibly narrow-minded point of view. For one thing, no enterprise installation is going to recompile *anything* on the box. As for users, isn't the point of getting widespread adoption to improve the system's usability, not say "You're not a programmer, you don't even know what a compiler is, but you have to recompile all your software"?

Re:Why?

[oliverthered]

What an incredibly narrow-minded point of view

You would think so wouldn't you, but For one thing, no enterprise installation is going to just upgrade the compiler, if fact why the hell are they using a compiler of that kind of box.

"You're not a programmer, you don't even know what a compiler is, but you have to recompile all your software"

What is your weird reasoning, have you ever worked for a company? Redhat your chosen Linux support provider will give you upgraded binaries, and any software you purchase will run nicely on redhat version xyz.

You see Redhat, Mandrake, Debian etc.. will all make sure your system is upto date, software you purchase will run fine on you system, even if it overrides LD config or is staticly compiled.

If you have custom inhouse software then you should be able to recompile it, at least I hope so. What is the point of keeping legecy crap around when it isn't needed.

Far from being narrow minded my view is broad reaching, you took the narrow minded opinion that everyone else is like you, except I bet that you've never had a problem with non-binary compatability that wasn't either enforced by you or down to a lack of understanding on your part.

Intel C compiler team

[zymano]

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

Re: Intel C compiler team

[ratsnapple tea]

And what about IBM's compiler for PowerPC? It would be great if GCC could incorporate some of the IBM compiler's optimization techniques, especially now that IBM's "freed" its patent portfolio.

Re: Intel C compiler team

[Anonymous Coward]

Dude, that comparison is for gcc 2.95!

Re: Intel C compiler team

[Jameth]

Well, they hire a large team of coders, have a good set of test machines, get any hardware the need before it comes out and...oh yeah... ONLY SUPPORT ONE ARCHITECTURE. Hmmm...I wonder how they manage to get one architecture's speed to compete with a compiler suite that works on something like ten languages and damn near every arch out there.

Re: Intel C compiler team

[SunFan]

They use the same dark magic that they used to make the Internet go faster.

Re: Intel C compiler team

[Anonymous Coward]

Yes, that also explains why FreeBSD is faster than NetBSD. Oh, wait...

Re: Intel C compiler team

[Anonymous Coward]

Oh, wait, it doesn't explain that and oh, wait, it's unrelated.

Re: Intel C compiler team

[Anonymous Coward]

They use the same dark magic that they used to make the Internet go faster.

MMX? :-)

Timeline?

[Matt Clare]

Anyone know when 4.0 will be ready for the distros?

3 monts? 6 months? a year ? forever?

Re:Timeline?

[seringen]

right now, and later. It all depends on what type of distro you're running.

Re:Timeline?

[winavr]

According to the GCC Development Plan, the 4.0 branch was cut on Feb. 25. On the gcc list, they were talking about making a release appox. 3 months after that (IIRC), but it all depends on how the bug fixing goes.

Re:Timeline?

[mla_anderson]

Now for some, 10 years from now for Debian.

Re:Timeline?

[Matt Clare]

For me, Gentoo. So guessing, based on other responces, maybe six months before it's in the stable x86 and PPC. Guess on the RPM based distros? When will we see the GCC4.RPM file precompiled with GCC4? (Please no portage overlay responces)

Re:Timeline?

[drfreak]

GCC 4.0 has been in experimental for months. Actually seeing binaries produced from it even in unstable could take a while though. Very little will compile cleanly with it yet anyways.

Re:Timeline?

[seringen]

if you're using gentoo then just search the forums for an ebuild. As for RPM's, fedora has 'em.

Re:Timeline?

[True Grit]

One of Debians AMD64 distros is using gcc4.0 now. One is called pure64 using gcc3.3/3.4, and the other was unfortunately called gcc3.4 when it was begun, which has now using gcc4.0.

Now for Debian *stable*, we may be talking awhile... :)

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.

[Anonymous Coward]

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

What is the priority on those "issues" at the gcc team? Are they abandoned issues, high or low priority or what?

Re:Ahem.

[Anonymous Coward]

Of course Microsoft haven't had any trouble maintaining ABI going back many years.

Re:Ahem.

[Anonymous Coward]

Microsoft uses COM for exactly this reason. If every OSS library used XPCOM, nobody would care what GCC does.

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.

[HiThere]

Do remember, however, that the users aren't exactly supporting them, or not much. There was a link offered in case he did want to participate.

That said, the commentor will probably only notice if his distribution decides to include (only?) the newly revised compiler. The GCC team don't change things on their own. If the distributions don't like the changes, they'll stick with the old version.

And if you REALLY care, there's always "Linux from scratch" which allows you to build your own system with your choice of compiler, and your choice of everything else, too. It's a bit of a pain to maintain, but it's a full Linux distribution. (I must admit I've never followed things through to the end, so I can't personally vouch that it works properly, but I have no reason to doubt it.)

Re:Ahem.

[Anonymous Coward]

You can have whatever compiler you want if you pay. Oh wait, you didnt? Then what are you complaining about? As has been said about other pieces of free software: If it breaks, you get to keep both pieces.

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.

[Kent Recal]

so I can't personally vouch that it works properly

Ofcourse it works, why shouldn't it?
There's no magic smoke in your distro. It's a kernel, a glibc and a bunch of software.

Only via LFS you can do funny things like compile everything static, really get rid of SysV init (in favor of e.g. minit), compile stuff against dietlibc instead of glibc (talk about >50% less bloat), choose the exact version and patches for all your system utils (ever hated distro X for including only broken version Y of Z?)...

So, yes, LFS is for people who REALLY care. And it works.
Make a tarball and it even works for many machines ;-)

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.

that's nice...

[Anonymous Coward]

but does it run linux? oh, wait... nevermind.

Can't be assed reading TFA

[simonwalton]

But I'm hoping we'll see objective-C++ in this one. And perhaps a nicer solution for C++ template instantiation.

Re:Can't be assed reading TFA

[winavr]

IIRC, from reading the gcc list, is that it's more likely that ObjC++ will be in 4.1 than in 4.0. Go read the gcc list archives for all the gory details.

Fortran?

[Anonymous Coward]

I know how much this looks like trolling ... but Fortran ... why?! After all this time, all the best open source software is written in C. C is the only language I know and the only one I ever will need to contribute to open source ... I don't know of anything written in Fortran.

Re:Fortran?

[Anonymous Coward]

Just because you don't know of anything written in fortran, doesn't mean there isn't any.

Given that you say C is the only language you know, you're probably are a clueless n00b anyway.

Otherwise you'd perhaps have a clue like: Almost all the worlds' scientific software is written in fortran. And a heck of a lot of it is Open Source. (And the rest of it

SSA...

[ndogg]

I know that SSA isn't a new piece of technology, even though it is new to GCC. I'm just wondering what other compilers have been using it, because I don't know. I tried googling for it, but all I could find was information about GCC.

This is an honest question, not a troll.

Re:SSA...

[devphil]

Pretty much every compiler in serious production use uses SSA internally.

Re:SSA...

[Anonymous Coward]

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.

The optimizations enabled or radically improved by Tree SSA are:

* Scalar replacement of aggregates
* Constant propagation
* Value range propagation
* Partial redundancy elimination
* Load and store motion
* Strength reduction
* Dead store elimination
* Dead and unreachable code elimination
* Auto-vectorization
* Loop interchange
* Tail recursion by accumulation

In addition to these generated-code optimizations, 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.

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.

Mudflap and buffer overflows

[Anonymous Coward]

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

I'm glad Mudflap is going to be built-in, but I think it's moronic to turn it off for finished products. Given a choice between safety from buffer overflows and a 5% speed-up, which would you choose for most of your software (desktop and server)? It's pretty obvious to me. I wouldn't even notice a speed difference of even 10% or 20% on most applications, but I sure would notice a buffer overflow that lets all my data get swiped.

Why is a trivial performance gain more important than safety? I'll never understand this type of thought, but that seems to be how a lot of developers think.

Re:Mudflap and buffer overflows

[Anonymous Coward]

Um... right.

You realize that, once MudFlap detects a possible buffer overrun error in the code, you can fix it, right? And then, it's not there any more? That's what MudFlap does. It CHECKS for buffer overruns. It's up to your lazy ass to fix it. Leaving it in a production version is worthless... unless your end users want to be informed that the programmer was too lazy to fix buffer overruns that he knew about. It's a 5% slowdown, or a 0% slowdown for fixing your damn code and not using mudflap in a production version. NOW which would you choose?

Re:Mudflap and buffer overflows

[Anonymous Coward]

i am sure a gamer would notice it if Doom3 was
buit whit that enabled.

-Bob

not exactly new

[Baki]

i remember using a 'vectorizing' fortran compiler on a convex "mini super" in 1988. It had vector units and in those days such hardware with automatically vectorizing fortran compilers was quite common.

I think convex even added vectorizing to its C compiler at the time.

Re:not exactly new

[Anonymous Coward]

I think convex even added vectorizing to its C compiler at the time.

Yes, a friend's father was one of the Convex founders (hi Dan!), and he showed me the vectorizing C compiler sometime pretty early on. We had been doing the Sieve of Eratostenes to find prime numbers in computer science class in school, and I'd grown interested in optimizing it. So, I went over to his house and we dialed into his dad's work (which graciously supplied him an account). We coded up a quick Sieve in C and ran it without the vectorizing compiler. It ran pretty fast.

Then he ran it through the vectorizing compiler and turned on some verbose output option, and it spit out a listing of which lines had and hadn't been vectorized. I remember looking at that display and thinking, "Holy snot! How in the heck did they make it do that?" It was like pure magic. I couldn't believe these guys had made the compiler, in effect, rewrite your program for you to take advantage of this hardware feature. All you had to do was run vcc instead of cc, and your program was suddenly many times faster.

By the way, the vectorizing C compiler was probably around long before the Fortran compiler, because I remember seeing it early on (maybe 1986 or even 1985?), and I also remember my friend saying Convex had swore not to include a Fortran compiler on principle (because Fortran sucks), but eventually they changed their minds and decided to include one, probably because customers really wanted it for scientific software.

Anyway, I think the ability to automatically vectorize would be a really cool thing to have in gcc. It would be helpful on the Mac (altivec) and on the PC (MMX, SSE, etc.). All these computers already have the vector hardware built into the processor, so it would be really nice if it could be used to speed up existing software without changing the source code. The only difficulty I see is compatibility and profiling. Just because these features exist on one processor doesn't mean they exist on all of them, and even if they do exist, it's difficult to tell which mode is going to perform better, because it will depend on the hardware. I'm sure the Gentoo folks will love it and go to town, but for regular folks, it is nice to be able to build a single binary that can run and run well on any machine of the same basic architecture.

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!

Re:What?!?

[Anonymous Coward]

patent it patent it!

how do you think the nsa gets our private keys?

Re:What?!?

[Anonymous Coward]

A compiler that inserts malware into binaries? Like this?

Re:What?!?

[Anonymous Coward]

Off the post-it on the front of your monitor you twit!

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.

BF

[Anonymous Coward]

I think I've seen a compiler that compiled to BF code... or maybe it was the other way around. heh. :)

Functional languages...

[Anonymous Coward]

I'm eagerly awaiting 4.0 so functional language compilers (like GHC for Haskell) which spit out C code will be able to take advantage of the benefits of SSA (Single Static Assignment)

emacs?

[simonwalton]

A question... for what reasons mainly do you find vim more suitable for programming than say, emacs? I've recently become used to emacs for my C++ stuff, but I'm wondering whether to switch to vim at the cost of having to remaster the kb bindings.

Re:emacs?

[Lisandro]

It's a matter of personal taste, mostly. VIM, IMHO, is more focused on editing text than Emacs, which tries to cover everything that is to be done in a computer - i've even seen an IRC extension to it. Overkill.

I got used to VIM pretty fast. It handles syntax higlighting just fine, works great with several documents at the time and scripting is a breeze. Right now, when i code i just use a big GVIM (with the "darkblue" theme) window and a console, and it's pretty much enough.

Re:emacs?

[Anonymous Coward]

check this out too.

Re:emacs?

[downbad]

emacs goes against the unix philosophy of having many pieces of software that do one thing and do it well.

for a lot of people, emacs is practically its own operating system.

Re:emacs?

[Anonymous Coward]

If the only thing you notice about emacs is the keybindings, you're not using it correctly. You might as well use an inferior editor like vim.

If you take the time to learn emacs-lisp and modify your editing environment, you'll get the benefits of a decent code browser, on-the-fly syntax-checking, debugging, refactoring, etc. all integrated in one place. If you like vim or notepad (we're already stooping to vim, why not one level further?) keybindings better, you can get those too without leaving the benefits of the emacs environment. (Check out viper-mode for example.)

Re:emacs?

[Anonymous Coward]

It doesn't, Emacs consists of a lot of small pieces that do one thing well. It's a self-contained enviroment, so this is not visible if you think about everything that Emacs does as the result of one program.

How about support for older levels?

[harris s newman]

I have programs for 2.95 that won't even run under 3.x ... any chance of having backwards compatibility?

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.

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.

Re:How about support for older levels?

[Ohreally_factor]

Listen to your compiler's warnings; you ignore them at your peril.

I felt a disturbance in the source. It was as if a million lines of code cried out and then suddenly were silenced.

Sorry if I didn't get the quote exactly right.

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

[Anonymous Coward]

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?

Well, I wouldn't say 'dropped', because AFAIK, nobody ever really worked on it.

But yes, there are a number of people in GCC who really want it, and still do.

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

[Anonymous Coward]

No surprise there, high-and-mighty prick thinks he knows better than everyone else.

Do yourself a favour and go back to coding, you obviously have no social skills worth mentioning.

Re:Major Features Dropped From GCC 4.0

[mandolin]

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.

Is there a patent issue or other GPL problem, or what?

Re:Major Features Dropped From GCC 4.0

[Anonymous Coward]

The pot calling the kettle black..

Re:Major Features Dropped From GCC 4.0

[snorklewacker]

If the LLVM developers don't mind having their LLVM code incorporated into GPL code (which isn't required, but it's nice to ask), what the hell can RMS do about it? Does the FSF contribute any code or money to GCC development?

He wrecked emacs for over a decade. Do you want that for gcc?

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

[Anonymous Coward]

If the LLVM developers don't mind having their LLVM code incorporated into GPL code (which isn't required, but it's nice to ask),

They don't.

what the hell can RMS do about it? Does the FSF contribute any code or money to GCC development?

While RMS is on the GCC Steering Committee, he has a lot of clout with it. The FSF owns GCC, all code is assigned to them. Red Hat (formerly Cygnus) are the ones who contribute the most code and money.

See the history of GCC and the EGCS fork if you want to see an example of where RMS had to fold before.

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

[Anonymous Coward]

Stating one's opinion is not slander (at least in the US).

Re:Major Features Dropped From GCC 4.0

[DAldredge]

How would adding LLVM harm GCC?

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.

Re:Major Features Dropped From GCC 4.0

[vhex]

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.

Could you please explain in two words why would that make the process much faster, and how would that differ from translating all units with a single command?

Re:Major Features Dropped From GCC 4.0

[Dulimano]

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.

Would you tell us some more about this restriction? Is it a legal or a technological one? I'm very curious. Thanks in advance.

Re:Major Features Dropped From GCC 4.0

[puetzk]

Basically GCC is not to emit or accept any standardized IL sufficient to separate backend from frontend completely. This is intended to ensure that a proprietary backend cannot benefit from GCC's language support, nor a proprietary language from GCC's optimizers and CPU targets; you must instead integrate with GCC-specific internal structures, ensuring that you are politely compelled to GPL your addition if you want to use the rest of GCC.

Re:Major Features Dropped From GCC 4.0

[Per Abrahamsen]

Having a standard intermediate language would make it easier to make proprietary front-ends and back-ends to GCC, which goes against the political goals of the GNU project.

However, having a standard intermediate language would also make it easier to make free software development tools, which would be contributing to the political goals of the GNU project.

Until now RMS have believed drawbacks outweighted the benefits. However, as technology progress and free software get more widespread, I believe the benefits will (or may already have) outweight the drawbacks.

Re:Major Features Dropped From GCC 4.0

[Anonymous Coward]

Sounds like RMS is protecting gcc, good for him.

Then it's a bit late to start now. GCC is GPLed, don't you know, with all the guarantees of forkability and freedoms that entails. If a company wants to fork GCC to write out intermediate code then RMS *cannot* stop them. His only hold is on what's included in the FSF's GCC distribution.

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.

This is why open source is useful

[pjc50]

If you have source, binary compatibility isn't such a big deal.

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.

Re:Yes, it's true

[Anonymous Coward]

It should be noted that in almost all cases where the Intel out-shines the others, it is in tight loops. Benchmarking code, scientific calculations etc. This is most likely due to the auto vectorization that the Intel compiler can do. It can break apart tight loops and do multiple operations at the same time.

For the most part it's about the same speed as GCC/MSVC when running general purpose code.

Re:Yes, it's true

[Anonymous Coward]

The wicked fast Fortran compiler isn't because Intel developed it internally, but because they acquired the old Alpha compiler group from Compaq. Same with the newer C compilers. There are many reasons why Alpha was the fastest in its day...

Re:Yes, it's true

[ameline]

IBM has some pretty rockin good fortran compilers for their machines. Why do you think the Power5 benches so well on SpecFP? (The chip is pretty awesome, I admit, but it needs a good compiler to get the last bit of performance out of it) The IBM XL compilers are just amazing.

Re:Yes, it's true

[Salis]

I'll second the part about Intel having a kickass Fortran95 compiler. Using interprocedural optimization speeds up programs by like 2x compared to not using it.

And the Linux version is FREE (as in beer) for non-commercial usage.

Re:Yes, it's true

[Salis]

Except that the IBM's xlf Fortran95 compiler only accepts .f files.

Why, why, oh why?! It is really, really annoying (and I've seen no flag to auto-convert .f90 files to .f).

Re:Yes, it's true

[Anonymous Coward]

Actually, the current Intel Fortran compiler is based on the old Kuck and Associates Fortran compiler, and the same people from K&A are still working on it.

Re:Yes, it's true

[Anonymous Coward]

Tom's Hardware: Painting a New Picture of Pentium 4: Tweaked MPEG4 Encoding

Re:Yes, it's true

[joib]

Except that the IBM's xlf Fortran95 compiler only accepts .f files.

Why, why, oh why?! It is really, really annoying (and I've seen no flag to auto-convert .f90 files to .f).


Uh, ever read the man page? ;-)

"xlf -qsuffix=f=f90 file.f90" does the trick.

Re:Yes, it's true

[Salis]

Well, thank you very much.

I've read through the --help for xlf about four times without finding that flag.

Re:Yes, it's true

[Anonymous Coward]

Yep. I'm surprised this wasn't modded up.

Slashbot morons as usual.

quote...

[Cryptnotic]

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

--not Benjamin Franklin

For real speed

[WindBourne]

do parellel compiles across multiple systems. Most geeks own at least several systems (normally quite a few more). There are plenty of good parellizing tools.

Oi! Mod parent up!

[devphil]

That's a good URL, but the post is buried in 0-point-ness. Moderators, some love here, please?

But if faster has been decremented...

[SuperKendall]

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

AutoConf isn't part of GCC

[Anonymous Coward]

AutoConf isn't part of GCC. The only alternative to autoconf that I know of is PMK.

Re:AutoConf isn't part of GCC

[Look KG486]

Understood that autoconf isn't part of GCC. Just stating that I'd like to especially see autoconf get smarter about what it has to check for and only check once.

Implementation of C++ standard in gcc 4.0

[Anonymous Coward]

Does anybody know how much of the C++ standard is implemented in gcc 4.0, especiallly regarding templates and the STL? Until now, what I have heard, the Microsoft compiler was the most up-to-date C++ compiler around. Did gcc 4.0 catch up?

Re:Implementation of C++ standard in gcc 4.0

[msbsod]

Two half compilers are not the same as one complete compiler.

Re:Implementation of C++ standard in gcc 4.0

[Anonymous Coward]

That's funny. Microsoft's compiler issues an error if you don't have a return from main (which the standard says isn't required!), so don't tell me it's up-to-date at all.

C++ memory management

[Peaker]

C++ memory management has a form of "GC" which is usually done via reference counting, auto_ptr's, etc.

If this is not used, and memory is completely manualy managed for performance reasons, it is no longer "good C++". With today's algorithms, requires O(n) to allocate (n being a function of the available memory count or hole count, depends on the scheme) and O(n) or O(1) to free (in the case of O(1), allocation is typically inefficient.

With good generational GC, you can get O(1) allocation, O(1)-amortized freeing (O(n) memory restructuring once "every n free calls"). The downsides are an extra dereference on every ptr, but this can be overcome with smart paging tricks and/or "safe" zones where GC won't be called (the dereference only has to occur once in those).

In theory, there is no reason for explicit memory management to be slower than any form of GC, but in practice (of existing methods), manual memory management is actually of far worse performance than good GC. Unfortunatly, this is also true of GC, which is also implemented in a very unideal way.

Anyhow, in conventional C++, every ptr assignment requires increasing/decreasing a refcount, which is more expensive than periodic mark and sweep under some scenarios of cache locality.

Its way too complex to compare GC to non-GC in theory as they are affected by too many factors. All existing implementations of both GC and malloc/free are highly inefficient, so benchmarks are also moot.

Maybe in 20 years we'll reach a concrete conclusion on that one ;)

Re:C++ memory management

[Anonymous Coward]

Actually, I kind of doubt any conclusion being reached..

To rephrase your points: I think the whole thing is a lot like discussing stick-shift vs manual-shift on cars. In the real world, a manual shift has the potential be more efficient. In practice, it very seldom is.

Some people still prefer manual-shifts since they either like the sense of control, or because they overestimate their ability as a driver. (and then there are the precious few who actually do a better job than an automatic)

Re:C++ memory management

[stripes]

C++ memory management has a form of "GC" which is usually done via reference counting, auto_ptr's, etc.

The auto_ptr isn't really reference counting. It is more of a "pointer with ownership passing". Anytime you do "x = y" with an auto_ptr it is really "x = y; y = NULL;". The auto_ptr has the advantage of being cheap. It has the significant disadvantage of being really confusing, and only sometimes being what you want (and not working as the contents of most STL containers).

There is no standard C++ reference counting smart pointer. Boost's shared_ptr has been proposed as one for the next round of C++ library standards (and may even have been accepted), but it isn't in the current C++ standard, so it isn't universally available.

It'll be nice when shared_ptr gets into common use because weather or not it faster then GC, it sure beats the hell out of trying to figure out when you should free something, when you can't free it, and when you need to make and track a private copy because someone else will free it.

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

[Anonymous Coward]

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

It killed it because unless you write in a vaccuum you have to write to the lowest common denominator of major compilers if you expect to distribute or port your code. This is espeicially true if you write open source, scientific code. Your code might be "free" but no one can even test drive it or merge it into a major application enviroment without shelling out big bucks for a pro-fortran compiler. This is escpecially the norm in academic and biosceince circles where no one is interested unless it runs on a gnu compiler. Its alos the norm in all cross platform numercial analaysis packages like R, Numeric Python and Octave. Those packages which do much of their numerics in fortran have to use cripled libraries to accomodate g77 and g95s missing syntax. No wonder people prefer C and C++ these days.

that is why the cripled implementation of g95 was what doomed F95.

Re:Gcc killed fortran

[Anonymous Coward]

Yunno, if gcc was the only Fortran compiler around, perhaps it was already dead, and gcc just declined to give it more life support. Think on that.

Re:Gcc killed fortran

[Aardpig]

It killed it because unless you write in a vaccuum you have to write to the lowest common denominator of major compilers if you expect to distribute or port your code.

No, you write code conformant to the Fortran 95 standard. Then, any compiler can compile it, including g95.

Those packages which do much of their numerics in fortran have to use cripled libraries to accomodate g77 and g95s missing syntax.

That you mention these wholly-separate products in the same breath suggests you don't really know what you're talking about.

that is why the cripled implementation of g95 was what doomed F95.

That you use the past tense, when g95 is still in beta, is incontrovertible evidence that you don't have a fucking clue what you're talking about. Now piss off, you troll.

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:Gcc killed fortran

[Anonymous Coward]

So you'd prefer it if platform vendors didn't offer any Fortran compiler, instead of offering a functional compiler that can only offer a sub-set of Fortran? You'd have a great "lowest common denominator" then, wouldn't you?

Re:Gcc killed fortran

[saigon_from_europe]

My favorite parts of fortrans are that one cannot overflow a buffer nor is it possible for a typo to compile.

Except that code

do 10 i = 1, 3
some code
10 continue

was once made by typo

do 10 i = 1. 3
some code
10 continue

which made a compiler to think it was

do10i = 1.3
some code
10 continue

And that crashed an expensive rocket.

Re:Gcc killed fortran

[feenberg]

> you could never detect EOF's on pipes to fortran 77.

Well, I do it all the time:

read(5,*,end=99) a

branches to statement 99 on EOF, from a file or a pipe. This is exactly the standard, and works on
all Fortran 77 compilers I have encountered, including Unix f77 and f2c.

feenberg isat nber dotte org

Re:Gcc killed fortran

[Aardpig]

That is an urban legend; while that particular mistake can be made in Fortran 77, it did not cause any sort of accident. Check up on Snopes.

In Fortran 90/95, using the preferred free-form source, spaces are no longer allowed in identifiers, and the erroneous code will no longer compile.

But hey, this is Slashdot, so dont worry; it's OK that you don't have a fucking clue what you are talking about.

Re:Gcc killed fortran

[saigon_from_europe]

But hey, this is Slashdot, so dont worry; it's OK that you don't have a fucking clue what you are talking about.

I posted (recently valid) piece of code that confuses compiler, and you say I don't have a fucking clue... Really, this is what you can expect only in Slashdot.

I agree that I did not know if it was urban legend, but for sake of correctness, you should notice that not-so-old Fortran was typo prone.

Re:Gcc killed fortran

[Anonymous Coward]

Thank you FSF for gcc-4.0. You guys r0x0rs. I love you all :)

How many fortran 95-features will be included in gcc-4.0? Will it have pointers and classes and all? Can I trust it for numerical calculations? Does it work well with numerical python?

I have been dreaming of structs in g77 for a long time, but a fullfledged fortran 95 would just be fantastic :)

While I am at it. Is there a way to turn on enhanced type checking in g77? Suppose I pass a real*8 to a subroutine that requires a real, then I would really my compiler to complain.

Re:Gcc killed fortran

[richmaine]

Pointers - yes. Classes are an f2003 feature - not f95, so no. Gfortran is a full-fledged Fortran 95. But it isn't quite yet ready for production use IMO. Hopefully soon. It doesn't compile my f95 codes, for example. G95 does compile my codes today. See other posts about the Gfortran/g95 split.

On your type-checking question: For f77, look into separate tools like ftnchek. For f90, put all your procedures in modules and all f90/f95 compilers will check thingsg like this. Although the f90 standard doesn't quite mandate such checking, it sure encourages it... and every actual f90/f95 compiler in existance (including gfortran and g95) does it.

Re:What we need is configure & make optimizati

[msbsod]

The fact that almost all Unix C/C++ software requires something like autoconf or imake says everything about the software development environment, doesn't it? IMHO it stinks like rotten eggs from the 60's.

don't do it...

[Cryptnotic]

They always either break the scripts for making cross-compilers or something will break with glibc. Or it will break with uClibc. Or it'll require a specific version of binutils, or some other problem.

Re:don't do it...

[cbreaker]

But on the bright side.. a lot of software compiled by GCC is open source, so people fix it!

Ahh, the cost of advancement.. It's frustrating when GCC/glibc breaks but somehow everyone's linux boxes keep on truckin'.

GCC/glibc are the staples of the OSS world, and I think the devs do a great job. They try to make things compatible and keep things as smooth as possible but sometimes it just can't happen if the system is to move forward.

As the entire GNU/Linux suite matures, problems like incompatibility between version skews will continue to be less of a problem.

How about working with cfront instead

[WindBourne]

in 1990. Yeah, I remember early g++.

Compiler incompatibilities

[msbsod]

Apropos compiler incompatibilities: do the new GNU compilers still add funny things like useless trailing underscores for non-C routines by default? And how about Fortran character strings, are they still passed with a hidden argument for the length in addition to the formally declared argument (address) or have the GNU people by now figured out why, for example, VMS compilers use a descriptor (structure) to describe complex arguments?

Re:Compiler incompatibilities

[cburley]

[...]about Fortran character strings, are they still passed with a hidden argument for the length in addition to the formally declared argument (address) or have the GNU people by now figured out why, for example, VMS compilers use a descriptor (structure) to describe complex arguments?

GNU isn't a clone of VMS; rather, a clone of Unix, so compatibility with f77, f2c, etc. was more important during g77 development than was replicating the VAX/VMS FORTRAN environment (though some of that background did find its way into the g77 front end, at least early on).

Besides, VMS's descriptors weren't just about catering to the CHARACTER type in Fortran, but about a full range of inter-language capabilities that was offered by that architecture. GNU hadn't, and to my knowledge hasn't since, attempted to similarly cater to the (fairly tiny) audience for such a comprehensive range of capabilities. It would have been counterproductive for g77 to try to serve as the launching-pad for such capabilities; just getting the GCC people to recognize the utility of certain optimizations that would help Fortran code was nontrivial.

Whether g95 uses descriptors by default (for FORTRAN-77-compatible CHARACTER types), or sticks with the hidden-argument approach for compatibility with g77-compiled (and f77-compiled and f2c-compiled) code to which its own compiled code might be linked, I don't know. Check the web site. But for some F90 features, much more sophisticated handling of argument-passing to procedures (than g77 ever did) would certainly seem to be necessary.

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

[Anonymous Coward]

Working for a company that makes engine tuning products (Diablosport) I can say we sure do use GCC for quite a few of our products. Several different versions, but no 4.0 yet.

Shocking, isn't it?

[Dr. Zed]

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

Yes. Compile-time errors now introduce an electric shock through the keyboard and mouse.

Apparently, the key to quick compile times is ellimiting the hackers who need to compile more than once to get it compiled.

Re:PathScale... GPL

[Anonymous Coward]

I just looked at their website. It had all kinds of language about part GPL and part non-GPL and you've gotta ask for the GPL source, and they say that you may be stuck if you don't have the non-GPL stuff, and ...

Looks like it's begrudging compliance with GPL.

Speaking of literal compliance ... I've seen that this new gcc has a new back-end and that it's unlikely that anyone will actually get the front end of the ada part of gcc to talk to it. Anyone want to say how long it will be until someone can do a relatively straight install of gcc (linux and mingw) and have C, C++, and Ada all in and working and producing compatible object code?

MOD UP, ggc is to fortran as MS is to java

[Anonymous Coward]

Amen. My company moved to C++ from fortran just for that reason. It's almost like the way microsoft killed java by creating a buggyreduced implementation of it as the defacto standard.

Re:MOD UP, ggc is to fortran as MS is to java

[Aardpig]

My company moved to C++ from fortran just for that reason.

Well, then, your company is managed by a group of ignorant fucktards. To go through the perils of a language switch, purely because you are dissatisfied with a free compiler, is one of the stupidest business decisions I can imagine.

Re:MOD UP, ggc is to fortran as MS is to java

[goombah99]

>>My company moved to C++ from fortran just for that reason.

Well, then, your company is managed by a group of ignorant fucktards. To go through the perils of a language switch, purely because you are dissatisfied with a free compiler, is one of the stupidest business decisions I can imagine. Well no, it makes sense because like most hardcore scientific software they sell source not binary

", which" vs. " that"

[tepples]

do you really not recognize a phrase intended for the portion of the audience that doesn't know what a compiler is?

The construction "a compiler, which does foo" defines compiler, while "a compiler that does foo" implies that foo is specific to this compiler. There's a difference. If that's grammar national socialism, then Sieg Heil!

Re:", which" vs. " that"

[Chris Burke]

Yes, there's a difference. Feigning misunderstanding of the intent based on that difference is indeed being a Grammar Nazi. If you wish, you can email the author of the story to let him know of his grammatical error. Anything else is pedantry for the sake of pedantry, or Grammar Nazi Masturbation.

A side benefit of templates...

[CatOne]

Morons like myself that don't code for a living can no longer understand WTF is going on with the code, so we can't get our hands dirty and screw things up.

Next step, shaving the center of my head and molding the sides into nice little pointy things. The transition has begun.

Once again, Richard Stallman holds back progress

[Anonymous Coward]

Are his defenders going to justify it this time? Now we get to lose out on a good technology because it doesn't fit into Stallman's world view. That's fascist.

Moving quickly

[slapout]

It seems the move from 3 to 4 happened much faster than the move from 2 to 3.

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

I Hope ...

[Anonymous Coward]

That they leave in the -std=c89 flag. I'm supporting a big system from a company that invented non-compatible versions of the c99 math library functions a little bit ahead of time.

Patents?

[tepples]

(invented in the early 90's)

Doesn't that mean (not available for use in free software until the early 10's)?

Re:Patents?

[Anonymous Coward]

It was only shown how to practically implement it in real code in the early 90's by Cytron et al. The idea is much older.

Nonsense

[Kergan]

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.

Delivering VB with an IDE and a bunch of libraries is what turned the... thing?... into a huge success. GCC, the developpers behind it, and the developpers who use it deserve more than silly statements such as this one.

Re:Nonsense

[Guy Harris]

Delivering VB with an IDE and a bunch of libraries is what turned the... thing?... into a huge success.

Delivering the Linux kernel with a C library, and other libraries and user-mode code, was certainly necessary to turn it into a success in many applications (such as the "general-purpose OS" application).

That still doesn't mean it's the Linux kernel developers' job to ship all that additional code; it's the Linux distributors' job. Somebody could bundle GCC and a pile of libraries into a distribution (heck, some people do bundle it in that fashion, although they also thrown in a Linux kernel and some other stuff along with it :-)), and perhaps a "division of labor" in which the people who bundle aren't the same as the people who develop the component is the right answer. (I suspect having them cooperate, and having the developers of various components of the bundle cooperate, would be a Good Thing, but that's a different matter.)

Re:Nonsense

[Anonymous Coward]

Delivering VB with an IDE and a bunch of libraries is what turned the... thing?... into a huge success. GCC, the developpers behind it, and the developpers who use it deserve more than silly statements such as this one.

Compiler, IDE, and Libs are seperate projects that your software distribution agent usualy bundles together to make a worth while enviroment to work in weather they are MS, Borland, Codewarrior, RedHat, etc... Have never noticed most professional development enviroments allow you to use third party replacents for most if not all of its components? (yes, replacing 3 of 3 is a special case, but still an option.<eg>)

Re:Nonsense

[Per Abrahamsen]

If you think a GCC + a bunch of libraries distribution is a good idea, make one! Don't expect GCC developers to do it for you. They are quite busy making GCC the best compiler it can be. That is what they do best, they are not "bundlers".

Dog* dog= cast(cloneAnyAnimalFromFabric());

[Anonymous Coward]

C++ Co-Variance checking fails in GCC-3.3.x & GCC-3.4.x.

And GCC-4.0 too?

open4free ©

confused: gfortran vs. g95

[tetabiate]

what are the differences/advantages of gfortran over g95?

Re:confused: gfortran vs. g95

[cimetmc]

G95 http://www.g95.org/ is the original project started by Andy Vaught. However given that the other people who wanted to contribute had problems with Andy's rather closed development, they finally decided to split off and continue their efforts on Gfortran http://gcc.gnu.org/fortran/ which has since become part of the main GCC development tree. More details can be found at http://www.gfortran.org/index.php?n=Main.TheOtherG ccBasedF95Compiler

This is rather unfortunate as both projects just advance slowly as they suffer a lack of developpers.

Marcel

Multiple Files

[Zan Lynx]

Yeah. And you should see what happens when you decide to get crazy and put every file in your project on the command-line with -funit-at-a-time.

700MB of RAM usage and 78 minutes of compile time (on a 2.2GHz A64). But boy was that code optimized!

*grin*

Eclipse

[cyfer2000]

Can Eclipse be one?

C++ is an order of magnitude more complex than C

[EmbeddedJanitor]

C++ is a very complex language and the compiler therefore needs to track a lot more stuff than a C compiler.

The only way to make you happy would be to build in a slow-down to the C compiler (which would make the kernel folks -- amongst others) a bit sadder.

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]

Yes, anyone who badmouths RMS is "ranting incoherently" about our Dear Leader.

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:Can anyone elaborate on this LLVM v. RMS issue?

[808140]

It's not that. It's that those of us who have been around for a while have learned something about RMS: agree with him or not, he usually has insightful reasons for his positions, and he backs them up very well.

Too well, in fact. The result is that most people that disagree with him don't bother trying to refute his points, because his points are simply too well argued. Instead, they resort to ad homniem attacks -- either some snide remark about GNU/Linux, or hygiene, or his beard, or whatever.

The result is that those of us that care what he has to say immediately discount any presentation of RMS's stance that is littered with such juvenile drivel. This isn't to say that RMS can't be wrong -- he's certainly said some things I disagree with. But then, this is hardly surprising, as different people generally have different opinions and any free thinking person will inevitably have opinions of his own.

Experience has shown that people that hate RMS with a passion are generally threatened by his ideas and the sway that they have in the hacker community. They often (but not always) lack the intellectual rigour to actually argue with him convincingly. So they take the "you can't agree with that GNU/Hippy bearded zealot, can you?" tack. Slashdot has a lot of morons like this lurking around.

If RMS dislikes something, he probably has a good reason for it, and behooves us to know what that reason is. Once we know, we can make up our own mind about it.

The people that follow RMS blindly are just as stupid, really, as the people that blindly discount everything he says. But the fact remains that RMS is an extremely thoughtful and intelligent guy. His opinion matters.

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

[StrawberryFrog]

LLVM would provide a clean interface between portions of gcc, and that clean interface could be so abused.

Good design is good design. Couldn't a clean interface also be used?

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

[rmathew]

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

RMS does not like the idea of GCC producing a machine-readable intermediate representation of the input program for fear of this being used by people to subvert the GPL to create proprietary back-ends that build on the power of GCC but do not contribute anything back. For the same reason, he was opposed to the idea of the GNU Compiler for Java (GCJ) producing Java bytecodes. This is one of the main reasons why GCC does not completely output its intermediate representation.

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

[jesup]

Not a bad point. I've interacted with him a few times (by email Way Back When in ~1986) and in person a few times (back in the 80's).

Philosophically I have serious problems with his position - not that that's unusual. And yes, he does defend his positions well - but always remember that they're based on his social philosophy; he sees all of these issues as levers to use in getting to his social goals. And like most absolutists of any nature, the majority of people (including his supporters) might not like the results if he got his way in any major manner.

In this case, he's trying the Jedi Mind Trick: hoping people ignore what's in plain sight. LLVM may make it slightly easier for someone to write an external utility to crunch on IR data - but only a bit. As was pointed out, they can do it today and just release the changes to GCC that make the IR code visible. Poof.

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

[808140]

I agree completely.

GCC 4.0 is first of all technology enabler

[Anonymous Coward]

The most important thing about GCC 4.0 is that
it is an enabler for all kind of interesting things in the future.

The Tree-SSA infrastructure add a very solid base that
allows future optimizations to be written much easier than before.
For example there are 50+ NEW optimization passes
(not all unique) that are now run at the tree level.
Optimization passes are MUCH easier to run at the tree
level as there's more high level information available, and it
does not require detailed knowledge of the target machine.
You will see more an more optimizations added to GCC.
Another thing that 4.0 will allow is easier integration
of new front-ends for other languages. Now the front-ends
are better separated from the rest of the compiler.

There are things that still need work, for example
some aspects of alias analysis is not as good at the tree level as it
is at the lower RTL level.

So expect even more improvements in 4.x, x>0

don't need configure anyway

[r00t]

Come on people:

sizeof(int)

Re:don't need configure anyway

[Anonymous Coward]

The problem is the definition of the word "byte". In C and C++, "byte" actually means "char" (that is to say, sizeof(char) is defined to be 1). In the rest of the world, "byte" means "8 bits". Therefore, "size of int in bytes" is an issue in cases where you're relying on the number of bits in an int rather than the size relative to a char. Frankly though, this is why C++ has numeric_limits or whatever the class name is and C has limits.h, but maybe using configure is faster or something.

Re:don't need configure anyway

[r00t]

Well, if you want to be picky:

• an octet is 8 bits
• a char is at least 8 bits
• a byte is whatever

It turns out that it is impossible to comply with the UNIX and POSIX standard unless char is 8 bits. What else do you care about? Windows, MacOS, VMS, BeOS, AmigaOS, MS-DOS... all have an 8-bit char. The only current systems without an 8-bit char are a few of the more messed-up microcontrollers and DSPs.

So go ahead and use the sizeof operator.

Tradeoff between C and C++?

[rice_burners_suck]

And software written in the C++ programming language should run faster--"shockingly better" in a few cases.

In the 3.x series of GCC, the output for C language programs has degraded somewhat in terms of execution time and size, while the performance of C++ language programs has improved somewhat.

I hope this apparent tradeoff doesn't go a step further in the 4.x series, as most of my work is still done in C.

Re:Tradeoff between C and C++?

[devphil]

Sorry to disappoint you; in 4.0, C++ code is highly optimized to produce the best assembly possible. C code is now converted into Bourne shell and written out as text.

Look at ICC's feature list

[r6144]

For me (floating-point intensive C programs on a P4), ICC and GCC's performances are usually very close, unless autovectorization works for the most time-consuming loops (which is rarely the case in my program) or when a lot of sin/cos/exp functions are called (ICC has a very well optimized SSE-based math library which GCC lacks). Other differences in instruction scheduling, register allocation, inlining, etc. usually have significant effects only in very specific cases.

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

[smittyoneeach]

I think that this concern is real, but I question its magnitude over time.
In another decade or so, when the idea of FOSS is more firmly rooted, I hope that this (legitimate) paranoia can be deprecated, and removed.
The Emacs Great Schizm both

shows the amount of mindshare that can be wasted trying to manage two separate, but nearly equal, codebases

shows the non-threat of supporting better integration

shows the threat of avoiding better integration, as other tools spring up to support pragmatic requirements that fall short of a subjective, ethical line.
Props to RMS, but we gotta move on.

Re:how LLVM would harm gcc

[Anonymous Coward]

It is not at all far-fetched. Companies have attempted similar tactics with GCC in the past, and there is every reason to believe that this would actually happen again. Of course, on the other side there are research projects that wanted to use GCC and contribute code back to the project, but were forced to go with proprietary alternatives because of the restrictions with respect to IR code. So neither side of the argument involves far-fetched ideas.

Re:how LLVM would harm gcc

[True Grit]

In another decade or so, when

In another decade or so, gcc will be obsolete if it doesnt continue advancing. RMS is just punishing everyone who uses gcc, and risking the possibility that gcc gets overtaken by some other compiler system. The new IR representation and optimization framework called tree-ssa in GCC is already in LLVM, its the feature LLVM was designed around, and being written in OO C++, LLVM is easier to work with. And LLVM isnt the only thing cooking out there... By keeping his head stuck in the sand, RMS is just hurting GCC.

Not yet...

[Anonymous Coward]

I'm waiting for the WYRMWYW (What You Really Meant When You Wrote) technology to be incorporated into GCC, so it will fix all my bugs as it compiles. Then I'll upgrade.

Re:Not yet...

[devphil]

This is usually spelled "#pragma dwim" (do what I mean[t]), and is the holy grail of compiler technology. And managers.

my guess

[jbellis]

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

Re:my guess

[dudeX]

Serious question: What if RMS retires, would the GCC team have more liberty to include useful code projects?

Just think of Dilbert

[Anonymous Coward]

Dilbert: (watching C++ program compile) "Do you realize what this means??"

Wally: "Hey! You're getting paid to do that!"

Including solaris on x86?

[cyfer2000]

wow, it's unbelievable.

Shocking indeed

[Salamander]

If C++ will run "shockingly better" that necessarily means it was shockingly bad to start with. It's like when Microsoft came out with FAT32 and claimed it would give you more usable space...but didn't go into the details of how they'd been pissing away your space before. "Yeah, we suck less!" Where's that eye-roll punctuation mark when I need it?

Re:Shocking indeed

[bluGill]

If C++ will run "shockingly better" that necessarily means it was shockingly bad to start with.

Clearly you have never worked with C++ under gcc compared to other compilers, or this would not be a surprise. Gcc is free, and it works good enough on just about every platform. Nobody makes the claim that it is anything other than bad. However it is normally good enough, so we use it anyway.

Re:Shocking indeed

[m50d]

Everyone knows it takes shockingly long to compile C++ with gcc, but before gcc there wasn't even a real C++ compiler at all. So we put up with it. But just look at any KDE thread to see that everyone knows gcc's C++ performance sucks.

what we need in C

[Anonymous Coward]

is a for loop inside a printf statement :)

and why can't they add ADA inside C?

we should have a way of declare function as

ADA funka(...) ..etc
C++ funkb(...) ..etc
JAVA func(...) ..etc
COBOL fund(...) .. etc

Re:Ahhhhh... Time to start compiling all overagain

[downbad]

If your memory is that constrained, you should not be using C.

Re:What we need is configure & make optimizati

[cant_get_a_good_nick]

As an acually worse example, I'd like to point out the software that uses shell scripts to run configure. If you need a script to run a script, you have UI issues.

Considering what it's doing (making software compile and run on different hardware, OS, and lib variations), using configure isn't that bad. most cases you can do

configure && make && make install

. Creating these monstrosities, that's the not so fun part.

If you're comparing to MS tools, remember you're targetting a single system. That has it's own plusses and minusses. And if you think MS stuff always rules, I remeber doing driver work on Win32 and Win98 and I needed 3 seperate compilers (1.52 for the 16 bit thunk DLL, 4.0 for the VxD, and 5.0 for application code). Tools suck usually, they're generally best when they get out of the way as easily as possible.

distcc and ccache is better than compile server

[Anonymous Coward]

Sorry, but I this compile server idea is a dog. Distcc is less error prone, far simpler and works even when preprocessor tricks are used. Your compile server makes a lot of assumptions that many popular projects break. Getting an "optimal" compile time is not practical nor is it useful. Sometimes the 90% solution (distcc) is the best solution.

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

Re:distcc and ccache is better than compile server

[Per Bothner]

Distcc doesn't save you time in preprocessing, optimizing, or code generation.

Ooops. On re-reading, I overstated this: distcc can speed up optimizing and code generation, since they get distributed. It can't speed up lexing or preprocessing, since that is centralized, and it loses the benefit of having the pre-processor and lexer interleaved, as Gcc currently does.

GCC4.0 snapshot available

[FlyByPC]

Found via Google... http://strawberry.resnet.mtu.edu/pub/gcc/gcc/snaps hots/4.0-20050109/

Re:Apple has been on the "leading" edge for a whil

[Anonymous Coward]

And it's absolutely horrible for any kind of C++ development. Look at Boost's C++ regression test suite results for gcc on Darwin - they are discraceful! The fact that they are branching in the middle of Stage 1 or early in Stage 2 has meant that they have a compiler that's about as bad as the infamous RedHat 2.96 series, only Apple, Inc puts out bugfixes even more rarely.

Its so bad, that I don't even use Apple's GCC for any C++ development; I always start by building a GCC/G++ from FSF's released codebase.

Re:What we need is configure & make optimizati

[Look KG486]

WTF offtopic?

Fortran 95

[elronxenu]

I want to know whether the Fortran 95 code will compile and/or run faster than C++ using GCC 4.0 :-)

Agreed

[Anonymous Coward]

Truly pathetic moderation.

I completely disagree.

[Anonymous Coward]

I disagree.

I can compile useful robot-control programs in C that fit in 208 bytes of program space using "C"

It controls two variable-speed DC motors and follows a black line on the floor.

That ain't too shabby for C

You should try compiling for something other than a Microsoft platform someday!

Re:I completely disagree.

[Anonymous Coward]

What does Microsoft have to do with the the fact that C is unsuitable for most <8Kb applications ?

for loop inside a printf -- gcc does it

[r00t]

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

Re:for loop inside a printf -- gcc does it

[CBravo]

I guess the formatting misses out on the < character.

Re:for loop inside a printf -- gcc does it

[r00t]

Yes, even though I used "Plain Old Text".

I'd love to have somebody justify the failure
to properly escape such characters. It's not
as if everyone knows and remembers which HTML
characters are special, and I sure don't see it
as being friendly or useful to just delete them.

The make replacement that I'd recommend...

[Anonymous Coward]

is SCons.

Pointer/int casting should be an error

[Anonymous Coward]

Maybe 99.999% of the world will disagree with me but I advocate breaking almost every program on earth.

I'd like gcc to flag as an *error* any pointer/int casting on all platforms. And believe me, as an amd64 user I guarantee you almost every program out there does this. It may be legal C and it may work OK on X86 but as soon as you move to an LP64 platform (basically every 64-bit platform) you will get burned.

We need to force the programs out there to get 64-bit clean in the first place. We shouldn't have to react to it after the fact.

Precisely

[A nonymous Coward]

That's what inspired me.

Reasons for Objective-C

[stivi]

Remember that gcc has Objective-C support only because NeXT was forced to abide by the GNU GPL.

Have you heard about a GNU project called GNUstep? Or have you heard about one of the largest open-source simulation environments called Swarm? They are quite large projects and both are based on Objective-C. And there are several other projects too.

Re:Reasons for Objective-C

[flimflam]

And you know that both of them are preceded by NeXT releasing their Objective-C front-end for GCC under the GPL, right?

Re:Reasons for Objective-C

[stivi]

Sure. Perhaps there was a misunderstanding. I thought that you were refering to the reason of ObjC existence as NeXT release only, not any current live usage.

Re:Reasons for Objective-C

[Anonymous Coward]

What's that got to do with anything? GCC, the GNU Compiler Collection, only has Obj-C support because when NeXT added Obj-C support to GCC, they were subsequently forced to abide by the terms of the GPL and release the source for Obj-C support. Exactly what the original poster said. So what does GNUStep or Swarm have to do with GCC?

Check the Dice add with the article

[TheAcousticMotrbiker]

please check out the Dice animated gif that comes with the article (you might have to reload to see it, as they might have changing adverts

if(threshold = salary_sucks)

= ?? on a GCC article ??
And that company claims to be high-tech ?

Sheesh .. tossers

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

tmpfs accomplishes similar things

[billstewart]

tmpfs is a file system type that keeps files in memory if available, or in swap space if the VM system feels like paging them out. It's been a number of years since I've actually used it (ok, over a decade ago on SunOS :-), but the principles still hold - it's especially useful for files that you don't plan to keep around once you've used them, like typical compiler temp files - often they're written, updated, read, and deleted without ever bothering to write them to a disk drive.

And RAM is cheap. Go buy some more of it.

Usenet..... while waiting for compiles

[billstewart]

OK, I did read the LOTD for a while, but it didn't waste any significant time compared to Usenet. After all, by the time Dilbert came out, it wasn't possible to read all of Usenet any more, even by printing it out 4-up double sided on the gimongous Xerox printer in the basement. (Though by about the time we had that printer, it was possible to use the mainframe in the basement to do compiles on, running some ersatz Unix version on Amdahls at a blazing 10 MIPS, with far more RAM and I/O horsepower than our Vaxen had...)

Maybe..

[Henk Poley]

You should read "The Pragmatic Programmer"? One of their tips is "Don't live with broken windows" (bad designs, wrong decisions, or poor code). When some part of your software is broken/bad it is easy to get into the mindset that all of the surrounding code is just as crappy.

Look it up on Google, there are lots of websites discussing this.

Forget about Fortran

[m50d]

What I want to know is, when are they going to support the latest version of C? The standard's been out what, 5 or 6 years? It's the primary language of the compiler. And yet I still can't pass complex numbers to functions and expect it to work. Please, someone get C99 support working.

Re:Forget about Fortran

[Anonymous Coward]

C99 status page.

But there's only finite resource, of course. You want some obscure feature fixed, why don't you fix it?

Re:Forget about Fortran

[m50d]

It was down as "library issue" last time I looked and I couldn't find anything about how to fix in the library. But it's now merely "broken" so I'll take another look when I've got the video playback I'm working on working.

Dumb question

[m50d]

Would LLVM let me write a BF backend for GCC? That would be so leet.

C++ is just as unsafe as C

[billstewart]

I've been using C longer than you have (1978:-), though you've probably been using C++ longer than I have, and you've definitely been doing real programming more recently.

Writing safe code in C is easy - you just have to sit down and do it, and not get lazy. C++ has some more convenient tools for writing safe code, but C is really just fine. The real problem is that both of them let you write unsafe code, so a random chunk of C++ from some careless slacker is just as dangerous as a random chunk of C code. C++ was useful precisely because it retained relatively good backwards compatibility with C, which means you can still shoot yourself in the foot with the same precision, simplicity, and beauty that you always could, as well as introducing newer and more baroque ways to do it.

Some of my friends rave about Python, or about Objective-C; I haven't tried them enough to comment usefully. There are still a few problems which benefit from down-to-the-virtual-metal programming - device drivers and occasional numerical hackery - but most of the real performance problems aren't language overhead, they're environmental baggage or memory bloat or overuse of ill-matched packages. The obsolete laptop I'm typing on right now has a CPU 1500 times faster than the ones I learned to program C on, with about 1000 times as much RAM. The machines I learned to do graphics on mostly had about 10 MIPS and 8 MB of RAM. Some of the bloating is an economic tradeoff - programmers are still expensive, while hardware just isn't (the desktop sitting next to me costs 1/1000 of what my first VAX cost, with 2500 times the CPU and 150 times the RAM - I'm using it to download music.) Wasting a bit of CPU horsepower to check boundaries decently is definitely cheaper than wasting user time debugging or cleaning up viruses.

Re:C++ is just as unsafe as C

[Anonymous Coward]

Writing safe code in C is easy - you just have to sit down and do it, and not get lazy.

Getting rich is easy - you just have to go out there and make lots of money.

Mommy, why are there so many poor people in Africa?

Kernel vs. Userland compatibility problems

[billstewart]

I'm really tired of seeing Linux releases coming out saying "You have to build the kernel with GCC version x.y.z and Gnome/KDE with version x.w.q and be sure to only build GlibC using GCC version x.f.m." Scary-looking stuff - how much code do people write that should be significantly different for different compiler versions?

Re:Kernel vs. Userland compatibility problems

[ArsonSmith]

I don't think I've seen any of those versions. Don't they use numbers???

CMOV bug fixed?

[cpghost]

A very annoying bug for us VIA C3 users was that GCC uses the CMOV instruction with i686, even though CMOV is an optional instruction according to Intel specs. This prevented software compiled for i686 to run on VIA C3 processors.

Does anyone know if this GCC bug is fixed in the development version or in the upcoming 4.0?

Re:CMOV bug fixed?

[Anonymous Coward]

PR8234. Looks like it's been closed as not-a-bug.

Why would you care for shorter -compile- times?

[Vo0k]

I'd much rather see a compiler that is half as fast but generates twice as fast code. I really can wait another 4 hours to have the desktop manager compiled and then have it running fast, smoothly, making the experience pleasant, than to have crap compiled now.

Re:Why would you care for shorter -compile- times?

[pchan-]

I'm a software engineer, I use gcc every day, and I sometimes compile code 200 times in one day. So, while you can afford to wait 4 hours for your desktop manager to compile, I can't afford to wait two minutes for a build to complete two hundred times per day.

What the article haven't said about DSO

[dugenou]

Long awaited significant improvement on symbols visibility. Saves RAM, saves disk, and as a consequence, allows to save link and load time. -- "La simplicité fait l'élégance"

And not only the embedded world

[cbreaker]

GCC is the staple of the entire OSS/GNU/Linux world. While it's possible to run alternate compilers on Linux and some people do, the majority of OSS is compiled on GCC for the same reason the majority of OSS is written on Linux - it's free, it's available, and it works well.

It doesn't much matter if the Intel compiler can out perform GCC on x86 because people will continue to use GCC.

I can only see GCC getting better and better over time.

Re:What we need is configure & make optimizati

[Anonymous Coward]

It says that UNIX and C are flexible enough to support multiple hardware platforms? Yeah, what a bummer that is!

I have appreciated your comments

[Futurepower(R)]

idlake, I want you to know how much I have appreciated your comments in this thread. MOD PARENT idlake UP, EVERYWHERE.

You got that the wrong way round.

[Anonymous Coward]

It's "they that can give up runtime safety to obtain a little boost in performance..."

Isn'

[Futurepower(R)]

You said, "... it introduces lots of extra management hassles for larger projects--you have to be constantly alert that developers don't start using unsafe or dangerous constructs."

idlake, you seem to know far more about this than I. Isn't what you said indicative of a social problem? Are programmer employees so uncooperative that they cannot be trained?

Isn't this partly a social problem?

[Futurepower(R)]

I hit a key accidentally, and Firefox clicked the Submit button for me. Here's what I intended to say: You said, "... it introduces lots of extra management hassles for larger projects--you have to be constantly alert that developers don't start using unsafe or dangerous constructs."

idlake, you seem to know far more about this than I. Isn't what you said indicative of a social problem? Are programmer employees so uncooperative that they cannot be trained?

It seems to me that a lot of the problems with C++ could be solved simply by not using all the features.

There is a similar problem with human languages. If someone insisted on using a selection from most of the 550,000 English words, he or she would make himself incomprehensible.

Where does CNET train its journalists?

[Ed Avis]

Amazing how a site like CNET can take an interesting story and mangle it to look like a regurgitated press release. Their authors must spend years honing this particular stilted style.

Remove the space/%20 from the URL

[Ripat]

Slashdot inserted a space in the URL. Don't miss to remove it...

yes on a file but Not on a pipe in g77

[Anonymous Coward]

Try your code on a pipe, not a file, and compile it in g77.

for example

mkfifo mypipe

write to the pipe:

perl -we 'open FH, "mypipe"; @s =`ls`; print FH @s;close FH'

in another terminal, run your program and the perl script that feeds text to the pipe, and try reading mypipe to the end. It will hang because g77 opens the pipe read-write and thus the pipe senses that there is an alternate writing device to the pipe and thus no EOF gets generated when the perl script closes the pipe.

Re:yes on a file but Not on a pipe in g77

[Anonymous Coward]

oops, dang slashdot filters! there should be the greater-than sign in front of mypipe in the perl file open:

perl -we 'open FH, ">mypipe"; @s =`ls`; print FH @s;close FH'

Off topic, I guess but...

[Anonymous Coward]

Why does that GNU mascot look like he's sucking his thumb?

Is it just me?????????

g95 to be bundled with duke nukem's next release?

[Anonymous Coward]

you write code conformant to the Fortran 95 standard. Then, any compiler can compile it, including g95.

I think the point is that g95 in fact does not implement the standard. meaning people have to use a reduced feature set if they want to distribute their code, just like Microsoft did with java. as for excuse of g95 being in beta, well 1995 is a bit of a long time ago, and its been years since the g95 project started. its starting to rival dukeNukem's next release date.

Re:g95 to be bundled with duke nukem's next releas

[Aardpig]

as for excuse of g95 being in beta, well 1995 is a bit of a long time ago, and its been years since the g95 project started. its starting to rival dukeNukem's next release date.

What an absurd remark. What is to stop people from using a commercial compiler? And looking at the g95 web page, I see that the project started in 2000. When you remember that it has been an essentially one-man effort, five years for a compiler sounds pretty good to me. Why are you fixated on 1995? The Fortran 95 standard wasn't released until 1997. Do you know anything about what you are talking about?

Screw Fortran

[Cro Magnon]

When will GCC include support for COBOL?

Point by point rebuttal

[Merk]

Thanks, but you kinda missed the point. At least you were a bit closer than the other people who replied.

I know you can have make be silent. I know you can log its output. I know you can split its stdout from its stderr. I know all that. There's a reason I mentioned a GUI.

• --silent doesn't cut it. If there's an error, then I don't have the context of that error. What I need is some way to have it be quiet when things are going well, but verbose when they fail. I don't just need the stderr when they fail either. I need to know things like "Entering directory foo"
• I know all the info is available, but if the error occurs on directory 543 of a 858 directory process, I don't want to have to sift through the first 543 lines of output to find the context. That's why said I wanted it silent by default, but verbose when there's an error.
• When showing the commandline, the problem isn't knowing what to see, it's trying to understand and parse all that data. If things were nice and GUI, I could imagine that it would be able to tell me it ran gcc, with include paths X, Y, Z, with commandline defines M, N, O, with language options P, Q, R, with machine options S, T, U.
• As for which tool's responsibility it is to colorize the output -- um, the GUI tool I'm imagining. :)

Most of this sort of thing is already done, at least to some extent, in GUI IDEs like kdevelop. The thing is, sometimes you don't want, or can't easily use a full IDE. For instance, when compiling a kernel, the makefiles and procedures are already in place for you. You don't want to create a new project, you just want to build the kernel. On the other hand, if something blows up while you're compiling the kernel, you want to know, and you don't want information overload.

I don't think you can do what I want with existing make / GCC options. I really think to do it right you'd need a wrapper. You could pipe the output of make/gcc to the wrapper, and then it could format the output all pretty-like.

Silly

[Christopheles]

That's what Emacs is for!

The Ada frontend is written in Ada..

[krischik]

... so the use of other language inside gcc is not forbidden as such.

Martin.

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.

Re:No, here it is.

[Anonymous Coward]

Thanks for great explanation. Results of fanatism are always ugly :-(

Re:No, here it is.

[Anonymous Coward]

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

What's to stop someone who writes proprietary tools that do nifty things with the IR from releasing their own GPL'd GCC patch that writes out the IR so people can use their proprietary app? Sure, people would have to patch their copy of gcc to use it (or install a pre-patched version), but they could just release RPM's for the latest RHEL and that would be enough for most people (vendors of proprietary software) who would likely use such a tool. It seems like this policy is only making it slightly harder to do that.

Re:No, here it is.

[cimetmc]

What's to stop someone who writes proprietary tools that do nifty things with the IR from releasing their own GPL'd GCC patch that writes out the IR so people can use their proprietary app? Sure, people would have to patch their copy of gcc to use it (or install a pre-patched version), but they could just release RPM's for the latest RHEL and that would be enough for most people (vendors of proprietary software) who would likely use such a tool. It seems like this policy is only making it slightly harder to do that.

Nothing stops people from doing this, and actually it has already be done. For instance, Sun has produced a C backend for GCC so that you can compile any language or dialect support by GCC to a minimum C program which is then fed to Sun's own C compiler and is supposed to produce better code than GCC itself.
However this kind of code takes a lot of work to keep it up to date. For each new version of GCC, a new patch needs to be created. Generally, these projects are therefore "one shot" projects where the code is written once for one version of GCC, and then it remains at that version forever (or at least for a very long time).
With an official internal API or a stable and documented IR, people could write code that would be comptible with multiple versions of GCC without have to make significant changes for each new version of GCC. As such, the overall burden for keeping up non GPL programs that interface with GCC would be much lower.

Marcel

Fine.

[devphil]

I've explained it in a sibling post just now. I was hoping to encourage people to go look up the discussions themselves, but if it's easier to accuse me of slander, so be it.

MOD PARENT UP

[Anonymous Coward]

+3 Informative

Re:g95 to be bundled with duke nukem's next releas

[richmaine]

Exactly what features of the standard is it that you claim g95 doesn't implement? As editor of the f95 and f2003 standards, I have some interest in the question. I don't claim to have done exhaustive testing, but it looks like a pretty complete implementation to me as far as I have seen. Not 100% bug free, but then neither is anything; I'd say it has advanced into the state of being usable. It runs my f95 code, which heavily uses features new to f90.

Are you confusing g95 with gfortran? Though they forked from the same base, their current status is quite different (gfortran doesn't yet run my codes). Or are you talking about an old version of g95? I'd say that it made some pretty major leaps just a few months ago.

If you really mean the current version of g95, I would seriously like to know specifics of what these allegedly missing features are. I'm not just flaming. It would be useful information that I would actually like to know.

ahem, cross compiler?

[slew]

yes, not everyone configures gcc is for use in native compile mode...

Re:ahem, cross compiler?

[r00t]

Native or not, the sizeof operator must work.

Getting GNU configure to run with cross-compiling
is a whole different matter. It's horrible.

Use sizeof. Don't rely on a giant buggy shell
script. You wouldn't jump off a bridge just because
lots of other developers did so, would you?

Re:ahem, cross compiler?

[slew]

> Native or no, the sizeof operator must work.

Sure it might work for the internals, but how do you describe to your compiler what to return for the cross compiling value or what number to use for computing the size and offset of aggregates? I think a preprocessing macro is a reasonable thing to do for that situation (although one might reasonably argue for using some run-time scheme, there would be some inefficiencies that might make that a poor choice because c and c++ are such poor languages for doing so)...

> You wouldn't jump off a bridge just because
> lots of other developers did so, would you?

I use c "just because lots of other developers did so"... I'm pretty sure I wouldn't make the same choice if there were no HLL and I wanted to design one (of course I might call my language "A") ;^P

BTW, most in C/C++ code *I* write, I usually use sizeof, but let's just say, IMO in a bigger project, it's sometimes prudent to just do what "lots of other developers did" before you and leave it at that...

Re:ahem, cross compiler?

[r00t]

For offset of aggregates, use the offsetof macro. It's part of , and easy to code anyway. Here's the glibc one:

#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

For size of aggregates, do likewise, with sizeof.

Re:ahem, cross compiler?

[slew]

ahme, cross compiler? again

My continuing point (that you seem to be consistently ignoring) is that for say a 16 bit target machine cross compiled on a 32 bit arch, both sizeof and offsetof will return the WRONG value. No amount of "magic" is gonna make that work...

However having said that, I often use OFFSETOF in my one-off code, but when you are writing a cross compiler, or code that must work on multiple machines it's sometimes not a good idea to use offsetof or sizeof.

For example, if you (and I find this to be a bad, but common practice), use a structure to define a binary file header in your code (e.g., bitmap file, or targa file), and you read the letter of the STANDARD, there's no guarantee of the layout of the structure (other than the pointer to the first member is at the same address as the pointer to the structure or other aggregate). Thus any code that does something totally non-portable like...

retcode=fread(&mystruct,1,sizeof(mystruct),fp);

is of course fataly flawed and non-portable (simple compiler switches or pragmas that control structure packing can often cause this to fail on the same architecture and same compiler), not to mention across compiler versions or platforms. In an ideal world, all file header structures would be XML-ish, but of course we don't live in that ideal world, and there are lots of legacy binary formats (and don't get me started on big/little endian)...

As with all guidelines for good programming, there are always exceptions to a rule and using sizeof and offsetof are no (uhm) exception...

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

Re:g95 to be bundled with duke nukem's next releas

[Anonymous Coward]

I think a lot of the rants here are historical ones. The issue for many developer was that g95 was not feature complete till sometime in late 2004. Basic things like say data structures were missing for years. The absence of a free or cheap f95 compiler meant anyone who wanted to ship source code cold only do so if the client was willing to buy a pro-compiler. People left the f95 party. Hopefully the same thing wont happen with f03.

Holy Crap!

[Anonymous Coward]

Did you just call OCaml "mainstream"?

I think some sort of major development in OCaml history just occurred here.

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.

MOD ABUSE

[Look KG486]

How is this offtopic? It isn't GCC per se, but it's withing the realm of shortening compile times. Certainly germane to the discussion.

WTF is the matter with the mods?

Re:g95 to be bundled with duke nukem's next releas

[cimetmc]

Still, the rant is wrong in the sense that it blames an early development version to be not yet complete.
The rant would be valid if it said that the *absense* of (a released) G95 was bad for Fortran, but I can't see much truth in a rant which claims that G95 hurt Fortran because it was feature incomplete.

Marcel

Re:g95 to be bundled with duke nukem's next releas

[Anonymous Coward]

Would the world have been better off if MS had not messed with Javascript and Java, shipping broken versions that became the default? I suspect it would have been better not to have a weak g95 than to have had none at all till it was feature complete.

Re:g95 to be bundled with duke nukem's next releas

[cimetmc]

I think your are missing one important point: Neither Gfortran nor G95 are released products. Both projects provide snapshot to give people a preview on what to expect and to help testing for bugs or missing features. However neither Gfortran nor G95 are suited to run important production code, and this was certainly even less the case a couple of months ago, when G95 was still based on an old version of the tree-saa backend.
I think it would have been highly naive for someone to develop fotran programs specifically for those early, unstable and incomplete versions of G95 and Gfortran.
I think both G95 and Gfortran projects are doing exactly what you are asking for. The wait with the official release until they are good enough from the completeness and stability point of view.
Your analogy with MS and Java is completely wrong as MS actually *shipped* their Java version with IE. This is *not* the case with G95 and Gfortran.

Marcel

get a C compiler

[r00t]

The sizeof operator must work according to the target. Anything else is a violation of the C standard. Although it doesn't matter in this case, also be sure to use the correct C preprocessor and header files.

When you cross-compile, building on a 32-bit arch and targetting a 16-bit arch, sizeof(int) will return 2. (or 1, if your compiler uses a 16-bit char) You will not get a 4 unless your compiler is emulating a 32-bit int for the 16-bit machine.

As far as binary struct layout goes, yeah, that is undefined. In general though, there is no problem if you use <inttypes.h> (for int32_t and such) and you naturally align all data elements with explicit padding. The real world uses only two types of endianness, which you'll also need to deal with.