GCC doesn't set the inexact flag on inexact compile-time int-to-float conversion: #include <stdio.h> #include <fenv.h> #pragma STDC FENV_ACCESS ON void test1 (void) { volatile float c; c = 0x7fffffbf; printf ("c = %a, inexact = %d\n", c, fetestexcept (FE_INEXACT)); } void test2 (void) { volatile float c; volatile int i = 0x7fffffbf; c = i; printf ("c = %a, inexact = %d\n", c, fetestexcept (FE_INEXACT)); } int main (void) { test1 (); test2 (); return 0; } Under Linux/x86_64: $ gcc -std=c99 -O3 conv-int-flt-inex.c -o conv-int-flt-inex -lm $ ./conv-int-flt-inex c = 0x1.fffffep+30, inexact = 0 c = 0x1.fffffep+30, inexact = 32 Ditto without optimizations. Note: the STDC FENV_ACCESS pragma is currently not supported (PR 34678), but I don't think it is directly related (this is not an instruction ordering problem...). This bug has been found from: http://gcc.gnu.org/ml/gcc-help/2013-04/msg00164.html
There is no -finexact-math flag similar to -frounding-math we could guard such transforms with. Certainly the default of that flag is 'off' by design, similar to -frounding-math.
There is -ftrapping-math, which I think is supposed to have an effect here. And if this was implemented properly, I hope it would be turned off by default.
(In reply to comment #2) > There is -ftrapping-math, which I think is supposed to have an effect here. And > if this was implemented properly, I hope it would be turned off by default. -ftrapping-math is on by default. And whether -ftrapping-math or -fno-trapping-math is used, the behavior is the same.
PR84407 was related which was about rounding modes and int-to-float conversion which means the testcase in this bug should now also be fixed if you supply -frounding-math which is documented as to determine the default of #pragma STDC FENV_ACCESS when the latter is implemented. But yes, -ftrapping-math is not enough to preserve the conversions from being constant folded (and thus the exception being lost). Not sure if separate control of this is really desirable.