Re: Clang as default compiler November 4th

On Fri, 14 Sep 2012 15:23:19 -0500
Brooks Davis <brooks_at_freebsd.org> 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 <break19_at_gmail.com>