From owner-freebsd-toolchain@FreeBSD.ORG Wed May 29 13:25:20 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0AA3238F; Wed, 29 May 2013 13:25:20 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id D96BCDCF; Wed, 29 May 2013 13:25:19 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r4TDPALe057913; Wed, 29 May 2013 06:25:10 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r4TDPARl057912; Wed, 29 May 2013 06:25:10 -0700 (PDT) (envelope-from sgk) Date: Wed, 29 May 2013 06:25:10 -0700 From: Steve Kargl To: David Chisnall Subject: Re: [CFT] gcc: support for barcelona Message-ID: <20130529132510.GA57733@troutmask.apl.washington.edu> References: <51A38CBD.6000702@FreeBSD.org> <51A3B8AB.5080808@FreeBSD.org> <521EEFA1-E116-41F5-B618-238E7AA092A8@bsdimp.com> <3C29AD82-077D-4E6B-94C7-5D069A130348__27528.1591726982$1369769859$gmane$org@FreeBSD.org> <51A5A6F4.8000501@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Andriy Gapon , toolchain@FreeBSD.org, Pedro Giffuni , Rui Paulo , amd64@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:25:20 -0000 On Wed, May 29, 2013 at 09:47:52AM +0100, David Chisnall wrote: > On 29 May 2013, at 07:57, Andriy Gapon wrote: > > > In fact, I am of opinion that while such bugs exist gcc should be crowned back > > as a default compiler. > > Seriously? Your show stopper bug is that, very occasionally, clang emits incorrect debug info? And Steve's is that clang emits code that is fully compliant with the C standard, but gives more floating point precision than he wanted? > Ah, no. I just pointed to the last example of poor floating point support from clang. The other bug I mentioned has sat in the llvm bug database for nearly 2 years. But, to be blunt, clang cannot do complex arithmetic correctly. > If those are the most serious problems we have with clang, then > it's time to remove gcc 4.2.1 from the tree right now. I wish > the problems that we had with it were so trivial... The most serious problems IMNSHO are: 1) The dismal compile time of clang. My buildworlds are 3 to 4 times slower with clang than gcc. I certainly understand the recent explosion in tinderbox messages. No one wants to wait the better part of a day to do a make world and make universe must be painful. 2) Last time I checked, clang could not build a functioning X11 environment. Perhaps, having the xserver blow chunks when she's starting is consider to a Good Thing. When I reported the problem, I was dutifully informed that the problem wasn't clang, it was the x11 loader. Oddly, gcc does not have this issue. May be this has been fix. Don't know, don't care, because the last time I tried clang as the default compiler it took a week to recover a working environment. 3) Last time I benchmarked a libm built by clang against a libm built by gcc. gcc produced smaller, faster code and in one case a gcc compiled function produced a correct result while the clang compiled functions produced NaN for all inputs in a specific range. Yeah, I reported that too. I was told the test case was too complicated. PS: That extra precision can be a big headache when one is trying to write high quality software. -- Steve