On Thu, 5 Nov 2015, Sujoy Saraswati wrote: > > Some other places in this patch have similar issues with checking > > HONOR_SNANS && REAL_VALUE_ISNAN when they should check if the particular > > value is sNaN. > > I modified the code to check for sNaN specifically. The modified patch > is below.
This is looking pretty close to ready to go in, but the patch also seems to be doing several things at once and it might be easier to review if split into separate logical pieces. For example (this is an illustration, not necessarily saying it should be exactly this way): (1) Add REAL_VALUE_ISSIGNALING_NAN and convert existing logic that already does something equivalent (so no semantic change, just cleanup). (2) Convert existing code that checks for all NaNs in cases where REAL_VALUE_ISSIGNALING_NAN would be enough. (3) Treat rint and nearbyint the same. (4) Make real.c operations properly produce quiet NaNs for operations with signaling NaN input. (5) Disable various transformations for signaling NaN operands, where folding them loses exceptions. This patch is also getting big enough that it would be a good idea to complete the copyright assignment paperwork, certainly if you plan to make more contributions in future, if you're not covered by a corporate assignment. > @@ -1943,7 +1965,17 @@ fold_convert_const_real_from_real (tree type, cons > REAL_VALUE_TYPE value; > tree t; > > + /* Don't perform the operation if flag_signaling_nans is on > + and the operand is a NaN. */ > + if (HONOR_SNANS (TYPE_MODE (TREE_TYPE (arg1))) > + && REAL_VALUE_ISSIGNALING_NAN (TREE_REAL_CST (arg1))) > + return NULL_TREE; > + > real_convert (&value, TYPE_MODE (type), &TREE_REAL_CST (arg1)); > + /* Make resulting NaN value to be qNaN when flag_signaling_nans > + is off. */ > + if (REAL_VALUE_ISSIGNALING_NAN (value)) > + value.signalling = 0; Shouldn't real_convert do this rather than the caller needing to do it? -- Joseph S. Myers jos...@codesourcery.com