Clang as default compiler November 4th

[Roman Divacky]

> > 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.
 
We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent
the most other ports from compiling together prevent 2222 ports from
compilation. So if we fixed those 10 ports we could be at around 2500 ports
not compiling. Thats quite far from your claim of forking 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.
 
I believe majority of the broken ports is broken because their maintainer
never saw them being broken with clang just because it's not the default
compiler. Thus by making it the default majority of the problems would just
go away.

Note that the work needed to make ports compiling with clang is largely shared
with the work to make them compiliable with newer GCCs (as they are stricter
etc.)

> 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 ?

Agreed. We should provide numbers. At least how buildworld times change
with clang compiled kernel/workd and gcc compiler kernel/world.

> 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.

Thank you for pointing this out. This is, in my opinion, one of the strongest
reasons to switch to clang. We can go, fix issues or report we find upstream
and then import newer clang. Unlike with gcc.

Thank you, Roman