Re: Clang as default compiler November 4th

On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote:
> [Please confine your replies to toolchain_at_freebsd.org to keep the thread
> on the most relevant list.]
I do not see how removing current_at_ can be done, toolchain_at_ is not
relevant for this discussion. Proposed is not a local change in the
toolchain itself, but a far reaching and IMO premature change.

> 
> For the past several years we've been working towards migrating from
> GCC to Clang/LLVM as our default compiler.  We intend to ship FreeBSD
> 10.0 with Clang as the default compiler on i386 and amd64 platforms.  To
> this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
> platforms on November 4th.
> 
> What does the mean to you?
> 
>  * When you build world after the default is changed /usr/bin/cc, cpp, and
>    c++ will be links to clang.
> 
>  * This means the initial phase of buildworld and "old style" kernel
>    compilation will use clang instead of gcc.  This is known to work.
> 
>  * It also means that ports will build with clang by default.  A major
>    of ports work, but a significant number are broken or blocked by
>    broken ports. For more information see:
>      http://wiki.freebsd.org/PortsAndClang
> 
> What issues remain?
> 
>  * The gcc->clang transition currently requires setting CC, CXX, and CPP
>    in addition to WITH_CLANG_IS_CC.  I will post a patch to toolchain_at_
>    to address this shortly.
> 
>  * Ports compiler selection infrastructure is still under development.
> 
>  * Some ports could build with clang with appropriate tweaks.
> 
> What can you do to help?
> 
>  * Switch (some of) your systems.  Early adoption can help us find bugs.
> 
>  * Fix ports to build with clang.  If you don't have a clang system, you
>    can use the CLANG/amd64 or CLANG/i386 build environments on
>    redports.org.
> 
> tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04

There was a chorus of voices talking about ports already. My POV
is that suggesting to 'fix remaining ports to work with clang' is
just a nonsense. You are proposing to fork the development of all the
programs which do not compile with clang. Often, upstream developers
do not care about clang at all since it not being default compiler in
Debian/Fedora/Whatever Linux. The project simply do not have resources
to maintain the fork of 20K programs.

Looking from less amiable angle, you propose to knowingly break significant
and important piece of the project work. My belief is that switch cannot
be done before ports switch to the port-provided compiler.

Another issue with the switch, which seems to be not only not addressed,
but even not talked about, is the performance impact of the change. I
do not remember any measurements, whatever silly they could be, of the
performance change by the compiler switch. We often have serious and
argumented push-back for kernel changes that give as low as 2-3% of
the speed hit. What are the numbers for clang change, any numbers ?

And, some small but annoying things left with clang, like ABI change
requiring 16-byte stack alignment on i386, but lets ignore this until
two big issues are resolved.