On Mon, 14 Sep 2015, Richard Biener wrote: > I'll leave the correctness part of the patch to Joseph who knows FP > arithmetic better than me, > implementation-wise this is ok if you fix the REAL_CST sharing issue.
Changing fold_abs_const is wrong - abs of sNaN is sNaN, no exceptions raised. Changing real_arithmetic is wrong for the NEGATE_EXPR and ABS_EXPR cases, both of which should just affect the sign bit without quieting sNaNs. All the comments in the patch should end with ". " (full stop, two spaces). If -fsignaling-nans, then folding of expressions involving sNaNs should be disabled, outside of static initializers - such expressions should not get folded to return an sNaN (it's incorrect to fold sNaN + 1 to sNaN, for example). I think existing code may ensure that (the HONOR_SNANS check in const_binop, for example). Inside static initializers, expressions involving sNaNs still need to be folded (so sNaN + 1 becomes qNaN inside such an initializer, for example, with the translation-time exception being discarded). Again, existing code should handle this: START_FOLD_INIT / END_FOLD_INIT already handle clearing and restoring flag_signaling_nans. My understanding of the design of the existing code is that real.c will do the arithmetic regardless of whether it might raise an exception or have rounding-mode-dependent results, with fold-const.c being responsible for deciding whether the result can be used to fold the expression in question. That is, you shouldn't need any flag_signaling_nans conditions in real.c; rather, if IEEE semantics mean an sNaN is quieted, real.c should do so unconditionally. It should be the callers in fold-const.c that check HONOR_SNANS and disallow folding when it would lose exceptions. -- Joseph S. Myers jos...@codesourcery.com