Re: [PATCH] Let numeric_limits::is_iec559 reflect -ffast-math

[Marc Glisse <marc.glisse@inria.fr>]

On Thu, 21 May 2020, Jonathan Wakely wrote:

> On 27/04/20 17:09 +0200, Matthias Kretz wrote:
>> 
>> From: Matthias Kretz <kretz@kde.org>
>>
>>        PR libstdc++/84949
>>        * include/std/limits: Let is_iec559 reflect whether
>>        __GCC_IEC_559 says float and double support IEEE 754-2008.
>>        * testsuite/18_support/numeric_limits/is_iec559.cc: Test IEC559
>>        mandated behavior if is_iec559 is true.
>>        * testsuite/18_support/numeric_limits/infinity.cc: Only test inf
>>        behavior if is_iec559 is true, otherwise there is no guarantee
>>        how arithmetic on inf behaves.
>>        * testsuite/18_support/numeric_limits/quiet_NaN.cc: ditto for
>>        NaN.
>>        * testsuite/18_support/numeric_limits/denorm_min-1.cc: Compile
>>        with -ffast-math.
>>        * testsuite/18_support/numeric_limits/epsilon-1.cc: ditto.
>>        * testsuite/18_support/numeric_limits/infinity-1.cc: ditto.
>>        * testsuite/18_support/numeric_limits/is_iec559-1.cc: ditto.
>>        * testsuite/18_support/numeric_limits/quiet_NaN-1.cc: ditto.
>
> I'm inclined to go ahead and commit this (to master only, obviously).
> It certainly seems more correct to me, and we'll probably never find
> out if it's "safe" to do unless we actually change it and see what
> happens.
>
> Marc, do you have an opinion?

I don't have a strong opinion on this. I thought we were refraining from 
changing numeric_limits based on flags (like -fwrapv for modulo) because 
that would lead to ODR violations when people link objects compiled with 
different flags. There is a value in libstdc++.so, which may have been 
compiled with different flags than the application.

Also, IIRC part of the effect of -ffast-math is at link time (linking some 
object that enables flush-to-zero). Anyway, as discussed in the PR, what 
numeric_limits says here is not very meaningful, and users can't rely on 
it 100%.

By default, numeric_limits gives yes if IEC support exists on the 
platform. The change would sometimes make it say no, when we know for sure 
that this support is not enabled at the beginning of the translation unit. 
Why not...

-- 
Marc Glisse