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>