Re: Optimization bug with floating-point?

On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote:
> On 2019-Mar-13 23:30:07 -0700, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:
> >AFAICT, all libm float routines need to be modified to conditional
> >include ieeefp.h and call fpsetprec(FP_PD).  This will work around
> >issues is FP and libm.  FreeBSD needs to issue an erratum about 
> >the numerical issues with clang.
> 
> I vaguely recall looking into the x87 initialisation a long time ago
> and STR that the startup code (either crtX or in the kernel) does
> a fninit() to set the precision.  I don't recall exactly where.
> 
> IMO, calling fpsetprec() in every libm float function is overkill. It
> should be enough to fpsetprec() before main() and add a note in the
> man pages that libm is built to use the default FPU configuration and
> changing the configuration (precision or rounding) may result in larger
> errors.

My understanding of the situation is that FreeBSD i386/387 sets
the FPU to 53-bit precision (whether at start up or first access
is immaterial).  This was done long ago to prevent issues with
different optimization levels leaving different intermediate
results is registers with extended precision.  You can observe
the problem with the toy program I posted and clang.  Compile it
with -O0 and -O2.  With the former you have max ULP of 2.9 (the
desired result); with the latter you have a max ULP of 23.xxx.
I have observed a 6 billion ULP issue when running my testsuite.
As pointed out by John Baldwin, GCC is aware of the FPU setting.
The problem with clang is that it seems to unconditionally assume
the FPU is set to 64-bit precision.   It is unclear if clang is
generated the desired result for float routines in libm.  The
only to gaurantee the desired resut is to use fpsetprec(FP_PD),
or fix clang to take into account the FPU environment.

-- 
Steve