Re: Optimization bug with floating-point?

On 3/14/19 12:20 PM, Konstantin Belousov wrote:
> 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.
> At boot, a clean initial FPU state is stored in fpu_initialstate.
> Then on first FPU access from userspace  (first for the given process
> context), this saved state is copied into hardware registers.  The
> quirk is that for i386 binaries on amd64, we adjust fpu control word
> to what is expected by i386 binaries.
> 
>>
>> 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.
> Changing default precision in crt1 would break the ABI.

So what I don't understand then is what is gcc doing different than clang
in this case.  I assume neither GCC _nor_ clang are adjusting the FPU in
compiler-generated code, and in fact as Steve's earlier tests shows, the
precision is set to PD by default when a clang-built binary is run.

-- 
John Baldwin