]> git.ipfire.org Git - thirdparty/gcc.git/commit
Make frange selftests work on !HONOR_NANS systems.
authorAldy Hernandez <aldyh@redhat.com>
Wed, 31 Aug 2022 12:31:12 +0000 (14:31 +0200)
committerAldy Hernandez <aldyh@redhat.com>
Thu, 1 Sep 2022 07:08:29 +0000 (09:08 +0200)
commitbdfe0d1ce0aebdb68b77e2c04a0f45956c56b449
tree1b4697330f2a36936588cd59cf9f2d188044795a
parentca8f4e8af148694ae2fd444a0cdcf713910d23fd
Make frange selftests work on !HONOR_NANS systems.

I'm just shuffling the FP self tests here, with no change to existing
functionality.

If we agree that explicit NANs in the source code with !HONOR_NANS
should behave any differently, I'm happy to address whatever needs
fixing, but for now I'd like to unblock the !HONOR_NANS build systems.

I have added an adaptation of a test Jakub suggested we handle in the PR:

void funk(int cond)
{
  float x;

  if (cond)
    x = __builtin_nan ("");
  else
    x = 1.24;

  bar(x);
}

For !HONOR_NANS, the range for the PHI of x_1 is the union of 1.24 and
NAN which is really 1.24 with a maybe NAN.  This reflects the IL-- the
presence of the actual NAN.  However, VRP will propagate this because
it sees the 1.24 and ignores the possibility of a NAN, per
!HONOR_NANS.  IMO, this is correct.  OTOH, for HONOR_NANS the unknown
NAN property keeps us from propagating the value.

Is there a reason we don't warn for calls to __builtin_nan when
!HONOR_NANS?  That makes no sense to me.

PR tree-optimization/106785

gcc/ChangeLog:

* value-range.cc (range_tests_nan): Adjust tests for !HONOR_NANS.
(range_tests_floats): Same.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/vrp-float-nan-1.c: New test.
gcc/testsuite/gcc.dg/tree-ssa/vrp-float-nan-1.c [new file with mode: 0644]
gcc/value-range.cc