https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785
--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> If !MODE_HAS_NANS, then NANs can't appear ever, that is the VAX case.
> Some floating point formats simply have no representation for those.
> If MODE_HAS_NANS && !HONOR_NANS, it is user promising NaNs won't appear but
BTW, HONOR_NANS already uses MODE_HAS_NANS. It's defined as:
return MODE_HAS_NANS (m) && !flag_finite_math_only;
so MODE_HAS_NANS && !HONOR_NANS is really:
MODE_HAS_NANS && flag_finite_math_only
I take it MODE_HAS_NANS means the FP format supports them?
> the floating point format supports them. Code where NaN would appear is UB,
> we can do anything we want, just shouldn't break code where the NaN wouldn't
> appear at runtime. Say
> if (cond)
> x = __builtin_nan ("");
> else
> x = 1.24;
> we can assume that x will never be NaN with -ffinite-math-only.
But wouldn't the NaN appear at runtime? I mean, I expect __builtin_nan to mean
something concrete even with !HONOR_NANS or !MODE_HAS_NANS or whatever. If
someone is explicitly requesting a NAN, that really smells like undefined
behavior.
That being said, I think we're ok for the snippet above:
void funk(int cond)
{
float x;
if (cond)
x = __builtin_nan ("");
else
x = 1.24;
bar(x);
}
The PHI is:
# x_1 = PHI < Nan(2), 1.2400000095367431640625e+0(3)>
and the code in mainline would set the x_1 range to:
[frange] float [1.2400000095367431640625e+0, 1.2400000095367431640625e+0] !SIGN
which is 1.24 with an unknown NAN (notice the absence of NAN or !NAN). This
would be considered a singleton and propagated by VRP, because
frange::singleton_p() ignores the NAN property if !HONOR_NANS:
bar (1.2400000095367431640625e+0);
I suppose we could leave the NAN bit alone when unioning for !HONOR_NANS. That
is, the union of a NAN would anything would be anything, ignoring the NAN
altogether. That would make x_1:
[frange] float [1.2400000095367431640625e+0, 1.2400000095367431640625e+0] !NAN
!SIGN
But I'd honestly prefer to do nothing. Clear the NAN bit as unknown, since
it'll get caught in singleton_p. Ughh. Either way is fine, I suppose. I'll
add a testcase to make sure we don't break.
