On Mon, 10 Jul 2017, Yuri Gribov wrote: > On Mon, Jul 10, 2017 at 11:06 AM, Joseph Myers <jos...@codesourcery.com> > wrote: > > On Sat, 8 Jul 2017, Yuri Gribov wrote: > > > >> 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. > > > > No, I mean qNaNs, as I said. Any of < <= > >= with a NaN argument, > > whether quiet or signaling, raise "invalid"; == and != only raise > > "invalid" for sNaNs, not qNaNs. (For a few architectures this is broken > > in GCC; see bug 52451 for x86, 58684 for powerpc, 77918 for s390. We > > should not introduce more instances of such breakage, and should fix it > > where it exists.) > > Oh, I see. Assuming that I fix this (in obvious way, by changing > real_issignaling_nan to real_is_nan) and boostrap/regtest, is the rest > of the patch ok?
Please send the updated patch (including any testcase updates needed) for review. -- Joseph S. Myers jos...@codesourcery.com
