http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Thu, 30 Jan 2014, jakub at gcc dot gnu.org wrote: > I guess the important thing is if it is allowed to raise exceptions on a > simple > load and store of a floating point value. So: At C level, if we follow draft TS 18661-1 (WG14 N1778) for specification of signaling NaNs, "Whether C assignment (6.5.16) (and conversion as if by assignment) to the same format is an IEC 60559 convertFormat or copy operation is implementation-defined, even if <fenv.h> defines the macro FE_SNANS_ALWAYS_SIGNAL". I think it's most useful for such assignments, function calling etc. to be implemented not to raise exceptions - doing otherwise prevents properly implementing issignaling. But when actual floating-point assignments are involved (as in bug 56831) it's only really a bug with -fsignaling-nans (although if there isn't any significant performance cost it's probably best not to depend on that). When, as in bug 58416 and here, there are no floating-point assignments involved, it's entirely unambiguously a bug to raise exceptions. > If it is ok that thiscase aborts and the #c0 should not, then the bug would be > in fold-const.c and we should use integral types instead of floating point > types to fold the copy. If this testcase shouldn't abort too, then it is a > target issue, where it should avoid the i387 loads if the result isn't used in > some arithmetic instruction. And if the value is both used in arithmetic and copied with memcpy, the copy can't reuse the value that was loaded into a floating-point register for the arithmetic (because the copy needs to copy the original signaling NaN to the destination, not the quiet NaN that resulted from the floating-point load).
