Hacker News new | comments | ask | show | jobs | submit login
FreeBSD 10 to use Clang, GCC will be deprecated (phoronix.com)
165 points by lysol on May 13, 2012 | hide | past | web | favorite | 64 comments



I have been working on getting a quite complex C++ code base (3M+ LOC) with heavy template use to compile on clang. Along the way, I have found many violations of the C++ standard that GCC silently accepts, several obscure GCC features that clang does not support, and up to now filed three clang bug reports.

The project compiles now, but the resulting executable is still not passing basic regression tests :)

I think our codebase has been depending for too long on just one compiler, and clang C++ support isn't perfect yet. (FreeBSD has mostly C code which is very stable). I will keep pushing to get it all working :)


"many violations of the C++ standard that GCC silently accepts"

Or maybe it's C++ violations that are "commonplace" and would break several existing softwares.

And herein lies the biggest hurdles with C++

Heavy templating and inheritance is the way to ensure your C++ program will be unmaintainable and not forward compatible with GCC (or other compilers)

I've been in a similar situation where I spent a lot of time fixing compiler errors (on GCC 3.X if I'm not mistaken) that would be ignored on 2.X


I'm in the same boat. A large code base relying on GCC and Boost heavily.

The code builds with Clang, but the runtime crashes deep inside Boost.

It's been very frustrating because we're well past the point where refactoring-out Boost would be cost effective.


> It's been very frustrating because we're well past the point where refactoring-out Boost would be cost effective.

I'm curious: What was the motivation for switching in the first place? And why is staying with the proven tool not the better option?

My own case: It makes no sense to migrate our (relatively small by the sound of it) codebase. It is in production, generating money, and anything that interferes with that is simply not going to be considered. Our largest dependencies are wxWidgets, ffmpeg, libcurl: It has performed well, though not without some hiccups.


iOS.

Apple won't allow us to submit apps built with Xcode 4.1 forever. (4.1 was the last to include GCC.)


headslap Right. I live in a windoze-centric place at the moment (at least for compile) and forgot the world is bigger.

Thanks for the reply.


We have been using clang on Apple, Linus, and FreeBSD. It's a lot nicer to work with and compiles faster than GCC, including 4.7. As people point out, the generated code is on average a little slower.


> Linus

Linus' ultimate plan for Linux. Replace brain with Linux. Circle complete. Spleen still uses binary blob for driver. Open-source attempt to recreate it called Splouveau.


We have been using clang on ...Linus...

clang, now with a compile-to-DNA backend.


No, I think he's saying Linus is a robot. A robot whose software is compiled with clang.

That implications are disturbing.


I haven't been following C much in recent years, though I knew that Apple had switched.

Someone want to give (or link to) a brief rundown of the advantages/disadvantages?


There is a little bit on the Clang site:

http://clang.llvm.org/comparison.html#gcc

Outside the license, the main benefit seems to be that in Clang the different stages are less intertwined than GCC. This is supposed to make developing Clang easier (since you don't have to understand so much), allowing optimizations to be tested and added easier.

On the user side, Clang is well known for providing much better error messages. Some error messages will even suggest possible fixes (you might get something like "Can't assign a pointer to a something, did you mean *pointer?").

The GCC guys have been improving their compiler for a long time, and over the last few years they have been working hard to make GCC easier to work on and optimize. I believe that GCC is usually faster or the binaries are smaller by a few percent, but it's not generally a drastic difference.


GCC speedup is actually quite substantial in math/numerical code (which, in turn, is not as fast as Intel's ICC). Moreover, GCC supports OpenMP, whereas Clang does not. This alone make building several scientific software packages not possible with Clang.

It's important to note though that it has only been recently (starting with GCC 4.4) that I've started to see some _improvement_ over previous GCC versions. GCC 3.x was known to be bloated, buggy and emit poor code for almost every architecture. Open64 was superior in _all_ regargs up to GCC 4.2/4.3 in my opinion.

Clearly, the whole project greatly benefited from Clang's competition.


Agreed. Competition is GREAT, and seeing these two excellent open source compiler offerings engaging in friendly competition means we as end users all benefit, no matter which solution we prefer (or use both, as I assume I'm not the only one doing).


Starting with gcc 4.7 and 4.8 the error message for C++ are also improved [1] and start to get close to clang. The competitions seems to be good for gcc and I like to have the choice between two compilers.

[1] : http://gcc.gnu.org/wiki/ClangDiagnosticsComparison


> On the user side, Clang is well known for providing much better error messages. Some error messages will even suggest possible fixes (you might get something like "Can't assign a pointer to a something, did you mean pointer?").*

Here [0] is an example of Xcode leveraging clang to provide valuable feedback. The second picture speaks volumes.

[0] http://www.macfanatic.net/blog/2009/08/28/xcode-3-2-static-a...


While we're on the subject of static analysis and valuable feedback, you should take a look at PVS-Studio, which is pretty neat as well, and is comparable to what clang can do (as far as I can tell from their blog posts).


From everything I've heard pvs-studio is great, but it only runs within Visual Studio. Would love to have an os x or linux version of it some day.


On error report: I wrote some programs in C that heavily reply on huge macros to mimic template in C++. The gcc error report is completely useless as it points to the line with the entire function expanded to a single line. Clang is much more clever.


Yes

I'm not sure how it works in Clang, but of course, GCC doesn't "see" macros, this is seen by the CPP (C pre processor) and GCC operates in C code only

There's a flag (-E) that makes GCC output the preprocessed code and stop


I do not know how clang achieves that, either. BTW, with gcc, I usually do something like this: "gcc -E prog.c | grep -v ^# | indent > prog-fmt.c" This is quite clumsy, though.


Pros:

Faster compile times.

Better error messages.

BSD license.(More in line with their project not a judgement on my part.)

Designed to make use in tools easier.

Cons:

Code produced isn't as fast, but not much slower.


I thought Firefox was seeing speedups from using Clang generated code? I guess I don't know the average case of course, but I'm curious to hear more about this, my Clang/LLVM-fu is weak


Well you are likely thinking of Raphael Espindola's tests of using Clang to build Firefox, and those tests showed that Clang/LLVM was better in some instances but overall GCC was faster.

HOWEVER the GCC he tested against was GCC 4.2, a ~5 year old version of GCC which is the version OSX ships with (he was using OSX) so the tests as comparative between GCC and Clang/LLVM of today were pointless.

It should also be noted that Firefox as used on people's machines today gets a large performance boost from profile-guided-optimization (remember back when people noticed that win32 Firefox under wine was faster than native Firefox on Linux? This was because of the Linux versions not being compiled with profile-guided-optimization at the time), and this optimization is not available for Clang/LLVM (though iirc there's a GSOC project for it this summer).


One area where Clang really shines is compile time - it's faster than gcc, at least a little [1].

The claims about who has faster binaries are pretty difficult to judge - it seems they really are about equal. It may be highly superscalar CPUs with instruction reordering and register aliasing hide the difference.

[1] http://gcc.gnu.org/ml/gcc/2012-02/msg00134.html (probably unbiased) and http://clang.llvm.org/performance.html (probably biased)


My code consists of tight loops used for numerical simulation. Clang runs about 2x slower. Hence I conclude that Clang is bad for optimizing tight loops.

Many of the Clang vs. GCC tests are clandestinely skewed towards llvm because they involve code that does not benefit from low level optimization.

Many of the people who work on GCC are scientists who want tight loop performance while many of the folks who work on clang want a BSD license.


It depends a lot on the use-case. For my hobby project (numerical stuff, C++) I got a speedup of more than 10% by moving to Clang. Huge stuff. I spend ~50% of my time in one hot function, though, and it's entirely possible that GCC generated better code for the rest of the project.

As usual, the only reliable way to know which compiler generates better code for your program is to run benchmarks.

For what it's worth, I wasn't blown away by the compile times or error messages when I moved to Clang. I think GCC is getting a lot better, but I'd also learned to live with its failings regardless.


For me it's mainly the error messages, either Clang/LLVM has gotten slower in compiling or GCC has gotten faster, but it's not a big 'percieved' difference for me anymore. I think the Clang error messages are more informative and also that the colored output makes it easier to read.

Performance-wise though I still generally get ~5-15% better speed on generated code with GCC (corei7).


A: Modular design. You can change everything, modify to make your own compiler and even include on a proprietary project if you want(license much more permissive than GPL)).

It lets you interpret C and C++, if you want.

It lets you compile in C, C++ to bytecode like java if you want, native code if you want too.

It can compile JIT fast things like OpenCL or javascript.

D: It is huge for a compiler. I believe gigabytes or so.


I was a bit surprised by Stallman's statement

"One of our main goals for GCC is to prevent any parts of it from being used together with non-free software. Thus, we have deliberately avoided many things that might possibly have the effect of facilitating such usage"


Clang is not gigabytes big. Even the uncompressed source code for it and LLVM (which are very big) aren't in the gigabytes.

http://llvm.org/releases/download.html#3.0


If you want a more technical review of LLVM, I think this is a very good one: http://www.aosabook.org/en/llvm.html (Chris Lattner is the creator of LLVM)


I'm excited about this change. I was working on a C++ project last summer that had a lot of templates. Clang was a lot faster, and a lot easier to use.


Would be interesting to see benchmarks with GCC vs Clang in FreeBSD


Aren't they pretty much doing anything these days to make it easier for Apple to “steal” their code, considering that most consumers of BSD code are Apple users?


As someone who tends to release on more-permissive licenses, I just want to clarify the causal model here.

It's not "doing something extra" to release with BSD; the "doing something extra" comes when you want to properly release with GNU.

After a long random walk over the licensing attitudes graph, I have found myself for the last several years stably located at one node. This node is, "licensing is about lawsuits." People often release with the GNU GPL because licensing, for them, is not about lawsuits but has some other import and use -- perhaps moral. But for me, a license is strictly about defining what sorts of lawsuits are possible.

Copyleft is a threat to sue. More precisely, it is the threat "I may sue you if you don't threaten to sue others." And that just sounds crazy. Why would you do that? Well, the stated goal of copyleft is to eliminate all fears of lawsuits by using legal threats.

Let me hasten to add that this is a very pretty idea. If you know the religions of India, this idea is called tantra -- that sometimes the most precise tool for removing a thorn is other thorns, or sometimes the best way to remove dirt from your clothes is with an abrasive substance -- like other (cleaner) dirt. The reason that Stallman is sometimes described as religious may come back to the attendant mysticism that tantric approaches usually bring with them.

My point is, this sort of thinking is an active choice and requires you to enforce the threat, at least in principle. The BSD license is much simpler: it says "I won't sue you, and you're not allowed to sue me." It is a Buddhist-nonviolence approach to eliminating lawsuits: "I have stopped causing suffering in this world, Angulimala -- now why don't you stop?"

It is nothing extra to release this way: you simply promise to not sue anyone, and you only give permission conditional on the fact that they will not sue you, you write it once and then it is done. It's clean and elegant. If you want to actually be a productive GPL licenser, you have to either hope that the threat in the docs is enough, or else find everybody who is "conveying" your software, and slap them with a lawsuit so that they learn how much lawsuits suck.


Hmmm... no I have to disagree with the picture you paint here. A licence is not a 'threat to sue', it's a set of conditions for use. Theoretically you could be sued for removing the copyright notice and author attribution from BSD licenced code just as you could be sued for not making the source code available when you distribute GPL licenced code.

Furthermore when you talk about 'promising not to sue', as we see today the highest risk of being sued for software is through software patents. GPL says that if you distribute your patented code under GPL you are not allowed to turn around and sue people using that code or any derivates of it. The BSD licence makes no such provisions and as such you could release patented code under BSD and the proceed to sue people using it.


I love your comparison gpl and bsd licenses to different religions/philsophical ways of dealing with violence.

However, the game theoretic consequences of absolute non-violence (as in Jainism) are negative, unless non-violence is adhered to by everyone in the neighborhood. Or, I suppose you could say instead that non-violence is not a principle to be taken alone. In order to be effective and safe, you have to divest yourself of anything worth stealing, avoid creating interpersonal problems, and stay out of environments where you might be caught up in unrelated violence.

Since copyright has no meaning in isolated or pure environments like that, the analogy breaks down. Copyright is fundamentally a social and legal construct, not a philosophical one.

It's not quite accurate to draw the comparison with a 2-clause BSD license though. Relinquishing copyright and placing code into the public domain would be more pure. Authors licensing code under a 2-clause BSD license are threatening to sue if proper attribution is not kept. 3 and 4 clauses licenses add more promises to sue under some conditions.


An upvote wasn't quite enough here:

This is a lovely way of explaining the difference, and it'll be what I link people to in future when explaining why I opt for BSD-style licensing. Thank you.


As lovely as the explanation may be, it focuses on a single issue. The whole point of the GPL is granting and protecting end-user rights - protecting the developer from lawsuits is a secondary concern.


What end-user rights does the GPL grant or protect that the BSD license doesn't?

The right to do whatever the hell they want with the code is granted by the BSD license. I wouldn't say the same for the GPL.


The end-user is not the developer who re-uses GPL'd code, but the guy who uses the final program.

By licensing code under the GPL, you grant the end-user the right to use and modify any program using your code as he sees fit (as long as he adheres to the rules of the GPL on re-distribution), and no intermediate developer can legally take that right away.

Of course this restricts the freedom of indermediate developers, but the GPL is intentionally -Ouser, not -Odeveloper. It just so happens that some users are also developers.


> What end-user rights does the GPL grant or protect that the BSD license doesn't?

The right to receive a copy of the implementation of the program they are using and re-distribute it freely.

I say "right" here, because in the case of BSD source on the internet it could be more accurately coined an "election" to distribute the source. As you say, "whatever the hell you want." Which is fine. So is requiring copies to carry a complete copy, including the human-readable form, and the rights to redistribute those, ala GPL.


The right to do whatever the hell they want with the code is granted by the BSD license.

That would be public domain, not BSD, by the way.


I think viewing licenses as just about lawsuits is a reductionist take on the issue.

A license can provide a strong indication of your wishes even if you don't ever intend to sue. I don't think it "requires you to enforce the threat" to be effective as a signal to others, particularly companies.

Now, you could say putting a note that isn't part of the license would have the same effect, but I find that hard to believe.


A strange way of looking at it. But it makes a lot of sense.


I guess I'm just not living in such a companies-are-people and everyone-sues-over-shit country.


If by steal you mean hiring the best contributors to the project(like Cris Lattner), and releasing a big part of that work freely, then yes, they are letting Apple steal them blatantly.


Apple isn't stealing if BSD is explicitly giving it to them for free.

FreeBSD apparently have no issues with donating their work to corporations.


That is precisely the point of the BSD license: Give freely to everyone.


"I said people could use my stuff, and then they used it! Thieves!"

Wait, what?


For one, they too benefit from Apple's work on Clang (and other projects).

Seconds, there is no "stealing". They provide a license that explicitly allows such a use.


WAT.


Wheres the "WHAT?!". The BSD guys have gone on record multiple times saying that they think that RMS and GNU are a joke. It seems natural that they would try and phase out GNU when possible in light of this belief.

An example: http://openbsd.org/lyrics.html#43

You can even download an MP3 or Ogg of it being sung (With backing.) by Nikkos Diochnos.


Hm. That example is entertaining and creative, but not really consistent with the actual viewpoints of the FSF[0].

Choice statement:

    > Distributing free software is an opportunity to raise funds for development.
    > Don't waste it!
Redhat is a good example of a company doing well distributing free software and making money doing it; it's just that the typical shrink-wrap license business model doesn't fare so well when copying and modifying the distributed program is allowed and protected.

Also, I don't mean to implicate that you share beliefs with the OpenBSD people, since you are merely reporting on their position -- accurately, in my mind. But I thought this is an interesting bit of related information for the discussion.

[0]: http://www.gnu.org/philosophy/selling.html


You must mean the OpenBSD guys.

FreeBSD is pretty much neutral on the GPL, but BSD licensed software is sort of their "thing", so it's natural they'd prefer a BSD licensed compiler.

NetBSD used to be pretty hostile until control was wrested from wasabi systems which disliked the GPL because it prevented them from closing down GPL software.

Dragonfly never really took a position, so it's safe to assume they're neutral too.

That leaves only the OpenBSD guys, of whom (some of) the vocal part thinks anything not OpenBSD is a joke.

I think that's a bit more of a qualifier than "The BSD guys", most of which don't particularly care about phasing out GNU (even though that happens when accumulating BSD licensed software in their OS), some of which are sympathetic but simply like BSD systems more, and what seems to be a fringe minority which is actually hostile for one reason or another.


It makes perfect sense if you distill it to just a licensing issue. No wat needed.


That's a pretty scathing critique.


..and a big lie.

>Richard felt that this "ports tree" of ours made OpenBSD non-free. He came to our mailing lists and lectured to us specifically, yet he said nothing to the many other vendors who do the same; many of them donate to the FSF and perhaps that has something to do with it.

See here for example: http://www.gnu.org/distros/common-distros.html

Stallman and the FSF apply the same standard everywhere. He rejects Red Hat (a major GNU sponsor) as "non-free" just like OpenBSD, in contrast to what the BSD guys claim.

>Richard has personally made sure that all the official GNU software -- including Emacs -- compiles and runs on Windows.

What?! Most official GNU software does NOT run on Windows.


">Richard felt that this "ports tree" of ours made OpenBSD non-free. He came to our mailing lists and lectured to us specifically"

to complement this story a little. rms had heard from one source or another that OpenBSD was "completely free" too (probably based on their hard and much appreciated work on wifi drivers and blobs), and looked into the matter to see if it could be included in the list of FSF endorsed operating systems (which thus far have only GNU/Linux systems). He found references to non-free software in the ports tree and wrote to the openbsd mailing list to ask for clarifications. There were actually a few saner voices who politely stated that was the intent and that OpenBSD as a project had a different definition of "free" and as such should not be included in the officially endorsed FSF-list.

Of course, for the less stable elements, it was a good pretext to scoff and insult the the man. Some even riled on and created a song about it. OpenBSD is a fine operating system, but for a normal person the culture around it can be quiteoffputting.


Thanks for the clarification nothing like a out of context FUD!


For bonus points, in the actual recording they note that Hypocrites "Smells like thousand year old goat cheese.". which no doubt refers to Stallmans's legendary hygienic practices. [0]

Needless to say, the BSD guys aren't really fans.

[0]: http://www.youtube.com/watch?v=I25UeVXrEHQ


Yea, most BSD guys I know are also fans of Apple; iOS and Macs on desktop rather than GNU or Linux and Clang is supported by Apple for license reasons.


I am surprised you didn't bring up monkey gate & security taking a backseat.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: