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

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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785

            Bug ID: 106785
           Summary: ICE in fail, at selftest.cc:47 since
                    r13-2266-g8bb1df032cc080
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: aldyh at gcc dot gnu.org, amacleod at redhat dot com
  Target Milestone: ---
              Host: x86_64-linux-gnu
            Target: pdp11-aout

Fails for the following cross compilers:
pdp11-aout  rx-elf  vax-linux-gnu  vax-netbsdelf

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: vax-linux-gnu
Configured with: /home/marxin/Programming/gcc/configure
--enable-languages=c,c++ --prefix=/home/marxin/bin/gcc --disable-multilib
--disable-libsanitizer --disable-bootstrap --target=vax-linux-gnu :
(reconfigured) /home/marxin/Programming/gcc/configure --enable-languages=c,c++
--prefix=/home/marxin/bin/gcc --disable-multilib --disable-libsanitizer
--disable-bootstrap --target=vax-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220830 (experimental) (GCC) 

$ make
./xgcc -B./ -B/home/marxin/bin/gcc/vax-linux-gnu/bin/ -isystem
/home/marxin/bin/gcc/vax-linux-gnu/include -isystem
/home/marxin/bin/gcc/vax-linux-gnu/sys-include -L/dev/shm/objdir2/gcc/../ld 
-xc++ -nostdinc /dev/null -S -o /dev/null
-fself-test=/home/marxin/Programming/gcc/gcc/testsuite/selftests
/home/marxin/Programming/gcc/gcc/value-range.cc:3517: range_tests_nan: FAIL:
ASSERT_NE (r0, r1)
In function ‘test_fn’:
cc1plus: internal compiler error: in fail, at selftest.cc:47
0x25b888b selftest::fail(selftest::location const&, char const*)
        /home/marxin/Programming/gcc/gcc/selftest.cc:47
0x1b554b8 range_tests_nan
        /home/marxin/Programming/gcc/gcc/value-range.cc:3517
0x1b56020 range_tests_floats
        /home/marxin/Programming/gcc/gcc/value-range.cc:3581
0x1b5724c selftest::range_tests()
        /home/marxin/Programming/gcc/gcc/value-range.cc:3686
0x22efaca test_ranges
        /home/marxin/Programming/gcc/gcc/function-tests.cc:584
0x22f024f selftest::function_tests_cc_tests()
        /home/marxin/Programming/gcc/gcc/function-tests.cc:680
0x248ff92 selftest::run_tests()
        /home/marxin/Programming/gcc/gcc/selftest-run-tests.cc:107
0x16f87fa toplev::run_self_tests()
        /home/marxin/Programming/gcc/gcc/toplev.cc:2205
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [/home/marxin/Programming/gcc/gcc/cp/Make-lang.in:197:
s-selftest-c++] Error 1 shuffle=1661930953

[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 #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #0)
> Fails for the following cross compilers:
> pdp11-aout  rx-elf  vax-linux-gnu  vax-netbsdelf
> 
> $ ./xgcc -v
> Using built-in specs.
> COLLECT_GCC=./xgcc
> Target: vax-linux-gnu
> Configured with: /home/marxin/Programming/gcc/configure
> --enable-languages=c,c++ --prefix=/home/marxin/bin/gcc --disable-multilib
> --disable-libsanitizer --disable-bootstrap --target=vax-linux-gnu :
> (reconfigured) /home/marxin/Programming/gcc/configure
> --enable-languages=c,c++ --prefix=/home/marxin/bin/gcc --disable-multilib
> --disable-libsanitizer --disable-bootstrap --target=vax-linux-gnu
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 13.0.0 20220830 (experimental) (GCC) 
> 
> $ make
> ./xgcc -B./ -B/home/marxin/bin/gcc/vax-linux-gnu/bin/ -isystem
> /home/marxin/bin/gcc/vax-linux-gnu/include -isystem
> /home/marxin/bin/gcc/vax-linux-gnu/sys-include -L/dev/shm/objdir2/gcc/../ld 
> -xc++ -nostdinc /dev/null -S -o /dev/null
> -fself-test=/home/marxin/Programming/gcc/gcc/testsuite/selftests
> /home/marxin/Programming/gcc/gcc/value-range.cc:3517: range_tests_nan: FAIL:
> ASSERT_NE (r0, r1)
> In function ‘test_fn’:
> cc1plus: internal compiler error: in fail, at selftest.cc:47
> 0x25b888b selftest::fail(selftest::location const&, char const*)
> 	/home/marxin/Programming/gcc/gcc/selftest.cc:47
> 0x1b554b8 range_tests_nan
> 	/home/marxin/Programming/gcc/gcc/value-range.cc:3517

Huh.  Does the VAX have different NAN rules, or is HONOR_NANS off by default on
it?

Either way, could you attach the .i file from the selftests if you still have
the build handy?

[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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-08-31
           Assignee|unassigned at gcc dot gnu.org      |aldyh at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Nevermind, got it.

HONOR_NANS is off by default on VAX, and the tests assume NANs, which we drop
for all ranges per the upstream discussion.

Mine.

[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 #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 53523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53523&action=edit
untested patch

[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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
For !HONOR_NANS we know x >= 5.0 will not contain a NAN, but what about
explicit NANs in the code, for example the result of __builtin_nan?

Is [NAN, NAN] != [NAN, NAN] like we do for HONOR_NANS?

Are the following selftests applicable for !HONOR_NANS?

  // NAN U NAN = NAN
  // NAN ^ NAN = NAN
  // VARYING ^ NAN = NAN.

It would seem yes, but I'd like to make sure.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 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.

[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.

[Bug tree-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 #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
And how about __builtin_nan ("") == xxx ??

Is that undefined for !HONOR_NANS?  Can I continue treating it as false?

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, __builtin_nan ("") == xxx is always false even with
-fno-finite-math-only,
including NaN == NaN, that is how floating point equality comparisons are
defined.
But, e.g. with -ffinite-math-only, we fold __builtin_isinf (x) or
__builtin_isnan (x) to 0 (maybe with the exception if you use __builtin_nan
("") as its operand?; but that just shows that it is UB if NaNs or Infs can
appear at runtime).

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

https://gcc.gnu.org/g:bdfe0d1ce0aebdb68b77e2c04a0f45956c56b449

commit r13-2334-gbdfe0d1ce0aebdb68b77e2c04a0f45956c56b449
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Aug 31 14:31:12 2022 +0200

    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.

[Bug tree-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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> Well, __builtin_nan ("") == xxx is always false even with
> -fno-finite-math-only,
> including NaN == NaN, that is how floating point equality comparisons are
> defined.
> But, e.g. with -ffinite-math-only, we fold __builtin_isinf (x) or
> __builtin_isnan (x) to 0 (maybe with the exception if you use __builtin_nan
> ("") as its operand?; but that just shows that it is UB if NaNs or Infs can
> appear at runtime).

ok, we're good then.  That's how I understand things as well.