“I’ve made clang the default on x86 systems. There will probably be a few bumps as we work out the last kinks including a ABI issue for i386 system libraries, but the transition is expected to be fairly smooth for most users.”
“I’ve made clang the default on x86 systems. There will probably be a few bumps as we work out the last kinks including a ABI issue for i386 system libraries, but the transition is expected to be fairly smooth for most users.”
They finally did it. Great news.
This is the result of a lot of hard work from a lot of people. Awesome news!
I’m not a compiler expert, I’m only a GCC and FreeBSD user, so from a practical point of view… why do you consider Clang so awesome?
To me It always smelled like a political decision and not a technical one… Apple wanted a BSD-licensed compiler and not a GPL one so they spent zillons of dollars creating a new one and alienating the open source community.
But maybe I’m wrong and there are technical reasons to have Clang and dismiss good old GCC…
clang is really very good compiler, though I think you’re right – its a licensing issue, at the moment I wouldn’t say clang is a better compiler.
For C, they both do well, for C++, clang is still not 100%.
And on both C/C++ clang misses OpenMP, which may be a big deal if you’re using that a lot.
I do benchmarks once in a while and for me – (testing cycles-raytracer), clang is still slower then gcc (5-10%), and has been for over a year.
IMHO the advantage is more with is ability to integrate with IDE’s and be used as a library. – clang/python for example is pretty nice, though focused on IDE’s rather then giving you access to all info.
Are you comparing current (at the time) Clang vs. current (at the time) GCC, or the ancient version of GCC in FreeBSD’s base?
latest of both, running on arch linux though, attempting to use similar optimization flags where possible.
Edited 2012-11-08 05:12 UTC
I agree. Clang provides fantastically clear error messages, expecially when you use templates. But the lack of support for OpenMP is a severe impediment for those like me that do HPC (I am working in a large astrophysical project, and our codes run on machines with 12 cores at least and take hours/days to complete!).
By the way, this is the reason why I removed Mac OS X from my Macbook and replaced it with Ubuntu: to have a reasonably updated version of gcc instead of the very old one bundled with Lion.
I don’t know if this helps: http://root.cern.ch/drupal/content/cling
CERN does something with cling and clang and they do HPC stuff.
While nifty, looks like a different tool – openmp is a standard that works across gcc/intel/ibm/oricle/msvc… compilers.
And can be integrated with existing c/c++/fortran codebases.
I know it’s a different tool, but it’s worth investigating how CERN does its HPC work with clang/cling, if indeed they do use clang/cling for HPC.
I don’t know much in that area and it would be interesting to hear from people who do.
Thanks for the link. The site says that cling is an “interactive interpreter” for the C++ language, thus I figure it is something like “ipython” is for Python?
The concept is interesting, I’ve never heard of anything like it. But it’s not clear to me how this could be used to compile some code that uses OpenMP.
CERN surely does HPC, but I bet their parallel codes were developed using MPI, which is a completely different technique and is supported by clang. Our codes rely both on MPI and OpenMP, and changing them to remove the dependency from the latter would be a huge (and useless) pain.
Edited 2012-11-08 13:33 UTC
From what I understand, it’s more like an interactive version of a “JVM” for C++. It’s made possible due to the parser and the intermediate language and the JIT-optimizer being in completely separate modules. So you can enter C++ code and it will recompile, optimize and link behind the scenes on the fly.
Well I wouldn’t have thought you’d change your existing OpenMP code to MPI just for the sake of it. There’s no reason for any code to move to clang just for the sake of it either. You’d probably want to try it out with a small MPI project rather than make a full commitment to clang just for the sake of it.
I don’t have much experience with OS X Lion, but couldn’t you simply have installed a newer version of GCC? I’ve not used a Mac as my main work machine for a while, but it used to be possible on Snow Leopard using MacPorts with some tweaking. I certainly had GCC 4.5.x running with OpenMP 3.0 support on my Snow Leopard based machine (like you, I needed it for modelling).
Edited 2012-11-08 16:56 UTC
You’re right, and in fact I know a few people that have gone through that path. However, for me installing GCC has proven to be extremely difficult. I used MacPorts for years, but I was dissatisfied because of a number of reasons and switched to Homebrew. Although Homebrew works like a charm, it does not provide the ability to install a new GCC. So I relied on the binaries that can be downloaded from this site:
http://hpc.sourceforge.net/
They provide precompiled binaries for the latest GCC. There are however several problems with these binaries as well (for instance, only C/C++/Fortran are included, while Gnat/Ada is left out; and in order to install them you have to run “tar -C / …”, so it is tricky if you want to keep different versions on your hard disk at the same time)
Compiling GCC from source produced a number of problems on my system. Don’t know what went wrong, but I began to get a number of conflicts between the stdlibc++ provided by Apple’s GCC 4.2.1 and the version I installed every time I tried to compile something.
So I switched to Ubuntu, and now I am extremely happy. GCC 4.7 is bundled with Quantal, and using apt-get I was able to install both gfortran and gnat in a few minutes.
Outside of licensing issues, it is the fact that LLVM is designed to have better support for creating tooling extensions. LLVM is highly modularized and pluggable.
Sure, but all things equal – why would you switch if clang misses OpenMP and can’t compile some C++ apps (inkscape for example fails, and some areas need non-trivial re-working to make it compatible).
Still, hopefully being default in BSD gives some incentive for clang to become as complete as GCC.
As I understand it, BSD is written in C, so other applications that can’t be compiled with Clang can use GCC.
All things are not equal. clang is replacing the version of gcc in the base system, which is version 4.2.1 (plus a few patches). gcc 4.2.1 does not have openmp support, and it is missing knowledge about newer cpus.
From a practical standpoint, FreeBSD cannot adopt newer versions of gcc because of the GPLv3 unless FreeBSD wants to alienate the commercial vendors that base their products on FreeBSD and who contribute back to the project.
This is a line of reasoning that I just don’t understand.
The “base compiler” is used … to compile the “base OS”. The only features the “base compiler” needs to have are those that allow it to … compile the “base OS”. Thus, whether or not Clang/LLVM support OpenMP, every since C++ extension/feature, etc is moot and completely orthogonal to its uses as the “base compiler”.
If you need OpenMP support, install the latest version of GCC from the ports tree, and use that for your OpenMP-using projects.
If you need specific C++ features, install the latest version of “Compiler X” from the ports tree, and use that for your C++ projects.
And so on.
If the “base compiler” supports everything you need in your projects, great. Use it. If not, there are many, many, many different compilers in the ports tree. Pick the one that suits your needs, and carry on.
You think Apple is the only organization that doesn’t want a GPL licensed compiler? Stop & ask yourself why a (Free|Net|Open|Dragonfly|PC)-BSD based OS wouldn’t want a BSD licensed compiler. Those guys don’t just use BSD-licensed software on a whim. They believe in that model of software licensing & I highly doubt that they’d want to be at the mercy of the GPL license model –which changes on a whim, the same way that GPL code changes on a whim.
The only real reason for GPLv3 is software patents, which didn’t exist when the GPL was first conceived. You can’t really blame them for having to update it.
The only real reason for GPLv3 is software patents, which didn’t exist when the GPL was first conceived. You can’t really blame them for having to update it. [/q]
I think you’re missing my point. The OS in question is a BSD OS. The OS primarily uses the BSD license. So, obviously, they favor the BSD license over the GPL license (regardless of version). So, why wouldn’t they want a compiler that’s BSD licensed???
Other than licensing issues. GCC has become increasingly buggy with each release.
I have no concrete data, but I do know a few people who make ports for OpenBSD and I have heard some noise from their direction about how it was getting worse.
Edited 2012-11-09 14:27 UTC
I run all the software I maintain through both GCC and Clang. I find Clang has much better warning/error messages, compiles at about the same speed and produces executables which are about equal to GCC. What I really like about clang though is the consistency. I often run into situations where code will compile and run cleanly with GCC version X, but not GCC version X+1. Clang, on the other hand, has never given me problems in this manner. I also tend to get false warnings from GCC, but Clang hasn’t given me any such problems to date.
FreeBSD may have decided to move to Clang originally due to licensing issues, but I think (hope) other projects will follow because Clang really is a much more pleasant compiler with which to work.