[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 via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Kewen Lin  ---
Should be fixed on latest trunk, we should get rid of this workaround in next
release, it will be tracked in PR112993.

[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 via Gcc-bugs]

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r14-6478-gfda8e2f8292a90dac9fcaf952bad6fff3aa7fff2
Author: Kewen Lin 
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-05a75e1fd...@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 via Gcc-bugs]

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

--- Comment #5 from Kewen Lin  ---
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

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  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  ---
(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

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  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  ---
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  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

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Macleod  ---
(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

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  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  ---
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-05a75e1fd...@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

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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