Re: Clang as default compiler November 4th

On 15-09-2012 03:06, Steve Kargl wrote:
> On Fri, Sep 14, 2012 at 05:18:08PM -0700, Steve Kargl wrote:
>>
>> A third class of failure appears to be that clang emits
>> i387 fpu instructions for at least sinf and cosf instead 
>> of calls to the library routines.  AFAIK, the library
>> routines are faster and more accurate.
>>
> 
> Yep. Clang has problems with at least sinf on i386 FreeBSD.
> 
> % pwd
> /usr/home/kargl/trunk/math/sine
> 
> % make clean && make CC=cc testf
> cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \
>  -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm
> 
> % ./testf -m 0 -M 1e20 -r
>  ULP Range |
> -----------+-------------------------
>  [0.0:0.6] | 1006424    (100.00%)
>  (0.6:0.7] | 0  ( 0.00%)
>  (0.7:0.8] | 0  ( 0.00%)
>  (0.8:0.9] | 0  ( 0.00%)
>  (0.9:1.0] | 0  ( 0.00%)
>  (1.0:2.0] | 0  ( 0.00%)
>  (2.0:3.0] | 0  ( 0.00%)
>  3.0 < ULP | 0  ( 0.00%)
> -----------+-------------------------
>    Count   | 1006424
>    Max ULP | 0.50084
>  Max ULP x | 53462490661259313152.000000 0x1.72f876p+65
> 
> % make clean && make CC=clang testf
> clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \
>  -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm
> 
> % ./testf -m 0 -M 1e20 -r
>  ULP Range |
> -----------+-------------------------
>  [0.0:0.6] | 1  ( 0.00%)
>  (0.6:0.7] | 0  ( 0.00%)
>  (0.7:0.8] | 0  ( 0.00%)
>  (0.8:0.9] | 0  ( 0.00%)
>  (0.9:1.0] | 0  ( 0.00%)
>  (1.0:2.0] | 0  ( 0.00%)
>  (2.0:3.0] | 0  ( 0.00%)
>  3.0 < ULP | 999998     (100.00%)
> -----------+-------------------------
>    Count   | 999999
>    Max ULP | 1328505256679420125050194353979392.00000
>  Max ULP x | 75516780764213542912.000000 0x1.06006p+66

A ULP this big can't be because of using a built-in instead of a library
call, right? Something must be wrong with clang's implementation of the
built-in. The fcos/fsin instructions have a limited domain and return a
value unchanged if it's outside that domain. Maybe clang doesn't check
this.

This error probably also explains the precision loss in j0, because it
calls cos/sin.