From owner-freebsd-current@FreeBSD.ORG Fri Sep 14 20:37:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0CD41065672; Fri, 14 Sep 2012 20:37:21 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8AD8FC14; Fri, 14 Sep 2012 20:37:20 +0000 (UTC) Received: by vbmv11 with SMTP id v11so6859928vbm.13 for ; Fri, 14 Sep 2012 13:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=mr0xVuKcNHj28rhWMXjho2ocYNbd0In3L6rKhdcrxnI=; b=ENj+as9jSL6I3+nK1RkEgllLLeU9cF3FyS15xjJ4dXEp3ZeGH2CwNI0+4eN6HGs2N9 jzS4UDZV4+Z3ax5gNntAOZllxENoJ7F2L5bkuU4btmAGULr0qQx/TKEgLaoS1zcNc6DK /FZXzzaQNkrF3hlkQblXKJYWpogWKv9jFmC+0KXZI5CzBfShbc0vV6F82XQp78pm8hMD /P6PKBbf3dLIdnl5Js3sWzh7plqT3fRRzepQlpaFuCNCxSgKtgFuoYMF+4Gkn35imRA1 8x0wM3kQv8L1EbPr0+tsX56iYa5UyUiSANiusiBPCf57735xOJrbTCjQqi3TxG0sn6/K /fpg== Received: by 10.58.58.147 with SMTP id r19mr3541798veq.5.1347655040239; Fri, 14 Sep 2012 13:37:20 -0700 (PDT) Received: from AL-MB-MWS0001.mediacomcorp.com (70-13-250-220.pools.spcsdns.net. [70.13.250.220]) by mx.google.com with ESMTPS id b7sm298168vdv.2.2012.09.14.13.37.17 (version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 13:37:19 -0700 (PDT) Date: Fri, 14 Sep 2012 15:37:15 -0500 From: Chuck Burns To: Brooks Davis Message-Id: <20120914153715.4aa1a412.break19@gmail.com> In-Reply-To: <20120914202319.GB5244@lor.one-eyed-alien.net> References: <20120911104518.GF37286@deviant.kiev.zoral.com.ua> <20120911120649.GA52235@freebsd.org> <20120911132410.GA87126@troutmask.apl.washington.edu> <504F4645.4070900@FreeBSD.org> <504F4A6B.4010001@coosemans.org> <504F5101.8090906@FreeBSD.org> <505101C3.70203@freebsd.org> <20120913020833.GA8255@troutmask.apl.washington.edu> <1347550332.1110.108.camel@revolution.hippie.lan> <20120913161024.GA13846@troutmask.apl.washington.edu> <20120914202319.GB5244@lor.one-eyed-alien.net> X-Mailer: Sylpheed 3.1.3 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Clang as default compiler November 4th X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 20:37:21 -0000 On Fri, 14 Sep 2012 15:23:19 -0500 Brooks Davis wrote: > On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote: > > On Thu, Sep 13, 2012 at 09:32:12AM -0600, Ian Lepore wrote: > > > On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote: > > > > In regards to my initial post in this thread, I was just trying > > > > to assess whether any benchmarks have been performed on FreeBSD > > > > for floating point generated by clang. Other than the limited > > > > testing that I've done, it appears that the answer is 'no'. > > > > > > > > > > We have src/tools/tests/testfloat and src/tools/regression/lib/msun. I > > > know nothing about the former (just noticed it for the first time). The > > > latter I think is a set of correctness tests rather than performance > > > tests. > > > > It's quite clear that the clang proponent have not tried > > to run src/tools/regression/lib/msun. > > > > % setenv CC clang > > % make |& grep warning | wc -l > > 1354 > > % make clean > > % make |& tee make.log > > % head -20 make.log > > clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp > > test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] > > #pragma STDC FENV_ACCESS ON > > ^ > > test-cexp.c:183:2: warning: expression result unused [-Wunused-value] > > testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > test-cexp.c:98:7: note: expanded from macro 'testall' > > test(cexp, x, result, exceptmask, excepts, checksign); \ > > ^ > > test-cexp.c:87:11: note: expanded from macro 'test' > > assert(((func), fetestexcept(exceptmask) == (excepts))); \ > > ^ > > /usr/include/assert.h:54:21: note: expanded from macro 'assert' > > #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ > > ^ > > test-cexp.c:183:2: warning: expression result unused [-Wunused-value] > > testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > test-cexp.c:99:7: note: expanded from macro 'testall' > > > > % tail -20 make.log > > test-trig.c:69:11: note: expanded from macro 'test' > > assert(((func), fetestexcept(exceptmask) == (excepts))); \ > > ^ > > /usr/include/assert.h:54:21: note: expanded from macro 'assert' > > #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ > > ^ > > 74 warnings generated. > > clang -O2 -pipe -march=opteron -O0 -lm test-fenv.c -o test-fenv > > test-fenv.c:82:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] > > #pragma STDC FENV_ACCESS ON > > ^ > > 1 warning generated. > > for p in test-cexp test-conj test-csqrt test-ctrig test-exponential test-fma test-fmaxmin test-ilogb test-invtrig test-logarithm test-lrint test-lround test-nan test-nearbyint test-next test-rem test-trig test-fenv; do /usr/src/tools/regression/lib/msun/$p; done > > Assertion failed: (((cexp), fetestexcept((0x04 | 0x20 | 0x01 | 0x08 | 0x10)) == (0))), function test_nan, file test-cexp.c, line 211. > > 1..7 > > ok 1 - cexp zero > > Abort trap (core dumped) > > *** [tests] Error code 134 > > > > Stop in /usr/src/tools/regression/lib/msun. > > Prompted by this post, I did a bit of testing and it looks like we have > two classes of failures that need to be investigated. First, some tests > are failing with a gcc compiled world and clang compiled test code. > They seem to mostly be unexpected fp exception state when testing with > NaNs. I suspect that someone more knowledgeable in this area could come > up with a reduced test case and explication of what clang is doing wrong > pretty quickly. > > The second class is tests that fail when libm is compiled using clang. > I've not investigate those at all. I'd tend to guess that we have a > wider range of issues there. > > This is clearly an area we need more focus on before a switch to clang. > To a point I would be OK with it delaying the switch to work these > issues, but as with C99 long double support we can't let the quest for > perfection delay us indefinitely. > > -- Brooks Also, you probably want to be sure you are running these tests against clang 3.2, not the clang that is in base, since -that- is the version that will be going live, right? -- Chuck Burns