Re: Clang as default compiler November 4th

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