https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126
--- Comment #4 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- (In reply to Richard Biener from comment #3) > You can use -ffp-contract=off but I don't think these transforms are > affected. I confirm that the test behaves in the same way with -ffp-contract=off too. BTW, -ftrapping-math is documented to be the default. > Note FENV_ACCESS is also ignored but then -ftrapping-math should indeed make > your testcase valid. Are denormals standardized or left towards the > implementation? One could argue the underflow exception with * 1 on a > denormal isn't covered? Subnormals are actually even standardized in the main C specification, but are required only for float and double if __STDC_IEC_559__ is defined (Annex F): float and double match IEC 60559 (= IEEE 754) single and double formats respectively, and all IEEE 754 formats have subnormals. But what is important here is more the specification of underflow. In C17, F.10: The “underflow” floating-point exception is raised whenever a result is tiny (essentially subnormal or zero) and suffers loss of accuracy.377) 377) IEC 60559 allows different definitions of underflow. They all result in the same values, but differ on when the floating-point exception is raised. However, IMHO, if the processor has some definition of underflow (typically conforming to the IEEE 754 one), optimization should not yield a different one. IEEE 754-2019 (which has a simpler definition than 754-1985, by eliminating choices that have never been used in practice, according to discussions in the stds-754 list) says: "The underflow exception shall be signaled when a tiny non-zero result is detected." It still allows differences about tininess detection (i.e. either after rounding or before rounding, the difference being for exact values close to the minimum normal number in magnitude), but this does not matter on my example. It also says: "In addition, under default exception handling for underflow, if the rounded result is inexact — that is, it differs from what would have been computed were both exponent range and precision unbounded — the underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. If the rounded result is exact, no flag is raised and no inexact exception is signaled. This is the only case in this standard of an exception signal receiving default handling that does not raise the corresponding flag. Such an underflow signal has no observable effect under default handling." When the underflow trap is enabled, this is not the default exception handling for underflow. Thus, whether the result is exact or not, the exception is expected to be signaled in the same way, here with a trap.
