https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #1) > BTW, regarding sign, generally NaNs can have either sign, though in this > testcase we know the sign is clear (positive NaN). Not sure how much we can > rely on that though, say if the NaN would be sNaN with known sign bit set, > it could raise an exception and be replaced by canonical qNaN which doesn't > have sign set. I take that back. There's no reason why we can't keep the signbit up to date wrt NANs. For that matter, we're doing pretty good. I just found one case where unioning a NAN and a range with a known sign bit clobbers the NAN. Everything else is working, so I think we should just fix that and then you can do whatever you need with signalling nans and what have you. I still have to implement folding of __builtin_copysign, but that's trivial. ?? And if we keep NAN signs up to date, maybe just maybe, we can return a NAN from singleton_p() if we're sure about the sign. ISTM we should be able to propagate a known NAN with SIGN. Or is there some funky floating point property where we can't propagate those?
