Re: Clang as default compiler November 4th

On Tue, Sep 11, 2012 at 03:21:22PM +0300, Konstantin Belousov wrote:
> On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:
> > > > 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.
> Sorry, I cannot buy the argument. How many patches there are already
> in the ports tree to cope with clang incompatibility with gcc ? You may
> declare that all of them are application bugs, but it completely misses
> the point.
> 
> > 
> > > 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.
> Can you, please, read what I wrote ? Fixing _ports_ to compile with
> clang is plain wrong. Upstream developers use gcc almost always for
> development and testing. Establishing another constant cost on the
> porting work puts burden on the ports submitters, maintainers and even
> ports users.

Upstream developers almost never use gcc4.2.1 as we do. So right now the
ports maintainer must check whats wrong in the case the (upgraded) port
doesnt compile with our in-tree gcc.


It can be trivial USE_GCC=4.something but the burden is exactly the same
as with clang.

> I do strongly oppose the attempt to drain the freebsd resources by
> forcing porters to port third-party code to other compiler.

We dont force anyone. Any port maintainer can decide to USE_GCC=4.2. We are not
advocating removing gcc but making clang default. The possibility of fallback
to gcc is still there.

> > > 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.
> 
> We do not want to hunt for the compiler bugs at all, goal of FreeBSD
> is to develop the OS and not a compiler.

By the nature of "developing the OS" we are forced to use compilers and
toolchains. Recently I saw you submitting/committing patches with .byte
sequences because our default assembler cant handle the instructions.
I saw jhb_at_ updating binutils to support invept/invvpid.

In my eyes, switching to clang by default lowers the compiler/toolchain
maintenance burden we have.

Thank you, Roman.