[Bug rtl-optimization/106785] ICE in fail, at selftest.cc:47 since r13-2266-g8bb1df032cc080

[aldyh at gcc dot gnu.org]

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.