https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Thu, 9 Jun 2016, ch3root at openwall dot com wrote: > - mere load (e.g. from a volatile var) of a float or double sNaN traps > on x86-32 when traps are enabled; It raises an exception. Exception trapping is outside the scope of ISO C. > - this perfectly fits the description of trap representation. > So gcc de facto doesn't support sNaNs in this configuration and any its > use is UB. No, it's not UB (given -fsignaling-nans). Rather, it's OK for the loads to raise an exception because assignment / argument passing etc. can be implemented as convertFormat rather than copy, which means raising the exception and converting to qNaN. (As a quality-of-implementation issue I still think that with -fsignaling-nans, floating-point loads should be avoided for simple copies of float and double values where they aren't needed in a floating-point register for arithmetic, function return etc. - that would allow sNaNs to be passed as function arguments, for example.) > IOW this bug is not about wrong handling of sNaNs, it's about > introducing sNaN-related problems where there were none. Like copying a > partially initialized struct where one of unknown fields happened to > have the double type and sNaN as representation. Indeed, which is why a fix for this issue / bug 58416 should *not* be conditional on -fsignaling-nans - it affects code that doesn't use signaling NaNs, just bit patterns that are never actually interpreted with type float or double (but if so interpreted, would be signaling NaNs).
