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? -Y
