On Fri, Jul 7, 2017 at 11:51 PM, Joseph Myers <jos...@codesourcery.com> wrote:
> On Fri, 7 Jul 2017, Yuri Gribov wrote:
>
>> > I suspect infinities would already work with the patch as-is (the logic
>> > dealing with constants outside the range of the integer type). I'm less
>> > clear that NaNs would work properly. (If the comparison is == or != you
>> > can optimize it for quiet NaNs, to false and true respectively. If it's a
>> > signaling NaN, or < <= > >=, optimizing to false is only valid with
>> > -fno-trapping-math, as it would lose an "invalid" exception.)
>>
>> It's actually under -fsignaling-nans (which if off by default). I've
>
> No, ordered comparisons with qNaNs should result in exceptions,
I assume you mean sNaNs.
> so it's not valid by default to optimize them to false (whereas it is valid
> for
> equality comparisons, as those only raise exceptions for signaling NaNs).
I'm afraid this is default GCC behavior atm - e.g. check existing
/* a CMP (-0) -> a CMP 0 */
...
(if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1))
&& ! HONOR_SNANS (@1))
{ constant_boolean_node (cmp == NE_EXPR, type); })
(this pattern causes testcase in my patch pr53731-5.c to be optimized).
Or documentation for -fsignaling-nans which says that "the default is
-fno-signaling-nans" and it "may change the number of exceptions
visible with signaling NaNs".
In any case, decision to optimize sNaNs is done in HONOR_NANS macro
which my code duly checks so I'm not really sure what else needs to be
done about discussed patch in this regards.
-Y
