* [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
2023-11-30 18:54 [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
@ 2023-11-30 18:57 ` pinskia at gcc dot gnu.org
2023-12-01 7:23 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-11-30 18:57 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
2023-11-30 18:54 [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
2023-11-30 18:57 ` [Bug tree-optimization/112788] " pinskia at gcc dot gnu.org
@ 2023-12-01 7:23 ` rguenth at gcc dot gnu.org
2023-12-01 8:04 ` linkw at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-01 7:23 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
2023-11-30 18:54 [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
2023-11-30 18:57 ` [Bug tree-optimization/112788] " pinskia at gcc dot gnu.org
2023-12-01 7:23 ` rguenth at gcc dot gnu.org
@ 2023-12-01 8:04 ` linkw at gcc dot gnu.org
2023-12-01 19:15 ` amacleod at redhat dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-12-01 8:04 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
2023-11-30 18:54 [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
` (2 preceding siblings ...)
2023-12-01 8:04 ` linkw at gcc dot gnu.org
@ 2023-12-01 19:15 ` amacleod at redhat dot com
2023-12-03 13:28 ` tschwinge at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: amacleod at redhat dot com @ 2023-12-01 19:15 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
2023-11-30 18:54 [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
` (3 preceding siblings ...)
2023-12-01 19:15 ` amacleod at redhat dot com
@ 2023-12-03 13:28 ` tschwinge at gcc dot gnu.org
2023-12-04 1:52 ` linkw at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2023-12-03 13:28 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
2023-11-30 18:54 [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
` (4 preceding siblings ...)
2023-12-03 13:28 ` tschwinge at gcc dot gnu.org
@ 2023-12-04 1:52 ` linkw at gcc dot gnu.org
2023-12-07 8:43 ` linkw at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-12-04 1:52 UTC (permalink / raw)
To: gcc-bugs
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. :(
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
2023-11-30 18:54 [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
` (5 preceding siblings ...)
2023-12-04 1:52 ` linkw at gcc dot gnu.org
@ 2023-12-07 8:43 ` linkw at gcc dot gnu.org
2023-12-13 2:40 ` cvs-commit at gcc dot gnu.org
2023-12-13 2:43 ` linkw at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-12-07 8:43 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
2023-11-30 18:54 [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
` (6 preceding siblings ...)
2023-12-07 8:43 ` linkw at gcc dot gnu.org
@ 2023-12-13 2:40 ` cvs-commit at gcc dot gnu.org
2023-12-13 2:43 ` linkw at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-13 2:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
2023-11-30 18:54 [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
` (7 preceding siblings ...)
2023-12-13 2:40 ` cvs-commit at gcc dot gnu.org
@ 2023-12-13 2:43 ` linkw at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: linkw at gcc dot gnu.org @ 2023-12-13 2:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread