http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #26 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- (In reply to Nick Maclaren from comment #25) > 3.4.3 says: > undefined behavior > behavior, upon use of a nonportable or erroneous program construct > or of erroneous data, for which this International Standard imposes > no requirements > > 4. Conformance, paragraph 2, says: > ... Undefined behavior is otherwise indicated in this International > Standard by the words "undefined behavior" or by the omission of any > explicit definition of behavior. There is no difference in emphasis > among these three; they all describe "behavior that is undefined". > > What "explicit definition of behavior" is there for the case when > STDC FENV_ACCESS is set to "on" but __STDC_IEC_559__ is not set to one? The behavior is defined. The standard says, e.g. for C99: ---- 7.6.1 The FENV_ACCESS pragma 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.184) [...] 184) The purpose of the FENV_ACCESS pragma is to allow certain optimizations that could subvert flag tests and mode changes (e.g., global common ubexpression elimination, code motion, and constant folding). In general, if the state of FENV_ACCESS is ``off'', the translator can assume that default modes are in effect and the flags are not tested. ---- And there is here no relation at all with __STDC_IEC_559__. > As there is none, it is undefined behaviour. gcc can therefore do > whatever it likes. No.
