It’s not even released yet, but John Marino and Sascha Wildner have been laying the foundation for using gcc 4.6 in DragonFly. gcc 4.6 looks to have some new things in it; more Objective-C support and Go, too, based on my quick perusal of the gcc website.
15 Replies to “What’s coming: gcc 4.6”
Comments are closed.
I feel more effort should be spent on clang instead of GCC. Since GPL3, projects are moving away from GCC. I don’t think GCC 4.6 will ever compile majority of apps in pkgsrc and sticking to the last GPL2 licensed GCC version is unreasonable in long term.
I would be surprised if clang has a better success rate than gcc in compiling pkgsrc packages right now. Or at least, I’d make sure of that before redirecting efforts.
I agree with the notion of going towards Clang, the rate of progress as well as innovation on the LLVM/Clang front blows GCC out the water. Both Apple and FreeBSD has been putting some wight behind Clang for some time now for both application and kernel support, Clang is both self hosting and now has feature complete C++/C/ObjC support. Clang has excellent Objective-C support. Its license is inline with the BSD’s ideology being of course BSD and this is a compiler framework that has been wanted for a long time now, here it is, lets support it! I am a little surprised by this GCC push considering the main valid argument before was that Clang was not previously self hosting which was a fair assertion to make _at that time_. I would like to note however that Marino has done some excellent work on Ada support and this is not a normal GCC spin as it contains his custom patches. Justin, I invite you to try the latest Clang before making that assertion, cheers.
I don’t know what these comments are about, really.
If anyone is interested in actually *using* clang on DragonFly rather than just talk about importing it, making it default or not, they will find that you can do that for a long time. Install it from SVN, set CCVER to ‘clangsvn’ and your cc and friends are clang.
In fact, clang/llvm has had support for DragonFly for longer than support for FreeBSD. Just check their logs.
As Sascha has said we have had excellent support for DragonFly in clang and vice versa for some time now.
All this mumble jumble about clang is a waste of time. If someone wants clang in base for one reason or another just submit a patch.
Sure, that is known however it would be nice to have it at least imported and standardised as a shadow compiler. I am willing to be responsible for maintaining it, handling updates and committing fixes back upstream into LLVM/Clang as I have done in the past.
If its a matter of just someone taking on the role I am up for it!
The printf issue has been brought to my attention and I’m looking into it, should not be big deal to fix.
I’d rather not have more than 2 compilers in base and at the moment these slots are taken by GCC 4.1 and 4.4. We’ll move to GCC 4.4 as default shortly and GCC 4.1 will linger around as a backup for some time. Once we get rid of GCC 4.1, clang might be an option to import.
But as I said before, I really don’t get what’s so important about having it in base.
Apart from the points made above, some other technical reason why would be that two totally different compilers to shadow compile is a better idea than two generations of the same compiler on the notion of picking up more possible bugs at compile time. Clang also has excellent diagnostic messages as I am sure your aware of that help both developers and lesser technical users to diagnose buildworld and buildkernel errors. I fully agree with not dropping GCC however, at the same time a choice of compiler not from one vendor/community alone is a very good idea, particularly with all the technical merit Clang with its diagnostics and static analysis faculties comparative to GCC as well as LLVM’s optimiser innovations and aside from the technical stand point, it being fully inline with half of what some may argue is what BSD is all about, the BSD license.
Should I perhaps write a proposal to the mailing list in detail with my case, how is such a notion normally put forward? btw, I do agree with no more than two compilers at any one time, that seems fairly logical and understandable to me. So a more careful consideration of Clang’s introduction into base could be considered in the time frame between. I have commit bit so I would be happy to negotiate fixes between projects to make such a introduction viable. I’m not sure if you remember as it was quite some time ago, however I did fix a number of clang issues such as hangs and things upstream.. this may of been forgotten however my enthusiasm for Clang has not dimmed.
Thanks for your time lads.
Clang in base would be good to see!
Edward – if you want to put effort in on clang, documenting the advantages of moving to it would be good. I know you listed several things in the comments, but “excellent diagnostic messages” is not quantifiable. Past that, I’ve got nothing. Some questions to answer:
– Does more or less of pkgsrc compile using it?
– Does a DragonFly system run faster/better using it?
Pushing a ‘known good’ version of gcc out of base to make room for it needs to be justified; replacing a version of gcc with clang and then finding out that it doesn’t work, or introduces some variety of problems isn’t a good idea. Not when it’s possible to use clang right now without removing gcc to be able to say whether it will work or not.
Putting it another way: pushing it into base is something you do when it’s known to work and be settled. We’re not at that point yet.
I’ve not tried with gcc 4.6, but with gcc 4.4 vs. clang (from svn, rev 109538), I tried a number of small-to-medium-sized routines and found them to be anywhere between ~5% slower to ~50% slower than gcc 4.4-compiled routines on a 2.66GHz Core 2 Duo. Granted those were only small routines (bit searching, cross-correlation, DFT, the LWKT token FIFO code, )…
I also just tried the LWKT token FIFO code (this time used w/ a spinlock) with clang 2.9 (118248) and gcc 4.4.4 on an 8-core nehalem. Just kick off 8 threads and see how many lock/unlock pairs are possible in 8 sec; the clang binary at -O2 turns in 1.9% more lock/unlock pairs than gcc -O2; at any other setting, the performances were very close. So your mileage may vary :D
My main concern with importing gcc 4.6 would be that 4.6 has not been released yet… we don’t want to produce a gcc 2.96 situation…
Yes, I’ll document it and send a proposal to the mailing list, of course some work will be needed before it can go directly into base, of course it can’t just happen overnight however I strongly believe there are many technical and rational reasons behind such a endeavour. The above was simply to highlight some points without substantiating them to the fullest of extents such as the diagnostic messages, clearly..
In regard to pkgsrc, this is one thing that I do need a more powerful machine or access to one to test with.. pkgsrc is also as you maybe aware a hard thing to get a completely fair metric on become there are spasmodic breakages happening all the time although certainly a rough estimate could be derived from doing a side by side using the same pkgsrc snapshot in around the same time period or using a cache of all the required source tarballs to make sure some package did not build simply because it could not be fetched leading to more skew’ing of the results.
In regards to if DragonflyBSD runs ‘faster’ or ‘better’ is also a hard thing to put a metric on, certainly LLVM has a number of advantages over GCC optimizer in certain areas where other areas could be need of work, thus this is more a workload dependant question or of the form of a particular requirement on a particular things. Certainly there has been a number of benchmarks between varying GCC and Clang/LLVM versions that have showed advantages and disadvantages in both, some very large by use of LLVM making use of GPU’s and CPU intrinsics in clever ways for some cryptographic jazz and other such things like software graphics accelerate pipelining via LLVM. GCC is older and by this nature has more mature code..
However, I believe there are many real advantages of Clang on the developer standpoint, another advantage to add to some of the above is that Clang has been proven under a number, admittedly one of there own benchmarks, to parse source and header files quicker than GCC can by up to 40% of memory serves correctly, clearly these numbers change all the time.
http://clang.llvm.org/performance.html
Certainly, and I am sure many will agree with me, that Clang/LLVM rate of development and attitude to getting bugs fixed promptly is another plus over GCC and the bureaucracy of the FSF as well as what others have indicated above about GCC being under the GPL3 that some people consider to be problematic however I digress from this.
Since the FreeBSD team, which have been working very hard consistently for quite some time now to make sure many ports build with Clang and patches have been going upstream both for the various ports and Clang its self. They, in effect have given good level of groundwork to lead the other BSD’s to follow suit.
I do however have to say the ‘it works don’t upgrade anything’ is fundamentally flawed, of course there will be problems, a printf warning has already been lighted to me for which I am looking into and I am sure there are a number of others so it will take some time however I feel there seems to be some consensus to resist such a change with the mentality that “what’s so good about clang” without bothering to look just a little closer and be a little patient. Give it a go, try it out some.. :)
Cheers,
Edward.
Venkatesh Srinivas,
I am definitely interested in any test cases that show LLVM being so much slower than GCC ! That’s a bug and would *definitely* be interested in such cases being identified!
Edward.
No one talked about importing 4.6 so far. :-)
All I did was to add a way to use the 4.6 that is in pkgsrc (gnat-aux) with our CCVER mechanism.
We have the same for clang and pcc too. It doesn’t represent an argument for or against importing in any way. What we bring into base or not is a different thing altogether.