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

[Jonathan Wakely]

On 21/05/20 17:46 +0200, Marc Glisse wrote:
>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...

Good point about ODR violations.

Maybe we should just let numeric_limits fade away and be irrelevant,
and replace it with something better which can be more useful.