On Thu, 21 May 2020, Jonathan Wakely wrote:
On 27/04/20 17:09 +0200, Matthias Kretz wrote:From: Matthias Kretz <kr...@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
