LWN: Comments on "GCC celebrates 25 years with the 4.7.0 release"

GCC celebrates 25 years with the 4.7.0 release

PaXTeam — Sat, 07 Apr 2012 21:12:49 +0000

oh boy, next time better email me directly please, it's only by luck that i caught this in rss ;). as for the patches, i did submit them last year to the cfe-dev list, only a few things changed since. if you're in a hurry for an up-to-date version (against linux 3.3.1) then email me please (lwn doesn't reveal your email address).

one of these days i'd also like to post an update now that llvm/clang 3.1 is nearing completion, i just have to finish my default argument support patch for asm macros so that we may then be able to use integrated-as for linux.

GCC celebrates 25 years with the 4.7.0 release

nathanwm — Fri, 06 Apr 2012 18:33:40 +0000

Could you guys release the clang patches for the kernel? I plan on implementing a distro based on llvm, mclinker, toybox and various other bits with a preference for code quality.

Continuity problems

David.Duffy — Thu, 29 Mar 2012 11:34:50 +0000

FWIW, for my code with Fortran 2003 features (73000 loc stats package), the executable GFortran produces is significantly faster than from the other 5 compilers I use.

Continuity problems

nix — Mon, 26 Mar 2012 19:32:15 +0000

Yeah, but part of the problem with reload being a convoluted mess is that for many years earlier in GCC's history, when some target needed something done, half the time it was done in the md file and half the time it was done by hacking reload so that it did *just* the right thing for some shape of RTL that only that target would produce. And, of course, this was often not documented. Hello unstated assumptions and fragility.

(This is not to say that you are wrong in any way. There are other problems too, not least the 'it works on major targets' RTL, it must be complete' problem you mention...)

Continuity problems

james_ulrich — Sun, 25 Mar 2012 08:49:43 +0000

Reload has all these "assumptions" because it is such a hughe big convoluted mess. Also, it is a corner stone in the whole compilation process, so you can't just throw it out. And hence, instead of fixing reload when some bug pops out, all the passes around it are fixed just so that reload doesn't need to be touched.

While I had my share of struggling with reload, by far most of the annoying problems with RTL passes was that lot's of them completely ignore some MD feature or other -- it can not even be said that this is old cruft hanging around: even the web construction pass has issues, which is supposed to serve as an example! This is a review problem.

GCC celebrates 25 years with the 4.7.0 release

nix — Sun, 25 Mar 2012 01:07:41 +0000

I frankly doubt you'd see enormous improvements in non-pathological benchmarks anyway, because the kernel is not the predominant consumer of CPU time in most benchmarks, and LTO will do nothing to improve locality of reference or any of the heaps of algorithmic things which a kernel has to deal with and which really do take time. You'd probably see an improvement from reduction in icache pressure though, but I have no idea how big it might be. Probably minimal, but one can hope.

As always, the numbers will tell.

"Heraldry test?"

nix — Sun, 25 Mar 2012 01:03:34 +0000

Quite. It wasn't even 'depose the king, he goes into exile'; kenner is *still* contributing to GCC now and then, and was contributing to egcs even while he was also maintaining trunk GCC.

Continuity problems

nix — Sun, 25 Mar 2012 00:56:33 +0000

I'm sorry, this is nonsense. As James Ulrich points out, the convolution in GCC has nothing to do with the implementation language.

Its biggest problem -- still pervasive in the RTL side of things -- was always global, unstated assumptions, often assumptions wired into target machine description files, RTL optimization passes, and reload. Often an RTL optimization pass would assume (or would grow to assume over years, accidentally) some property of md files that was true for all existing md files but not necessarily true, and then reload would come to depend on the form of the RTL emitted by optimization files when when that property was true. Some of these properties are much nastier than CC0 and can't be grepped for -- and fixing them requires understanding a lot of targets, and *testing* them.

This is slowly being sorted out as more machinery migrates into the tree-ssa side of things, and as older and cruftier targets are slowly decommissioned. But it's a slow, slow job, and it would be every bit as slow regardless of the implementation language. (This is one reason why reload has been such a monster to dump and replace: it's where all these unstated assumptions go to roost. Break just one of them and you might find yourself with wrong code on a couple of random targets you'd never heard of, and the poor sod who finds this is going to have the devil of a time tracking it down to your change.)

Continuity problems

nix — Sun, 25 Mar 2012 00:49:05 +0000

I'd say that by about the time of the egcs fork GCC was close to impossible to hack on. Cruft piled on cruft. However, starting in the 3.x eras a determined effort was made to fix this (still underway: tree-ssa was a massive improvement, but it couldn't have been done without other cleanups), and it is now very much nicer.

Continuity problems

codestr0m — Sat, 24 Mar 2012 07:13:39 +0000

For the record - PathScale EKOPath 5 will use a clang based FE for C and C++. We may have some C++11 in the initial release, but it's more likely to come in an update.

GCC celebrates 25 years with the 4.7.0 release

PaXTeam — Fri, 23 Mar 2012 23:58:14 +0000

some of it is due to the .config difference, some of it is genuine LTO but i don't have numbers for same .config compilations now, sorry.

Continuity problems

khim — Fri, 23 Mar 2012 20:59:51 +0000

My impression is that GFortran is no worse than those 3 compilers, or any other available Fortran compiler. One popular Fortran benchmark (Polyhedron) supports that impression, see:

http://www.polyhedron.com/pb05-linux-language0html
http://www.polyhedron.com/pb05-linux-diagnose0html

Have you actually looked on the links you've provided? Just count “Yes” and “No”.

GFortran is much better then it was just a few years ago but it's still far behind other implementations. Almost as much as C++11 support is ahead of the others.

"Heraldry test?"

JoeBuck — Fri, 23 Mar 2012 20:43:26 +0000

The use of the metaphor is mistaken. Much of the code in the first egcs release that wasn't in GCC 2.7.x was already checked in to the FSF tree, and merges continued to take place back and forth. Thinking that GCC was somehow a completely new compiler with the same name after the EGCS/GCC remerger is just wrong. Furthermore it was the same people developing the compiler before and after. What really happened was that there was a management shakeup.

Continuity problems

daglwn — Fri, 23 Mar 2012 19:52:17 +0000

Fair enough WRT C++-11. I don't know where PGI or Pathscale fits in there. I'll bet they use the EDG frontend and will get support whenever it is ready from EDG.

Continuity problems

daglwn — Fri, 23 Mar 2012 19:51:09 +0000

Does gfortran support Co-Array Fortran? I think it may support a limited form (intra-node only). I'm fuzzy on the details.

Certainly gfortran is improving but I wouldn't call it up to the same level of standards support as other Fortran compilers.

Continuity problems

daglwn — Fri, 23 Mar 2012 19:49:20 +0000

PGI has targeted several systems over the years. So have more traditional vectorizing compilers like IBM's offerings.

Continuity problems

rgmoore — Fri, 23 Mar 2012 18:43:51 +0000

The claims about being first to provide an "architecture neutral" (whatever that means) vectorizer and OpenMP implementation are laughable. Other compilers have been doing that for decades.

They may have been supporting those features, but they haven't been doing it across multiple architectures the way GCC does. That's the point they're trying to make with the "architecture neutral" comment; they do it across architectures and architecture families. That's tremendously important for anyone who hopes to write software that's usable across the huge range of systems supported by something like GNU/Linux.

Continuity problems

stevenb — Fri, 23 Mar 2012 18:27:40 +0000

Do you have a something to support the "much better Fortran support" comment? I don't think that comment is justified.

My impression is that GFortran is no worse than those 3 compilers, or any other available Fortran compiler. One popular Fortran benchmark (Polyhedron) supports that impression, see:

http://www.polyhedron.com/pb05-linux-language0html
http://www.polyhedron.com/pb05-linux-diagnose0html

Note they're comparing the latest Inter Fortran compiler (v11) to a 3 year old GFortran (v4.4). GFortran in more recent GCC releases has further improved significantly. (NB, Lahey and Absoft are Open64-based, like PathScale).

Also performance wise GFortran isn't so bad, and still improving. See:

http://www.polyhedron.com/pb05-linux-f90bench_AMD0html (v4.1, poor)
http://polyhedron.com/pb05-lin64-f90bench_SBhtml (v4.4, reasonable)
http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/bench... (v4.7, great)

Continuity problems

khim — Fri, 23 Mar 2012 17:56:30 +0000

They may be faster (in some cases… it all depends on the code in question very much), but as far as “better standards support”… let's check: Intel compiler - 17 “N/A” out of 39 (vs 4 “N/A” out of 39 for GCC), the PGI compiler and Pathscale are not even mentioned.

These three compilers have much better Fortran strandards support, but this is another kettle of fish: Fortran was always quite weak in GCC because GCC is primarily C and C++ compiler.

Continuity problems

daglwn — Fri, 23 Mar 2012 16:15:38 +0000

The Intel compiler. The PGI compiler. The Pathscale compiler. That's just a few.

GCC celebrates 25 years with the 4.7.0 release

jezuch — Fri, 23 Mar 2012 16:14:11 +0000

> https://github.com/andikleen/linux-misc/commits/lto

And it has a respectable name attached to it! I'll give it a try, thanks!

GCC celebrates 25 years with the 4.7.0 release

slashdot — Fri, 23 Mar 2012 16:04:58 +0000

What's causing the massive .data size differences?

Continuity problems

jzbiciak — Fri, 23 Mar 2012 13:27:33 +0000

Allow the cynic in me to make a possibly unfounded comment:

For some of GCC's ugliness, more of the improvement may come from the "rewrite" part than the "in C++" part. The "in C++" part just encourages a more thorough refactoring and rethinking of the problem, than a superficial tweaking-for-less-ugly.

In any case, nothing will fix GNU's ugly indenting standards as long as the language has a C/C++ style syntax. ;-)

GCC celebrates 25 years with the 4.7.0 release

grobian — Fri, 23 Mar 2012 12:20:10 +0000

https://github.com/andikleen/linux-misc/commits/lto

worked fine when I've tested it last year.

GCC celebrates 25 years with the 4.7.0 release

PaXTeam — Fri, 23 Mar 2012 10:13:41 +0000

i don't know of any public instructions for LTO'ing linux, i had to work it out myself. it needs a somewhat ugly 50k patch including a gcc plugin (on top of PaX which has the gcc plugin build infrastructure).

GCC celebrates 25 years with the 4.7.0 release

PaXTeam — Fri, 23 Mar 2012 10:11:11 +0000

i didn't do any benchmarks so i can't tell. note also that the above kernels don't have the exact same config due to some yet-to-be-fixed deficiences with LTO or clang (e.g., the LTO kernel above didn't have KALLSYMS/KPROBES/FUNCTION_TRACER enabled and the clang one didn't use the PaX gcc plugins for obvious reasons).

GCC celebrates 25 years with the 4.7.0 release

bluss — Fri, 23 Mar 2012 09:08:49 +0000

Any performance improvements with LTO?

Continuity problems

Pawlerson — Fri, 23 Mar 2012 08:27:01 +0000

What compilers do you mean? I hope you didn't mean clang/llvm which isn't even as half as powerfull.

GCC celebrates 25 years with the 4.7.0 release

PaXTeam — Fri, 23 Mar 2012 08:18:00 +0000

nope ;)

$ size linux-3.3-pax*/vmlinux
   text            data     bss      dec            hex filename
13552485        9980097 3715072 27247654        19fc426 linux-3.3-pax-clang/vmlinux
13434172        7919561 3796992 25150725        17fc505 linux-3.3-pax-lto/vmlinux
14145894        9323349 3776512 27245755        19fbcbb linux-3.3-pax/vmlinux

GCC celebrates 25 years with the 4.7.0 release

jezuch — Fri, 23 Mar 2012 08:14:01 +0000

> a small fact about the LTO work done for gcc 4.7: it can now LTO linux as well

Are there any instructions on how to do this? I tried and failed several times, just not familiar enough with the Linux build system :)

> (needs a few minutes and a few GBs of memory on a quad-core SNB)

Actually, as odd as it sounds, I bought extra RAM for my computer specifically to be able to compile things with LTO... GCC 4.7 vastly reduces memory usage of LTO but no, Chromium still does not fit ;)

Continuity problems

james_ulrich — Fri, 23 Mar 2012 06:59:30 +0000

Why does everyone pass around using C++ as some magic bullet that fixes all ugliness now and forever? It doesn't and it never will. The only lesson to be learnt from LLVM is that, when *starting from scratch*, a compiler can be well written in C++. Extrapolating that to "GCC's main problem is is not being written in C++ and doing so will fix all our problems" is plain idiotic.

Even if you start coding in C++, you still need to think about how to split long functions, ridiculous if() statements and make other general ugliness clearer. Take this (random example, there are much worse ones):

if (REG_P (src) && REG_P (dest)
&& ((REGNO (src) < FIRST_PSEUDO_REGISTER
&& ! fixed_regs[REGNO (src)]
&& CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (src))))
|| (REGNO (dest) < FIRST_PSEUDO_REGISTER
&& ! fixed_regs[REGNO (dest)]
&& CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (dest))))))

How exactly will C++ make this more obvious? Ofcourse it won't.

And, no, GCC not being a library is not it its main problem either.

Continuity problems

james_ulrich — Fri, 23 Mar 2012 06:36:37 +0000

I can see that the structures and constructs used in compilers lends itself very well to the features of C++.

My point is that the reason GCC is a mess is not because it is written in C. Even with C++, 2000 line functions need to be logically split, and 20 line if() statements with 5 levels deep subexpression nesting also need to be split to make it readable. These, and other, de-facto coding style idiosyncrasies need to be fixed (or at least agreed upon not to write code like that), which is in no way affected by the C/C++ decision.

GCC also has this "property", let's say, that code is never actually re-written, only new methods added in parallel to the old ones. Classic examples are the CC_FLAGS/cc0 thing and best of all reload. Everyone knew it sucked 15 years ago, yet only now are motions made in the form of LRA to replace it (which, BTW, are in now way motivated by using C++). The same can be said for the old register allocator, combine, etc. I somehow doubt that C++ alone would magically motivate anyone to start rewriting these old, convoluted but critical pieces.

Based on past observations my prediction for GCC-in-C++ is that all the old ugly code will simply stay, the style will not really change, but now it will ugly code mixed with C++ constructs.

Continuity problems

Cyberax — Fri, 23 Mar 2012 04:06:27 +0000

Rewriting stuff in another language is actually a good way to clean up the code.

Which gcc badly needs.

Continuity problems

daglwn — Fri, 23 Mar 2012 03:59:58 +0000

> Equally, it's indisputable that GCC is one of the most popular and
> powerful compilers out there.

Popular? Maybe. Powerful? No way. There are many compilers out there that beat the pants off gcc in performance of generated code and have better standards support.

I'm not knocking the gcc guys. In terms of target support they are leaps and bounds above everyone else. But let's not kid ourselves. The claims about being first to provide an "architecture neutral" (whatever that means) vectorizer and OpenMP implementation are laughable. Other compilers have been doing that for decades.

Again, gcc is a great project but there needs to be a little dose of reality here.

"Heraldry test?"

flewellyn — Fri, 23 Mar 2012 03:40:58 +0000

Ahhhh, thank you. I knew the history of GCC, but didn't connect it to that metaphor. Thanks very much.

Continuity problems

wahern — Fri, 23 Mar 2012 03:31:01 +0000

Indeed. If you read the clang source code, instead of having 2000 line functions, you have things implemented with something approximating 2000, single line functions. Both are impenetrable. Where GCC abuses macros, clang/LLVM abuses classing and casting. (You wouldn't think that possible, but analyze the clang code for awhile and you'll see what I mean.)

Continuity problems

wahern — Fri, 23 Mar 2012 03:20:01 +0000

I've delved into both GCC and clang to write patches, albeit simple ones. GCC is definitely arcane, but both are pretty impenetrable initially. You can glance at the clang source code and fool yourself into thinking it's easy to hack, but there's no shortage of things to complain about.

Compiler writing is extremely well trodden ground. It shouldn't be surprising that it's fairly easy to go from 0-60 quickly. But it's a marathon, not a sprint. The true test of clang/LLVM is whether it can weather having successive generations of developers hack on it without turning into something that's impossible to work with. GCC has clearly managed this, despite all the moaning, and despite not being sprinkled with magic C++/OOP fairy dust. The past few years have seen tremendously complex features added, and clang/LLVM isn't keeping apace.

And as far as C++11 support, they look neck-and-neck to me:

http://clang.llvm.org/cxx_status.html
http://gcc.gnu.org/projects/cxx0x.html

GCC celebrates 25 years with the 4.7.0 release

scientes — Fri, 23 Mar 2012 02:33:14 +0000

This is for linux modules right?

"Heraldry test?"

ghane — Fri, 23 Mar 2012 02:26:52 +0000

In this case the current GCC is from the bastard (and disowned) son of the family (EGCS), who took over the coat of arms when the legitimate branch of the family died out, and was blessed by all. http://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS...

My grandfather's axe, my father changed the handle, I changed the blade, but it is still my grandfather's axe.

--
Sanjeev Gupta

Continuity problems

HelloWorld — Fri, 23 Mar 2012 02:00:06 +0000

I would have responded to your posting, but elanthis was faster at making my point.