Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 May 2010 11:03:07 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
Cc:        current@freebsd.org
Subject:   Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Message-ID:  <Pine.GSO.4.64.1005311051440.12132@sea.ntplx.net>
In-Reply-To: <alpine.BSF.2.00.1005311456430.91047@fledge.watson.org>
References:  <20100529130240.GA99732@freebsd.org> <20100530135859.GI83316@deviant.kiev.zoral.com.ua> <508DA8CE-749A-46B4-AF0B-392DB08CBBCD@samsco.org> <20100531095617.GR83316@deviant.kiev.zoral.com.ua> <71B7DEC2-1ABE-4333-8C8E-02F899D2449B@samsco.org> <alpine.BSF.2.00.1005311456430.91047@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 May 2010, Robert Watson wrote:
>
> I think Kostik's question here is legitimate: clang maturity changes over 
> time.  The earlier we adopt it, the sooner we get the advantages of clang -- 
> but we also end up being the people who fault in more of the hard-to-diagnose 
> compiler bugs.  Since Kostik fields many of our complex file system/VM/etc 
> bugs, which are themselves often symptoms of hardware problems rather than 
> software bugs (a similar class of issue), and is on the release engineering 
> team, I think he speaks with some authority on the matter.
>
> I happen to (currently) disagree with him on whether clang is ready for us to 
> drop in the base system, as I feel providing early access to it (but not 
> enabling it as the bootstrap by default) will be of significant benefit, but 
> don't think that delegitimizes the concern he raises.  You can burn a lot of 
> hours chasing software bugs only to eventually (or never) figure out they are 
> compiler bugs.
>
> This is the trade-off, but as you point out in your e-mail, there is also a 
> larger non-technical context.  By throwing our weight behind clang, we 
> benefit in numerous and often non-technical ways: we lend the clang folks an 
> engaged and technically astute user community who can help them mature their 
> software, as well as give them a user they community they can point at as 
> part of establishing their own legitimacy.  That engagement in turn means 
> they will be more responsive to our needs, and it's clear we're at a swing of 
> the compiler/systems pendulum where we can benefit from the improved compiler 
> technology we get through using clang.

I would like to see this decision made without political bias.

Is clangBSD able to support all our architectures?  Does it
cross build for powerpc, mips, etc?  Has it made a ports run
and does it successfully build and run most of our ports on
Tier-1 archs, and does it compare similarly with gcc for ports
on other archs?

If it is clearly in a state to entirely replace gcc, then
I say import it.  But if it is not yet there, and won't be
for some time, then I would say leave it out for the time
and import it when it can.

-- 
DE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1005311051440.12132>