[Bug other/112788] New: [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[Bug other/112788] New: [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[seurer at gcc dot gnu.org]

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

            Bug ID: 112788
           Summary: [14 regression] ICEs in fold_range, at range-op.cc:206
                    after r14-5972-gea19de921b01a6
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:ea19de921b01a6ab470929f8da4dde526edb08f1, r14-5972-gea19de921b01a6
make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/float128-hw4.c"
FAIL: gcc.target/powerpc/float128-hw4.c (internal compiler error: in
fold_range, at range-op.cc:206)
FAIL: gcc.target/powerpc/float128-hw4.c (test for excess errors)
# of unexpected failures        2
# of unresolved testcases       16

Also:
FAIL: gcc.target/powerpc/pr82748-1.c (internal compiler error: in fold_range,
at range-op.cc:206)
FAIL: gcc.target/powerpc/pr82748-1.c (test for excess errors)


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/float128-hw4.c
-fdiagnostics-plain-output -mpower9-vector -O2 -mabi=ieeelongdouble -Wno-psabi
-ffat-lto-objects -fno-ident -S -o float128-hw4.s
during GIMPLE pass: evrp
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/float128-hw4.c:
In function 'nfma_odd':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/float128-hw4.c:119:1:
internal compiler error: in fold_range, at range-op.cc:206
0x10bb131b range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_trio) const
        /home/seurer/gcc/git/gcc-test/gcc/range-op.cc:206
0x11bfa13f fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
        /home/seurer/gcc/git/gcc-test/gcc/gimple-range-fold.cc:678
0x11bfb003 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
        /home/seurer/gcc/git/gcc-test/gcc/gimple-range-fold.cc:602
0x11bfb75b fold_range(vrange&, gimple*, range_query*)
        /home/seurer/gcc/git/gcc-test/gcc/gimple-range-fold.cc:322
0x11be4203 ranger_cache::get_global_range(vrange&, tree_node*, bool&)
        /home/seurer/gcc/git/gcc-test/gcc/gimple-range-cache.cc:1052
0x11bd5b97 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
        /home/seurer/gcc/git/gcc-test/gcc/gimple-range.cc:311
0x1119ba4f range_query::value_of_stmt(gimple*, tree_node*)
        /home/seurer/gcc/git/gcc-test/gcc/value-query.cc:113
0x1113f4ab rvrp_folder::value_of_stmt(gimple*, tree_node*)
        /home/seurer/gcc/git/gcc-test/gcc/tree-vrp.cc:999
0x10fbe62f
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
        /home/seurer/gcc/git/gcc-test/gcc/tree-ssa-propagate.cc:820
0x11b5514b dom_walker::walk(basic_block_def*)
        /home/seurer/gcc/git/gcc-test/gcc/domwalk.cc:311
0x10fbcd5b substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
        /home/seurer/gcc/git/gcc-test/gcc/tree-ssa-propagate.cc:999
0x1113a74b execute_ranger_vrp(function*, bool, bool)
        /home/seurer/gcc/git/gcc-test/gcc/tree-vrp.cc:1064


commit ea19de921b01a6ab470929f8da4dde526edb08f1 (HEAD)
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Tue Nov 28 09:39:30 2023 -0500

    Add operand_check_p to range-ops.

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|other                       |tree-optimization
   Target Milestone|---                         |14.0
           Keywords|                            |ice-on-valid-code

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |amacleod at redhat dot com
           Keywords|                            |ice-checking

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |linkw at gcc dot gnu.org,
                   |                            |meissner at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org
   Last reconfirmed|                            |2023-12-01

--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
Confirmed.

A reduced test case:

long double a, b, c;
long double d() { return -__builtin_fmaf128_round_to_odd(c, b, a); }

c.0_1 = c;
b.1_2 = b;
a.2_3 = a;
_4 = __builtin_fmaf128_round_to_odd (c.0_1, b.1_2, a.2_3);
_6 = -_4;
return _6;

 206├───> gcc_assert (m_operator->operand_check_p (type, lh.type (), rh.type
()));

stmt: _6 = -_4;

(gdb) pge lh.type()
_Float128
(gdb) pge rh.type()
long double

The root cause is the same to what's in PR107299, TYPE_PRECISION of rh.type is
127 while that of lh.type is 128, some attempts were tried to fix this
precision difference before but failed to, like:
https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com/.

ranger makes use of type precision directly instead of something like
types_compatible_p. I wonder if we can introduce a target hook (or hookpod) to
make ranger unrestrict this check a bit, the justification is that for float
type its precision information is encoded in its underlying real_format, if two
float types underlying modes are the same, the precision are actually the same. 

btw, the operand_check_ps seems able to call range_compatible_p?

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[amacleod at redhat dot com]

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

--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Kewen Lin from comment #1)

> 
> ranger makes use of type precision directly instead of something like
> types_compatible_p. I wonder if we can introduce a target hook (or hookpod)
> to make ranger unrestrict this check a bit, the justification is that for
> float type its precision information is encoded in its underlying
> real_format, if two float types underlying modes are the same, the precision
> are actually the same. 
> 
> btw, the operand_check_ps seems able to call range_compatible_p?

It could, but just a precision check seemed enough at the time.
The patch also went thru many iterations and it was only the final version that
operand_check_p() ended up with types as the parameter rather than ranges.

You bring up a good point tho. I just switched those routines to call
range_compatible_p() and checked it in.  Now it is all centralized in the one
routine going forward. 

It does seem wrong that the float precision don't match, and weird that its
hard to fix :-)   It should now be possible to have range_compatible_p check
the underlying mode for floats rather than the precision...  If there's a good
argument for it, and you want to give that a shot...

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2023-12-01 00:00:00         |2023-12-3
                 CC|                            |tschwinge at gcc dot gnu.org
           Keywords|                            |build

--- Comment #3 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
I'm actually running into this ICE already during powerpc64le-linux-gnu build:

    libtool: compile:  [...]/build-gcc/./gcc/xgcc [...] -fchecking=1 [...]
-mabi=ibmlongdouble -mno-gnu-attribute -fcx-fortran-rules -ffunction-sections
-fdata-sections -mabi=ieeelongdouble -g -O2 -MT norm2_r17.lo -MD -MP -MF
.deps/norm2_r17.Tpo -c [...]/source-gcc/libgfortran/generated/norm2_r17.c 
-fPIC -DPIC -o .libs/norm2_r17.o
    cc1: warning: Using IEEE extended precision ‘long double’ [-Wpsabi]
    during GIMPLE pass: evrp
    [...]/source-gcc/libgfortran/generated/norm2_r17.c: In function
‘norm2_r17’:
    [...]/source-gcc/libgfortran/generated/norm2_r17.c:214:1: internal compiler
error: in fold_range, at range-op.cc:206
      214 | }
          | ^
    0x10bf213b range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_trio) const
            [...]/source-gcc/gcc/range-op.cc:206
    0x11d8790b fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
            [...]/source-gcc/gcc/gimple-range-fold.cc:702
    0x11d89873 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
            [...]/source-gcc/gcc/gimple-range-fold.cc:602
    0x11d89eaf fold_range(vrange&, gimple*, range_query*)
            [...]/source-gcc/gcc/gimple-range-fold.cc:322
    0x11d7c6e3 ranger_cache::get_global_range(vrange&, tree_node*, bool&)
            [...]/source-gcc/gcc/gimple-range-cache.cc:1052
    0x11d69577 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
            [...]/source-gcc/gcc/gimple-range.cc:311
    0x11221b93 range_query::value_of_stmt(gimple*, tree_node*)
            [...]/source-gcc/gcc/value-query.cc:113
    0x111c6ae7 rvrp_folder::value_of_stmt(gimple*, tree_node*)
            [...]/source-gcc/gcc/tree-vrp.cc:999
    0x11044fbb
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
            [...]/source-gcc/gcc/tree-ssa-propagate.cc:820
    0x11ce966b dom_walker::walk(basic_block_def*)
            [...]/source-gcc/gcc/domwalk.cc:311
    0x110436f3
substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
            [...]/source-gcc/gcc/tree-ssa-propagate.cc:999
    0x111c1877 execute_ranger_vrp(function*, bool, bool)
            [...]/source-gcc/gcc/tree-vrp.cc:1064
    0x111c6a6b execute
            [...]/source-gcc/gcc/tree-vrp.cc:1307
    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[3]: *** [norm2_r17.lo] Error 1

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2023-12-03 00:00:00         |2023-12-01 0:00

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #2)
> (In reply to Kewen Lin from comment #1)
> 
> > 
> > ranger makes use of type precision directly instead of something like
> > types_compatible_p. I wonder if we can introduce a target hook (or hookpod)
> > to make ranger unrestrict this check a bit, the justification is that for
> > float type its precision information is encoded in its underlying
> > real_format, if two float types underlying modes are the same, the precision
> > are actually the same. 
> > 
> > btw, the operand_check_ps seems able to call range_compatible_p?
> 
> It could, but just a precision check seemed enough at the time.
> The patch also went thru many iterations and it was only the final version
> that operand_check_p() ended up with types as the parameter rather than
> ranges.
> 
> You bring up a good point tho. I just switched those routines to call
> range_compatible_p() and checked it in.  Now it is all centralized in the
> one routine going forward. 

Nice! Thanks a lot for your prompt enhancement!

>  
> It does seem wrong that the float precision don't match, and weird that its
> hard to fix :-)   

Yes, I dislike it and thought it's not sensible and tried to fix, but as the
discussion in the thread mentioned above showed there were some historical
reasons and practical issues to fix it. At the time, Segher mentioned he had
some patches to avoid different modes having the same format but encountered
some issues before and would have a re-try, but now stage 1 passed again, I
guessed we have to stay with it in this release.

> It should now be possible to have range_compatible_p check
> the underlying mode for floats rather than the precision...  If there's a
> good argument for it, and you want to give that a shot...

I have to admit this idea is just a workaround, even the actual float precision
is encoded in the format associated to the underlying mode, but it's still
unexpected to have two types with the same underlying mode but different type
precision. I'm going to make and test a workaround patch since it affected the
build again as reported. :(

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[linkw at gcc dot gnu.org]

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

--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
One workaround patch was posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639140.html.

We also found that with default long double format ieee128 the culprit commit
caused the libquadmath library isn't able to be built on a system with ieee128
libs, consequently there are a lot of fortran testing failures.

The workaround also fixed some failures which existed there previously:

UNRESOLVED->NA: 20_util/from_chars/8.cc  -std=gnu++23 compilation failed to
produce executable
NA->PASS: 20_util/from_chars/8.cc  -std=gnu++23 execution test
FAIL->PASS: 20_util/from_chars/8.cc  -std=gnu++23 (test for excess errors)
UNRESOLVED->NA: 20_util/from_chars/8.cc  -std=gnu++26 compilation failed to
produce executable
NA->PASS: 20_util/from_chars/8.cc  -std=gnu++26 execution test
FAIL->PASS: 20_util/from_chars/8.cc  -std=gnu++26 (test for excess errors)
UNRESOLVED->NA: 20_util/to_chars/float128_c++23.cc  -std=gnu++23 compilation
failed to produce executable
NA->PASS: 20_util/to_chars/float128_c++23.cc  -std=gnu++23 execution test
FAIL->PASS: 20_util/to_chars/float128_c++23.cc  -std=gnu++23 (test for excess
errors)
UNRESOLVED->NA: 20_util/to_chars/float128_c++23.cc  -std=gnu++26 compilation
failed to produce executable
NA->PASS: 20_util/to_chars/float128_c++23.cc  -std=gnu++26 execution test
FAIL->PASS: 20_util/to_chars/float128_c++23.cc  -std=gnu++26 (test for excess
errors)

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

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

commit r14-6478-gfda8e2f8292a90dac9fcaf952bad6fff3aa7fff2
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Tue Dec 12 20:39:34 2023 -0600

    range: Workaround different type precision between _Float128 and long
double [PR112788]

    As PR112788 shows, on rs6000 with -mabi=ieeelongdouble type _Float128
    has the different type precision (128) from that (127) of type long
    double, but actually they has the same underlying mode, so they have
    the same precision as the mode indicates the same real type format
    ieee_quad_format.

    It's not sensible to have such two types which have the same mode but
    different type precisions, some fix attempt was posted at [1].
    As the discussion there, there are some historical reasons and
    practical issues.  Considering we passed stage 1 and it also affected
    the build as reported, this patch is trying to temporarily workaround
    it.  I thought to introduce a hookpod but that seems a bit overkill,
    assuming scalar float type with the same mode should have the same
    precision looks sensible.

    [1]
https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com/

            PR tree-optimization/112788

    gcc/ChangeLog:

            * value-range.h (range_compatible_p): Workaround same type mode but
            different type precision issue for rs6000 scalar float types
            _Float128 and long double.

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

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

--- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> ---
Should be fixed on latest trunk, we should get rid of this workaround in next
release, it will be tracked in PR112993.