https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #10 from Alexander Cherepanov <ch3root at openwall dot com> --- On 2016-06-08 20:47, pinskia at gcc dot gnu.org wrote: > --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > I think this is really a dup of bug 57484. The problem is x87 related and > there is not much to be done. I don't think so. I haven't looked into floating-point arithmetic in any details but, as a first approximation, I see the situation like this: - sNaNs are not required by C11 (including by Annex F); - mere load (e.g. from a volatile var) of a float or double sNaN traps on x86-32 when traps are enabled; - 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. OTOH copying of structures doesn't invoke UB and is required not to trap. (At least if its address is taken:-) (Not sure if this is contradicted by C11, 6.2.6.1p5: "If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.50)". But the intention of DR 222 is quite clear.) 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.
