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

[Matthias Kretz <m.kretz@gsi.de>]

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, ... 

-- 
──────────────────────────────────────────────────────────────────────────
 Dr. Matthias Kretz                           https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research               https://gsi.de
 std::experimental::simd              https://github.com/VcDevel/std-simd
──────────────────────────────────────────────────────────────────────────