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

[Jonathan Wakely <jwakely@redhat.com>]

On 22/05/20 09:49 +0200, Matthias Kretz wrote:
>On Donnerstag, 21. Mai 2020 17:46:01 CEST 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.
>
>But these ODR violations happen in any case: The floating-point types are
>different types with or without -ffast-math (and related) flags. They behave
>differently. Compiling a function in multiple TUs with different flags
>produces observably different results. Choosing a single one of them is
>obviously fragile and broken. That's the spirit of an ODR violation...
>
>It would sometimes be useful to have different types:
>float, float_no_nan, float_no_nan_no_signed_zero, ...

Sure. There are ODR violations like that, and then there are ones
like:

   template<typename T>
   struct X
   {
     conditional_t<numeric_limits<T>::is_iec559, T, BigNum> val;
   };

I'm generally not concerned about ODR violations where one TU behaves
as requested by the flags used to compile that TU and another behaves
as requested by the flats used to compile that second TU. That happens
all the time with -fno-exceptions and -fno-rtti and such like. That
causes ODR violations too, but of the kind where each definition does
what was requested.

Constants defined by the library changing value is a bit more
concerning. But I don't know if it's really a problem in this case.