llvm dev - Sep 2014 - [LLVMdev] Optimization of sqrt() with invalid argument

> I know it's part of test-suite/external, but this constant fold code
has
> been around 5+ years. Was the bug lying dormant all this time, only visible
> on PPC, or something else?
My guess would be that people don't tend to run with -ffast-math (it's
got a reputation for breaking code, even ignoring this particular
issue). Without that, from what I can see the issue won't arise.

But that doesn't account for complete silence, it must happen occasionally.

Cheers.

Tim.

> On Sep 26, 2014, at 11:59 AM, Tim Northover <t.p.northover at
gmail.com> wrote:
> 
>> I know it's part of test-suite/external, but this constant fold
code has
>> been around 5+ years. Was the bug lying dormant all this time, only
visible
>> on PPC, or something else?
> 
> My guess would be that people don't tend to run with -ffast-math
(it's
> got a reputation for breaking code, even ignoring this particular
> issue). Without that, from what I can see the issue won't arise.
If this can really only happen under fast-math, I take back what I said
entirely.  IIRC, NaNs are explicitly not supported in that mode, so all bets are
off.  Zero is a perfectly reasonable result.

– Steve

On Fri, 2014-09-26 at 12:09 -0400, Stephen Canon wrote:
> > On Sep 26, 2014, at 11:59 AM, Tim Northover <t.p.northover at
gmail.com> wrote:
> > 
> >> I know it's part of test-suite/external, but this constant
fold code has
> >> been around 5+ years. Was the bug lying dormant all this time,
only visible
> >> on PPC, or something else?
> > 
> > My guess would be that people don't tend to run with -ffast-math
(it's
> > got a reputation for breaking code, even ignoring this particular
> > issue). Without that, from what I can see the issue won't arise.
> 
> If this can really only happen under fast-math, I take back what I said
entirely.  IIRC, NaNs are explicitly not supported in that mode, so all bets are
off.  Zero is a perfectly reasonable result.
The result of this is that we return 0 only under -ffast-math.  In all
other cases, the sqrt call will remain and we will return NaN.  So that
seems like a bothersome discrepancy given that the Posix standard
wording tends to favor NaN (though an implementation-defined value is
allowable, regardless of -ffast-math).

As mentioned earlier, a number of other compilers also generate NaN with
-ffast-math or its equivalent.  I believe this is done to comply with
the Posix wording.

Regardless of feelings about playing benchmark games (with which I have
sympathy), people tend to compile many of the SPECfp benchmarks with
-ffast-math so they can, e.g., use FMA instructions in their publishes.
But this is a side issue, and I'm rather sorry I mentioned SPEC at all.
This is really an issue of internal and external consistency.

Thanks,
Bill
> 
> – Steve