Clang as default compiler November 4th

[Steve Kargl]

On Tue, Sep 11, 2012 at 04:10:13PM +0200, Dimitry Andric wrote:
> On 2012-09-11 15:24, Steve Kargl wrote:
> ...
> >How fast clang builds world in comparison to gcc is irrelevant.
> 
> Not at all irrelevant: this proposal is about changing the default
> compiler for the FreeBSD system itself, not for all software out there.

If /usr/bin/cc becomes clang, then the proposal is about more
than the FreeBSD system.  This affects any port that uses cc.

> If certain software performs significantly better with gcc, and using
> newer versions of the GPL is no problem, then it is obviously the better
> choice.
>
> However, I think the majority of users can get by just fine using clang,
> right now.  Doug Barton even confirmed in this thread that 80% of our
> ports already work with it!

He stated that 80% build with clang.  I doubt that he actually
tested the functionality of some 17000 ports.

> >What is important is whether software built with clang functions
> >correctly.  See for example,
> >
> >http://math-atlas.sourceforge.net/errata.html#WhatComp
> 
> Yes, maths support, specifically precision, is admittedly still one of
> clang's (really llvm's) weaker points.  It is currently not really a
> high priority item for upstream.
>
> This is obviously something that a certain part of our userbase will
> care a lot about, while most of the time they won't care so much about
> licensing or politics.  So those people are probably better off using
> gcc for the time being.

Which gets back to Doug's original point.  Until the ports
system has worked out its infrastructure for choosing a
compiler, a switch to clang as the default compiler would
seem to be premature.

> >Has anyone run Spec CPU2006 on i386 and amd64 FreeBSD?
> 
> I am not aware of it, but is that test available publicly?  I might take
> a shot, if I can get my hands on it.

Unfortunately, it has a cost associated with it.
http://www.spec.org/order.html.
Perhaps, the FreeBSD Foundation can make it available.

-- 
Steve