https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #14 from Alexander Cherepanov <ch3root at openwall dot com> --- On 2016-06-08 20:49, joseph at codesourcery dot com wrote: >> - sNaNs are turned into qNaNs on x86-32 if traps are turned off. Probably ok if >> sNaNs and qNaNs are considered different representations of the same value; > > For *scalar* assignment that would be fine because of TS 18661-1 saying > "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 (F.2.1).". It's rather less clear for struct > assignment. How is it compatible with C11, 6.3p2: "Conversion of an operand value to a compatible type causes no change to the value or the representation."? Ha, even changing representation is prohibited. > I expect the present bug is essentially the same as bug 58416 (which > concerns a union, where the floating-point member isn't even the active > one). Indeed. It seems there are 3 variations of this bug: - a struct with one FP member -- triggered even without optimizations; - scalarization of a struct; - scalarization of a union. There are testcases for all of them. On 2016-06-09 19:59, joseph at codesourcery 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. Yes, so on level of ISO C it's just a trap. >> - 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). I was too concise. I mean that it's UB from POV of ISO C. But an implementation is free define some of it. And the standard doesn't place any restrictions on this definition. For example, an implementation can say that it's fine to pass sNaN to a function as an argument but it's not fine to return it from a function. Or it can say that passing it as an argument is not fine too. So the current behavior of gcc on x86-32 can be considered conforming (modulo this bug). > Rather, it's OK for the loads > to raise an exception because assignment / argument passing etc. can be I mean that "volatile double x; /* store sNaN to x */; x;" gives SIGFPE currently. It doesn't look like (re)definitions of assignment etc. would be applicable to this case. > implemented as convertFormat rather than copy, which means raising the > exception and converting to qNaN. As I wrote above, it's not clear to me that this is compatible with the current text of C11. Not that it means much... > (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.) AIUI ABI restricts how FP values are returned from functions so this cannot be fixed (bug 57484). But there are 2 cases that can be fixed (bug 56831): - assignments; - passing arguments to functions. Plus loads in a void context:-)
