From owner-freebsd-toolchain@FreeBSD.ORG Tue Sep 11 12:21:30 2012 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91530106566B; Tue, 11 Sep 2012 12:21:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 28BCC8FC12; Tue, 11 Sep 2012 12:21:29 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q8BCLYaq042941; Tue, 11 Sep 2012 15:21:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q8BCLMJD003903; Tue, 11 Sep 2012 15:21:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q8BCLMvu003902; Tue, 11 Sep 2012 15:21:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Sep 2012 15:21:22 +0300 From: Konstantin Belousov To: Roman Divacky Message-ID: <20120911122122.GJ37286@deviant.kiev.zoral.com.ua> References: <20120910211207.GC64920@lor.one-eyed-alien.net> <20120911104518.GF37286@deviant.kiev.zoral.com.ua> <20120911120649.GA52235@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lYetfuAxy9ic4HK3" Content-Disposition: inline In-Reply-To: <20120911120649.GA52235@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: toolchain@freebsd.org, current@freebsd.org Subject: Re: Clang as default compiler November 4th X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 12:21:30 -0000 --lYetfuAxy9ic4HK3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote: > > > tl;dr: Clang will become the default compiler for x86 architectures o= n 2012-11-04 > >=20 > > 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. > =20 > We currently dont compile 4680 ports (out of 23857). Top 10 ports that pr= event > 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 por= ts > 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. >=20 > > Looking from less amiable angle, you propose to knowingly break signifi= cant > > and important piece of the project work. My belief is that switch cannot > > be done before ports switch to the port-provided compiler. > =20 > 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 ju= st > 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. I do strongly oppose the attempt to drain the freebsd resources by forcing porters to port third-party code to other compiler. >=20 > Note that the work needed to make ports compiling with clang is largely s= hared > with the work to make them compiliable with newer GCCs (as they are stric= ter > etc.) >=20 > > 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 ? >=20 > Agreed. We should provide numbers. At least how buildworld times change > with clang compiled kernel/workd and gcc compiler kernel/world. For this 'silly' benchmark, I would suggest to benchmark the identical buildworlds with only different kernels, compiled with in-tree gcc and clang. >=20 > > 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. >=20 > Thank you for pointing this out. This is, in my opinion, one of the stron= gest > reasons to switch to clang. We can go, fix issues or report we find upstr= eam > 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. --lYetfuAxy9ic4HK3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBPLMIACgkQC3+MBN1Mb4igOQCeKrtDri/g8Cxnlsm4JUdb++Sx I9cAoJ3jv6OTuz3VvlMxLC1mtKjUzwGQ =fhTx -----END PGP SIGNATURE----- --lYetfuAxy9ic4HK3--