http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #28 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Nick Maclaren from comment #27)
> On Jan 14 2014, vincent-gcc at vinc17 dot net wrote:
> >The FENV_ACCESS pragma provides a means to inform the implementation when a
> >program might access the floating-point environment to test floating-point
> >status flags or run under non-default floating-point control modes.
>
> I suggest looking up the word "explicit" in a dictionary.
The above is an explicit definition. Where do you see an undefined behavior
here?
#include <fenv.h>
#pragma STDC FENV_ACCESS ON
int main (void)
{
return 0;
}
The modes and so on are dealt with in other parts of the standard, e.g.
----
Each of the macros
FE_DOWNWARD
FE_TONEAREST
FE_TOWARDZERO
FE_UPWARD
is defined if and only if the implementation supports getting and setting the
represented rounding direction by means of the fegetround and fesetround
functions.
----
This doesn't mean that the rounding direction will necessarily be honored even
for the basic operations (just like the C standard doesn't require "1.0+2.0" to
evaluate as 3.0, and a poorly-designed implementation could decide that 1-bit
accuracy is OK), but honoring the rounding direction when the processor does[*]
is a reasonable QoI feature. Basically, this means: disabling some
optimizations when STDC FENV_ACCESS is set to ON. This is what this bug is
about.
[*] a weaker requirement than __STDC_IEC_559__ being set to 1.
Note that the C standard doesn't explicitly say how a source file as a sequence
of bytes is to be interpreted as a sequence of character, so that if you just
restrict to the C standard, everything is undefined. The discussion is going
nowhere.
