* [Bug tree-optimization/97360] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
@ 2020-10-11 22:07 ` msebor at gcc dot gnu.org
2020-10-12 6:23 ` [Bug tree-optimization/97360] [11 Regression] " rguenth at gcc dot gnu.org
` (38 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: msebor at gcc dot gnu.org @ 2020-10-11 22:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |aldyh at gcc dot gnu.org,
| |msebor at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed| |2020-10-11
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
Confirmed in an instrumented x86_64-linux Binutils/GDB build (the note is from
the instrumentation):
/src/binutils-gdb/bfd/elf32-arc.c:3160: internal compiler error: in
range_on_exit, at gimple-range.cc:931
mv -f .deps/coff-sh.Tpo .deps/coff-sh.Plo
/bin/sh ./libtool --tag=CC --mode=compile /build/gcc-master/gcc/xgcc -B
/build/gcc-master/gcc -DHAVE_CONFIG_H -I. -I/src/binutils-gdb/bfd
-DBINDIR='"/usr/local/bin"' -DLIBDIR='"/usr/local/lib"' -I.
-I/src/binutils-gdb/bfd -I/src/binutils-gdb/bfd/../include -DHAVE_all_vecs
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
-I/src/binutils-gdb/bfd/../zlib -g -O2 -MT elf32-bfin.lo -MD -MP -MF
.deps/elf32-bfin.Tpo -c -o elf32-bfin.lo /src/binutils-gdb/bfd/elf32-bfin.c
libtool: compile: /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc
-DHAVE_CONFIG_H -I. -I/src/binutils-gdb/bfd -DBINDIR=\"/usr/local/bin\"
-DLIBDIR=\"/usr/local/lib\" -I. -I/src/binutils-gdb/bfd
-I/src/binutils-gdb/bfd/../include -DHAVE_all_vecs -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wshadow -Wstack-usage=262144
-I/src/binutils-gdb/bfd/../zlib -g -O2 -MT elf32-bfin.lo -MD -MP -MF
.deps/elf32-bfin.Tpo -c /src/binutils-gdb/bfd/elf32-bfin.c -o elf32-bfin.o
/src/binutils-gdb/bfd/ecofflink.c: In function ‘bfd_ecoff_debug_one_external’:
/src/binutils-gdb/bfd/ecofflink.c:1314:3: note: ‘<unknown>’: VR_VARYING
1314 | strcpy (debug->ssext + symhdr->issExtMax, name);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x24eb947 gimple_ranger::range_on_exit(irange&, basic_block_def*, tree_node*)
/src/gcc/master/gcc/gimple-range.cc:930
0x24eba6e gimple_ranger::range_on_edge(irange&, edge_def*, tree_node*)
/src/gcc/master/gcc/gimple-range.cc:949
0x17d35ee range_query::value_on_edge(edge_def*, tree_node*)
/src/gcc/master/gcc/value-query.cc:98
0x22cf6d4 hybrid_folder::value_on_edge(edge_def*, tree_node*)
/src/gcc/master/gcc/gimple-ssa-evrp.c:243
0x15cb023 substitute_and_fold_engine::propagate_into_phi_args(basic_block_def*)
/src/gcc/master/gcc/tree-ssa-propagate.c:1038
0x15cbb16 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/src/gcc/master/gcc/tree-ssa-propagate.c:1238
0x22789b9 dom_walker::walk(basic_block_def*)
/src/gcc/master/gcc/domwalk.c:309
0x15cbc37 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/src/gcc/master/gcc/tree-ssa-propagate.c:1283
0x22cf9ed execute_early_vrp
/src/gcc/master/gcc/gimple-ssa-evrp.c:334
0x22cfafa execute
/src/gcc/master/gcc/gimple-ssa-evrp.c:381
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[4]: *** [Makefile:1600: elf32-arc.lo] Error 1
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
2020-10-11 22:07 ` [Bug tree-optimization/97360] " msebor at gcc dot gnu.org
@ 2020-10-12 6:23 ` rguenth at gcc dot gnu.org
2020-10-12 7:42 ` marxin at gcc dot gnu.org
` (37 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-10-12 6:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.0
Summary|ICE in range_on_exit |[11 Regression] ICE in
| |range_on_exit
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
2020-10-11 22:07 ` [Bug tree-optimization/97360] " msebor at gcc dot gnu.org
2020-10-12 6:23 ` [Bug tree-optimization/97360] [11 Regression] " rguenth at gcc dot gnu.org
@ 2020-10-12 7:42 ` marxin at gcc dot gnu.org
2020-10-12 8:02 ` amodra at gmail dot com
` (36 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-10-12 7:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marxin at gcc dot gnu.org
Status|NEW |WAITING
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Can please anybody attach a pre-processed source file so that we can reduce it?
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (2 preceding siblings ...)
2020-10-12 7:42 ` marxin at gcc dot gnu.org
@ 2020-10-12 8:02 ` amodra at gmail dot com
2020-10-12 8:06 ` amodra at gmail dot com
` (35 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amodra at gmail dot com @ 2020-10-12 8:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #3 from Alan Modra <amodra at gmail dot com> ---
Created attachment 49346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49346&action=edit
reduced testcase
-mcpu=power10 -O2 -S
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (3 preceding siblings ...)
2020-10-12 8:02 ` amodra at gmail dot com
@ 2020-10-12 8:06 ` amodra at gmail dot com
2020-10-12 8:23 ` marxin at gcc dot gnu.org
` (34 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amodra at gmail dot com @ 2020-10-12 8:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
Created attachment 49347
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49347&action=edit
original .i
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (4 preceding siblings ...)
2020-10-12 8:06 ` amodra at gmail dot com
@ 2020-10-12 8:23 ` marxin at gcc dot gnu.org
2020-10-12 9:28 ` aldyh at gcc dot gnu.org
` (33 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-10-12 8:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
Status|WAITING |NEW
--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed:
$ cat pr97360.i
void
MMA_m() {
__vector_quad acc7;
for (;;) {
__attribute__((__vector_size__(16))) unsigned char *rowA;
__vector_pair rowB;
__builtin_mma_xvf64gerpp(&acc7, rowB, rowA[7]);
}
}
$ /home/marxin/Programming/gcc2/objdir/gcc/xgcc
-B/home/marxin/Programming/gcc2/objdir/gcc/ -O2 pr97360.i -c -mcpu=power10
during GIMPLE pass: evrp
pr97360.i: In function ‘MMA_m’:
pr97360.i:9:1: internal compiler error: in range_on_exit, at
gimple-range.cc:930
9 | }
| ^
0x93c679 gimple_ranger::range_on_exit(irange&, basic_block_def*, tree_node*)
/home/marxin/Programming/gcc2/gcc/gimple-range.cc:930
0x1e735db gimple_ranger::range_on_edge(irange&, edge_def*, tree_node*)
/home/marxin/Programming/gcc2/gcc/gimple-range.cc:949
0x14d70e6 range_query::value_on_edge(edge_def*, tree_node*)
/home/marxin/Programming/gcc2/gcc/value-query.cc:98
0x1c9866e hybrid_folder::value_on_edge(edge_def*, tree_node*)
/home/marxin/Programming/gcc2/gcc/gimple-ssa-evrp.c:243
0x13029b5 substitute_and_fold_engine::propagate_into_phi_args(basic_block_def*)
/home/marxin/Programming/gcc2/gcc/tree-ssa-propagate.c:1038
0x13034c4 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/home/marxin/Programming/gcc2/gcc/tree-ssa-propagate.c:1238
0x1c6fd37 dom_walker::walk(basic_block_def*)
/home/marxin/Programming/gcc2/gcc/domwalk.c:309
0x13035ed substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/home/marxin/Programming/gcc2/gcc/tree-ssa-propagate.c:1283
0x1c98286 execute_early_vrp
/home/marxin/Programming/gcc2/gcc/gimple-ssa-evrp.c:340
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (5 preceding siblings ...)
2020-10-12 8:23 ` marxin at gcc dot gnu.org
@ 2020-10-12 9:28 ` aldyh at gcc dot gnu.org
2020-10-12 23:42 ` amodra at gmail dot com
` (32 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: aldyh at gcc dot gnu.org @ 2020-10-12 9:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
It looks like the type of acc7 is __vector_quad, but the type of
TYPE_{MIN,MAX}_VALUE is something entirely different:
(gdb) ptg name
acc7_7(D)
(gdb) p name.typed.type
$20 = <integer_type 0x7ffff0e02d20 __vector_quad>
(gdb) p debug_generic_stmt ($18.type_non_common.maxval.typed.type)
uint512_t
And surprisingly, these types are incompatible with each other:
(gdb) p types_compatible_p ($18.type_non_common.maxval.typed.type,
name.typed.type)
$26 = false
How can the end points of a type be (a) of a different type than the type
itself (b) incompatible with the type itself.
Is this a peculiarity of these quad types, or is this a target bug?
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (6 preceding siblings ...)
2020-10-12 9:28 ` aldyh at gcc dot gnu.org
@ 2020-10-12 23:42 ` amodra at gmail dot com
2020-10-15 6:50 ` amodra at gmail dot com
` (31 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amodra at gmail dot com @ 2020-10-12 23:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bergner at gcc dot gnu.org,
| |meissner at gcc dot gnu.org
--- Comment #7 from Alan Modra <amodra at gmail dot com> ---
(In reply to Aldy Hernandez from comment #6)
> How can the end points of a type be (a) of a different type than the type
> itself (b) incompatible with the type itself.
>
> Is this a peculiarity of these quad types, or is this a target bug?
These are PXI and XI mode 512-bit integers. See comment #0. PXI is a partial
integer mode, which is likely why they aren't types_compatible_p. I have no
idea whether this is a target bug or something that should be handled by the
target-independent code.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (7 preceding siblings ...)
2020-10-12 23:42 ` amodra at gmail dot com
@ 2020-10-15 6:50 ` amodra at gmail dot com
2020-10-15 8:51 ` marxin at gcc dot gnu.org
` (30 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amodra at gmail dot com @ 2020-10-15 6:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |powerpc64le-linux,
| |x86_64-linux
Status|WAITING |NEW
--- Comment #8 from Alan Modra <amodra at gmail dot com> ---
Note that the error reported in comment #1 is on x86_64-linux.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (8 preceding siblings ...)
2020-10-15 6:50 ` amodra at gmail dot com
@ 2020-10-15 8:51 ` marxin at gcc dot gnu.org
2020-10-15 12:14 ` amodra at gmail dot com
` (29 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-10-15 8:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #8)
> Note that the error reported in comment #1 is on x86_64-linux.
So please provide one more test-case which can be reproduced on
x86_64-linux-gnu.
Thanks.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (9 preceding siblings ...)
2020-10-15 8:51 ` marxin at gcc dot gnu.org
@ 2020-10-15 12:14 ` amodra at gmail dot com
2020-10-15 14:09 ` amacleod at redhat dot com
` (28 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amodra at gmail dot com @ 2020-10-15 12:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #10 from Alan Modra <amodra at gmail dot com> ---
Here's elf32-arc.i creduced.
a;
b();
c() {
void *d;
if (d == b && e())
d = a;
return d;
}
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (10 preceding siblings ...)
2020-10-15 12:14 ` amodra at gmail dot com
@ 2020-10-15 14:09 ` amacleod at redhat dot com
2020-10-16 12:17 ` rguenth at gcc dot gnu.org
` (27 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amacleod at redhat dot com @ 2020-10-15 14:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Alan Modra from comment #10)
> Here's elf32-arc.i creduced.
>
> a;
> b();
> c() {
> void *d;
> if (d == b && e())
is that actually allowed?
if (d == b) is
void * == (void * ())
I was under the impression that void * and pointers to functions were not
compatible? I notice we don't issue a warning, and let it go tho.
The problem is "different" than the original problem. yes, they trigger in
the same place, but this is a comparison of !types_compatible_p() which I
didn't think was allowed without a cast?
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (11 preceding siblings ...)
2020-10-15 14:09 ` amacleod at redhat dot com
@ 2020-10-16 12:17 ` rguenth at gcc dot gnu.org
2020-10-16 13:38 ` amacleod at redhat dot com
` (26 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-10-16 12:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
CC| |rguenth at gcc dot gnu.org
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
See verify_gimple_comparison for what GIMPLE allows [to slip through]:
/* For comparisons we do not have the operations type as the
effective type the comparison is carried out in. Instead
we require that either the first operand is trivially
convertible into the second, or the other way around.
Because we special-case pointers to void we allow
comparisons of pointers with the same mode as well. */
if (!useless_type_conversion_p (op0_type, op1_type)
&& !useless_type_conversion_p (op1_type, op0_type)
&& (!POINTER_TYPE_P (op0_type)
|| !POINTER_TYPE_P (op1_type)
|| TYPE_MODE (op0_type) != TYPE_MODE (op1_type)))
{
so this is the two pointers, same mode "exception". I don't see the void *
special-casing anymore though. That means removing the exception above
and fixing the fallout might be the way to go. I guess FEs are in the
end responsible for the above.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (12 preceding siblings ...)
2020-10-16 12:17 ` rguenth at gcc dot gnu.org
@ 2020-10-16 13:38 ` amacleod at redhat dot com
2020-10-16 13:48 ` rguenth at gcc dot gnu.org
` (25 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amacleod at redhat dot com @ 2020-10-16 13:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #13 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 49386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49386&action=edit
Patch to create integral MAX and MiN
Joy. I'll try it and see what happens.
And back to the first problem where the MIN and MAXs are not the right type. I
found this nugget in tree.c::build_distinct_type_copy ()
/* Note that it is now possible for TYPE_MIN_VALUE to be a value
whose TREE_TYPE is not t. This can also happen in the Ada
frontend when using subtypes. */
What? That seems ridiculous, especially for types that are now distinct.
Why on earth don't we create new MIN and MAX values for the type?
I'm trying the attached patch which at least corrects it for integral types..
and does resolve the compilation failure.
Is this the correct way to resolve this, or am I missing something else?
+ if (INTEGRAL_TYPE_P (type))
+ {
+ TYPE_MIN_VALUE (t)= wide_int_to_tree (t, wi::to_wide (TYPE_MIN_VALUE
(type)));
+ TYPE_MAX_VALUE (t)= wide_int_to_tree (t, wi::to_wide (TYPE_MAX_VALUE
(type)));
+ }
+
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (13 preceding siblings ...)
2020-10-16 13:38 ` amacleod at redhat dot com
@ 2020-10-16 13:48 ` rguenth at gcc dot gnu.org
2020-10-16 13:55 ` amacleod at redhat dot com
` (24 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-10-16 13:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
But that's just a waste of memory ... the expectation that the min/max values
are of the same type is simply wrong.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (14 preceding siblings ...)
2020-10-16 13:48 ` rguenth at gcc dot gnu.org
@ 2020-10-16 13:55 ` amacleod at redhat dot com
2020-10-16 13:58 ` rguenther at suse dot de
` (23 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amacleod at redhat dot com @ 2020-10-16 13:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #15 from Andrew Macleod <amacleod at redhat dot com> ---
Well it seems far more incorrect that types_compatible_p () is FALSE for a type
and its MIN/MAX value?
Whats the point of MIN/MAX if you cant count on them being the right types, or
at least conmpatible.
And why can we not make that expectation? it seems more natural and wouldn't
require a special comment buried back in a build_* routine indicating that
something non-obvious may now be true.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (15 preceding siblings ...)
2020-10-16 13:55 ` amacleod at redhat dot com
@ 2020-10-16 13:58 ` rguenther at suse dot de
2020-10-16 14:17 ` amacleod at redhat dot com
` (22 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenther at suse dot de @ 2020-10-16 13:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 16 Oct 2020, amacleod at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
> --- Comment #15 from Andrew Macleod <amacleod at redhat dot com> ---
> Well it seems far more incorrect that types_compatible_p () is FALSE for a type
> and its MIN/MAX value?
But then this (types_compatible_p () is FALSE) is not going to be fixed
by the patch - or at least the type that was copied retains the issue.
So it's certainly the wrong place to fix.
Note that for integer subtypes generated by Ada the min/max values
are in the "parent" type. Usually the types are compatible though
(same precision and signedness).
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (16 preceding siblings ...)
2020-10-16 13:58 ` rguenther at suse dot de
@ 2020-10-16 14:17 ` amacleod at redhat dot com
2020-10-16 15:02 ` rguenther at suse dot de
` (21 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amacleod at redhat dot com @ 2020-10-16 14:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #17 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to rguenther@suse.de from comment #16)
> On Fri, 16 Oct 2020, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
> >
> > --- Comment #15 from Andrew Macleod <amacleod at redhat dot com> ---
> > Well it seems far more incorrect that types_compatible_p () is FALSE for a type
> > and its MIN/MAX value?
>
> But then this (types_compatible_p () is FALSE) is not going to be fixed
> by the patch - or at least the type that was copied retains the issue.
> So it's certainly the wrong place to fix.
Why doesn't it? it creates new min and maxs based from the old wide_ints, only
with the new type. So it'll be the correct mina dn max, with the corect type
set? It now passes the types_compatible_p() test in the testcase.. because
they are the same type instead of the old type.
Its not an interaction between the old type and the new that is at issue, its
interaction between the new type and its MIN/MAX values when we are type
checking something created from the MIN/MAX.
>
> Note that for integer subtypes generated by Ada the min/max values
> are in the "parent" type. Usually the types are compatible though
> (same precision and signedness).
Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on the powerpc
target.. so far the only place I have seen this issue.
tree xi_uns_type = make_unsigned_type (512);
vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
SET_TYPE_MODE (vector_quad_type_node, PXImode);
layout_type (vector_quad_type_node);
lang_hooks.types.register_builtin_type (vector_quad_type_node,
"__vector_quad")
The vector_quad ends up with MAX and MIN set to the uint512_t type, which is
not types_compatible_p...
Perhaps the type should be created some other way rather than distinct_type?
Im starting to wonder if I should stop trying to assert type correctness when
processing ranges since our type "system" has too many tweaky inconsistencies
that we continue to trip over.
Instead, just make sure precision and sign are the same and "trust" gimple to
be right otherwise.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (17 preceding siblings ...)
2020-10-16 14:17 ` amacleod at redhat dot com
@ 2020-10-16 15:02 ` rguenther at suse dot de
2020-10-16 15:46 ` amacleod at redhat dot com
` (20 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenther at suse dot de @ 2020-10-16 15:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
>--- Comment #17 from Andrew Macleod <amacleod at redhat dot com> ---
>(In reply to rguenther@suse.de from comment #16)
>> On Fri, 16 Oct 2020, amacleod at redhat dot com wrote:
>>
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>> >
>> > --- Comment #15 from Andrew Macleod <amacleod at redhat dot com>
>---
>> > Well it seems far more incorrect that types_compatible_p () is
>FALSE for a type
>> > and its MIN/MAX value?
>>
>> But then this (types_compatible_p () is FALSE) is not going to be
>fixed
>> by the patch - or at least the type that was copied retains the
>issue.
>> So it's certainly the wrong place to fix.
>
>Why doesn't it? it creates new min and maxs based from the old
>wide_ints, only
>with the new type. So it'll be the correct mina dn max, with the corect
>type
>set? It now passes the types_compatible_p() test in the testcase..
>because
>they are the same type instead of the old type.
>
>Its not an interaction between the old type and the new that is at
>issue, its
>interaction between the new type and its MIN/MAX values when we are
>type
>checking something created from the MIN/MAX.
>
>
>>
>> Note that for integer subtypes generated by Ada the min/max values
>> are in the "parent" type. Usually the types are compatible though
>> (same precision and signedness).
>
>Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on the
>powerpc
>target.. so far the only place I have seen this issue.
>
> tree xi_uns_type = make_unsigned_type (512);
> vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> SET_TYPE_MODE (vector_quad_type_node, PXImode);
> layout_type (vector_quad_type_node);
Why not put the fix here instead of in build distinct type copy??
lang_hooks.types.register_builtin_type (vector_quad_type_node,
> "__vector_quad")
>
>The vector_quad ends up with MAX and MIN set to the uint512_t type,
>which is
>not types_compatible_p...
>Perhaps the type should be created some other way rather than
>distinct_type?
Quite sure.
>
>Im starting to wonder if I should stop trying to assert type
>correctness when
>processing ranges since our type "system" has too many tweaky
>inconsistencies
>that we continue to trip over.
>
>Instead, just make sure precision and sign are the same and "trust"
>gimple to
>be right otherwise.
If precision and sign are the same then types_compatible_p will return true.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (18 preceding siblings ...)
2020-10-16 15:02 ` rguenther at suse dot de
@ 2020-10-16 15:46 ` amacleod at redhat dot com
2020-10-16 16:55 ` rguenther at suse dot de
` (19 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amacleod at redhat dot com @ 2020-10-16 15:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #19 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to rguenther@suse.de from comment #18)
> On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com
>
> >
> >Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on the
> >powerpc
> >target.. so far the only place I have seen this issue.
> >
> > tree xi_uns_type = make_unsigned_type (512);
> > vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> > SET_TYPE_MODE (vector_quad_type_node, PXImode);
^^^^^^^^^^^^^^
This is why types_compatible_p() fails. before checking sign and precision
matching, it does:
inner_type = TYPE_MAIN_VARIANT (inner_type);
outer_type = TYPE_MAIN_VARIANT (outer_type);
if (inner_type == outer_type)
return true;
/* Changes in machine mode are never useless conversions because the RTL
middle-end expects explicit conversions between modes. */
if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type))
return false;
and since the modes are now different, it never gets to check the sign and
precision.... (which do match).
> > layout_type (vector_quad_type_node);
>
> Why not put the fix here instead of in build distinct type copy??
>
> lang_hooks.types.register_builtin_type (vector_quad_type_node,
> > "__vector_quad")
> >
> >The vector_quad ends up with MAX and MIN set to the uint512_t type,
> >which is
> >not types_compatible_p...
> >Perhaps the type should be created some other way rather than
> >distinct_type?
>
> Quite sure.
I could fix it right there... but it wont prevent something similar from
happening elsewhere. Anyone changing the mode of the new distinct type will
continue to allow types_incompatible_p() types for MIN and MAX.
Maybe its not a big deal, but it just seems like a glaring inconsistency to me.
If you ask for distinct type, you should get one, complete with distinct
elements so you don't need to worry about things like this.
It doesn't seem like powerpc is doing anything wrong, but they are getting an
inconsistent type back due to the way types_compatible_p checks things.
Now, looking further into it, this would appear to be the only 2 places in all
the architectures where build_distinct_type_copy() is called, and then the mode
is changed. All the other places build a type then set the mode rather than
getting a copy.
I'd still prefer to fix it at its source, but given the lack of prevalence, I
could just set the MIN MAX properly here where these 2 types are having their
mode changed.
Is this your preferred solution?
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 9fdf97bc803..1fcb438ef95 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -12917,6 +12917,13 @@ rs6000_init_builtins (void)
tree oi_uns_type = make_unsigned_type (256);
vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
SET_TYPE_MODE (vector_pair_type_node, POImode);
+ // Changing modes makes the types incompatable.
+ TYPE_MIN_VALUE (vector_pair_type_node)
+ = wide_int_to_tree (vector_pair_type_node,
+ wi::to_wide (TYPE_MIN_VALUE (oi_uns_type)));
+ TYPE_MAX_VALUE (vector_pair_type_node)
+ = wide_int_to_tree (vector_pair_type_node,
+ wi::to_wide (TYPE_MAX_VALUE (oi_uns_type)));
layout_type (vector_pair_type_node);
lang_hooks.types.register_builtin_type (vector_pair_type_node,
"__vector_pair");
@@ -12924,6 +12931,13 @@ rs6000_init_builtins (void)
tree xi_uns_type = make_unsigned_type (512);
vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
SET_TYPE_MODE (vector_quad_type_node, PXImode);
+ // Changing modes makes the types incompatable.
+ TYPE_MIN_VALUE (vector_quad_type_node)
+ = wide_int_to_tree (vector_quad_type_node,
+ wi::to_wide (TYPE_MIN_VALUE (xi_uns_type)));
+ TYPE_MAX_VALUE (vector_quad_type_node)
+ = wide_int_to_tree (vector_quad_type_node,
+ wi::to_wide (TYPE_MAX_VALUE (xi_uns_type)));
layout_type (vector_quad_type_node);
lang_hooks.types.register_builtin_type (vector_quad_type_node,
"__vector_quad");
.
>
> >
> >Im starting to wonder if I should stop trying to assert type
> >correctness when
> >processing ranges since our type "system" has too many tweaky
> >inconsistencies
> >that we continue to trip over.
> >
> >Instead, just make sure precision and sign are the same and "trust"
> >gimple to
> >be right otherwise.
>
> If precision and sign are the same then types_compatible_p will return true.
except in cases like this :-P
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (19 preceding siblings ...)
2020-10-16 15:46 ` amacleod at redhat dot com
@ 2020-10-16 16:55 ` rguenther at suse dot de
2020-10-16 17:00 ` amacleod at redhat dot com
` (18 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenther at suse dot de @ 2020-10-16 16:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On October 16, 2020 5:46:28 PM GMT+02:00, amacleod at redhat dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
>--- Comment #19 from Andrew Macleod <amacleod at redhat dot com> ---
>(In reply to rguenther@suse.de from comment #18)
>> On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com
>>
>> >
>> >Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on
>the
>> >powerpc
>> >target.. so far the only place I have seen this issue.
>> >
>> > tree xi_uns_type = make_unsigned_type (512);
>> > vector_quad_type_node = build_distinct_type_copy
>(xi_uns_type);
>> > SET_TYPE_MODE (vector_quad_type_node, PXImode);
> ^^^^^^^^^^^^^^
>
>This is why types_compatible_p() fails. before checking sign and
>precision
>matching, it does:
>
> inner_type = TYPE_MAIN_VARIANT (inner_type);
> outer_type = TYPE_MAIN_VARIANT (outer_type);
>
> if (inner_type == outer_type)
> return true;
>
>/* Changes in machine mode are never useless conversions because the
>RTL
> middle-end expects explicit conversions between modes. */
> if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type))
> return false;
>
>and since the modes are now different, it never gets to check the sign
>and
>precision.... (which do match).
>
>
>
>> > layout_type (vector_quad_type_node);
>>
>> Why not put the fix here instead of in build distinct type copy??
>>
>> lang_hooks.types.register_builtin_type (vector_quad_type_node,
>> > "__vector_quad")
>> >
>> >The vector_quad ends up with MAX and MIN set to the uint512_t type,
>> >which is
>> >not types_compatible_p...
>> >Perhaps the type should be created some other way rather than
>> >distinct_type?
>>
>> Quite sure.
>
>
>I could fix it right there... but it wont prevent something similar
>from
>happening elsewhere. Anyone changing the mode of the new distinct type
>will
>continue to allow types_incompatible_p() types for MIN and MAX.
>
>Maybe its not a big deal, but it just seems like a glaring
>inconsistency to me.
>If you ask for distinct type, you should get one, complete with
>distinct
>elements so you don't need to worry about things like this.
>
>It doesn't seem like powerpc is doing anything wrong, but they are
>getting an
>inconsistent type back due to the way types_compatible_p checks things.
>
>Now, looking further into it, this would appear to be the only 2 places
>in all
>the architectures where build_distinct_type_copy() is called, and then
>the mode
>is changed. All the other places build a type then set the mode
>rather than
>getting a copy.
>
>I'd still prefer to fix it at its source, but given the lack of
>prevalence, I
>could just set the MIN MAX properly here where these 2 types are having
>their
>mode changed.
>
>Is this your preferred solution?
The backen should use more lowlevel functions to build this type rather than
copying from a type that isn't appropriate. Off my head it wants
fixup_unsigned_type after setting the mode and eventually a different function
to build the original type. See tree.c where we build for example
boolean_type_node
>diff --git a/gcc/config/rs6000/rs6000-call.c
>b/gcc/config/rs6000/rs6000-call.c
>index 9fdf97bc803..1fcb438ef95 100644
>--- a/gcc/config/rs6000/rs6000-call.c
>+++ b/gcc/config/rs6000/rs6000-call.c
>@@ -12917,6 +12917,13 @@ rs6000_init_builtins (void)
> tree oi_uns_type = make_unsigned_type (256);
> vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> SET_TYPE_MODE (vector_pair_type_node, POImode);
>+ // Changing modes makes the types incompatable.
>+ TYPE_MIN_VALUE (vector_pair_type_node)
>+ = wide_int_to_tree (vector_pair_type_node,
>+ wi::to_wide (TYPE_MIN_VALUE
>(oi_uns_type)));
>+ TYPE_MAX_VALUE (vector_pair_type_node)
>+ = wide_int_to_tree (vector_pair_type_node,
>+ wi::to_wide (TYPE_MAX_VALUE
>(oi_uns_type)));
> layout_type (vector_pair_type_node);
> lang_hooks.types.register_builtin_type (vector_pair_type_node,
> "__vector_pair");
>@@ -12924,6 +12931,13 @@ rs6000_init_builtins (void)
> tree xi_uns_type = make_unsigned_type (512);
> vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> SET_TYPE_MODE (vector_quad_type_node, PXImode);
>+ // Changing modes makes the types incompatable.
>+ TYPE_MIN_VALUE (vector_quad_type_node)
>+ = wide_int_to_tree (vector_quad_type_node,
>+ wi::to_wide (TYPE_MIN_VALUE
>(xi_uns_type)));
>+ TYPE_MAX_VALUE (vector_quad_type_node)
>+ = wide_int_to_tree (vector_quad_type_node,
>+ wi::to_wide (TYPE_MAX_VALUE
>(xi_uns_type)));
> layout_type (vector_quad_type_node);
> lang_hooks.types.register_builtin_type (vector_quad_type_node,
> "__vector_quad");
>
>.
>
>
>>
>> >
>> >Im starting to wonder if I should stop trying to assert type
>> >correctness when
>> >processing ranges since our type "system" has too many tweaky
>> >inconsistencies
>> >that we continue to trip over.
>> >
>> >Instead, just make sure precision and sign are the same and "trust"
>> >gimple to
>> >be right otherwise.
>>
>> If precision and sign are the same then types_compatible_p will
>return true.
>
>except in cases like this :-P
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (20 preceding siblings ...)
2020-10-16 16:55 ` rguenther at suse dot de
@ 2020-10-16 17:00 ` amacleod at redhat dot com
2020-10-19 6:08 ` rguenth at gcc dot gnu.org
` (17 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amacleod at redhat dot com @ 2020-10-16 17:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #21 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to rguenther@suse.de from comment #20)
> >
> >Is this your preferred solution?
>
> The backen should use more lowlevel functions to build this type rather than
> copying from a type that isn't appropriate. Off my head it wants
> fixup_unsigned_type after setting the mode and eventually a different
> function to build the original type. See tree.c where we build for example
> boolean_type_node
>
If thast the case, then I leave the construction/decision of how to build this
backend type more properly to a PowerPC person that knows what they are doing.
At least it should be straightforward for someone now.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (21 preceding siblings ...)
2020-10-16 17:00 ` amacleod at redhat dot com
@ 2020-10-19 6:08 ` rguenth at gcc dot gnu.org
2020-10-19 13:29 ` bergner at gcc dot gnu.org
` (16 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-10-19 6:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |segher at gcc dot gnu.org
--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so the fix here is quite obviously to simply drop the
build_distinct_type_copy calls:
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 9fdf97bc803..6e5192e4ab8 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -12915,14 +12915,12 @@ rs6000_init_builtins (void)
if (TARGET_EXTRA_BUILTINS)
{
tree oi_uns_type = make_unsigned_type (256);
- vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
SET_TYPE_MODE (vector_pair_type_node, POImode);
layout_type (vector_pair_type_node);
lang_hooks.types.register_builtin_type (vector_pair_type_node,
"__vector_pair");
tree xi_uns_type = make_unsigned_type (512);
- vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
SET_TYPE_MODE (vector_quad_type_node, PXImode);
layout_type (vector_quad_type_node);
lang_hooks.types.register_builtin_type (vector_quad_type_node,
powerpc folks, please test / push.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (22 preceding siblings ...)
2020-10-19 6:08 ` rguenth at gcc dot gnu.org
@ 2020-10-19 13:29 ` bergner at gcc dot gnu.org
2020-10-19 18:45 ` bergner at gcc dot gnu.org
` (15 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-10-19 13:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #23 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #22)
> OK, so the fix here is quite obviously to simply drop the
> build_distinct_type_copy calls:
Thanks richi, I'll put the patch through a bootstrap/regtest cycle.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (23 preceding siblings ...)
2020-10-19 13:29 ` bergner at gcc dot gnu.org
@ 2020-10-19 18:45 ` bergner at gcc dot gnu.org
2020-10-19 19:47 ` amacleod at redhat dot com
` (14 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-10-19 18:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #24 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #22)
> tree oi_uns_type = make_unsigned_type (256);
> - vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> SET_TYPE_MODE (vector_pair_type_node, POImode);
So this doesn't work. Without that line vector_pair_type_node is
NULL and the SET_TYPE_MODE() usage on the next line ends up dereferencing it
and we SEGV.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (24 preceding siblings ...)
2020-10-19 18:45 ` bergner at gcc dot gnu.org
@ 2020-10-19 19:47 ` amacleod at redhat dot com
2020-10-19 20:50 ` bergner at gcc dot gnu.org
` (13 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amacleod at redhat dot com @ 2020-10-19 19:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #25 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Peter Bergner from comment #24)
> (In reply to Richard Biener from comment #22)
> > tree oi_uns_type = make_unsigned_type (256);
> > - vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> > SET_TYPE_MODE (vector_pair_type_node, POImode);
>
> So this doesn't work. Without that line vector_pair_type_node is
> NULL and the SET_TYPE_MODE() usage on the next line ends up dereferencing it
> and we SEGV.
Wonder if it was suppose to be something like:
/* Vector pair and vector quad support. */
if (TARGET_EXTRA_BUILTINS)
{
- tree oi_uns_type = make_unsigned_type (256);
- vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
+ vector_pair_type_node = make_unsigned_type (256);
SET_TYPE_MODE (vector_pair_type_node, POImode);
layout_type (vector_pair_type_node);
lang_hooks.types.register_builtin_type (vector_pair_type_node,
"__vector_pair");
- tree xi_uns_type = make_unsigned_type (512);
- vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
+ vector_quad_type_node = make_unsigned_type (512);
SET_TYPE_MODE (vector_quad_type_node, PXImode);
layout_type (vector_quad_type_node);
lang_hooks.types.register_builtin_type (vector_quad_type_node,
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (25 preceding siblings ...)
2020-10-19 19:47 ` amacleod at redhat dot com
@ 2020-10-19 20:50 ` bergner at gcc dot gnu.org
2020-10-19 21:21 ` bergner at gcc dot gnu.org
` (12 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-10-19 20:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #26 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #25)
> (In reply to Peter Bergner from comment #24)
> > (In reply to Richard Biener from comment #22)
> > > tree oi_uns_type = make_unsigned_type (256);
> > > - vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> > > SET_TYPE_MODE (vector_pair_type_node, POImode);
> >
> > So this doesn't work. Without that line vector_pair_type_node is
> > NULL and the SET_TYPE_MODE() usage on the next line ends up dereferencing it
> > and we SEGV.
>
> Wonder if it was suppose to be something like:
Maybe? :-) I'll report back how the build does with this.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (26 preceding siblings ...)
2020-10-19 20:50 ` bergner at gcc dot gnu.org
@ 2020-10-19 21:21 ` bergner at gcc dot gnu.org
2020-10-19 22:40 ` bergner at gcc dot gnu.org
` (11 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-10-19 21:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #27 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #26)
> (In reply to Andrew Macleod from comment #25)
> > Wonder if it was suppose to be something like:
>
> Maybe? :-) I'll report back how the build does with this.
So far better results. My debug non-bootstrap build actually finished and I
can confirm it fixes the ICE on the test in Comment #5. My regtest is still
running.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (27 preceding siblings ...)
2020-10-19 21:21 ` bergner at gcc dot gnu.org
@ 2020-10-19 22:40 ` bergner at gcc dot gnu.org
2020-10-19 23:11 ` cvs-commit at gcc dot gnu.org
` (10 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-10-19 22:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #28 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #25)
> Wonder if it was suppose to be something like:
>
>
> /* Vector pair and vector quad support. */
> if (TARGET_EXTRA_BUILTINS)
> {
> - tree oi_uns_type = make_unsigned_type (256);
> - vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> + vector_pair_type_node = make_unsigned_type (256);
> SET_TYPE_MODE (vector_pair_type_node, POImode);
> layout_type (vector_pair_type_node);
> lang_hooks.types.register_builtin_type (vector_pair_type_node,
> "__vector_pair");
>
> - tree xi_uns_type = make_unsigned_type (512);
> - vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> + vector_quad_type_node = make_unsigned_type (512);
> SET_TYPE_MODE (vector_quad_type_node, PXImode);
> layout_type (vector_quad_type_node);
> lang_hooks.types.register_builtin_type (vector_quad_type_node,
So this passed bootstrap and regtesting with no regressions.
Is this really the correct fix? Don't we want a distinct type compared to the
unsigned type returned from make_unsigned_type()?
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (28 preceding siblings ...)
2020-10-19 22:40 ` bergner at gcc dot gnu.org
@ 2020-10-19 23:11 ` cvs-commit at gcc dot gnu.org
2020-10-19 23:28 ` amacleod at redhat dot com
` (9 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-10-19 23:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #29 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:
https://gcc.gnu.org/g:6e02de946125c36871bd4d8eff21f7f88f01a8aa
commit r11-4080-g6e02de946125c36871bd4d8eff21f7f88f01a8aa
Author: Andrew MacLeod <amacleod@redhat.com>
Date: Mon Oct 19 19:04:40 2020 -0400
Use precision and sign to compare types for ranges
Sanity check ranges by comparing just SIGN and PRECISION.
gcc/
PR tree-optimization/97360
* gimple-range.h (range_compatible_p): New.
* gimple-range-gori.cc (is_gimple_logical_p): Use
range_compatible_p.
(range_is_either_true_or_false): Ditto.
(gori_compute::outgoing_edge_range_p): Cast result to the correct
type if necessary.
(logical_stmt_cache::cacheable_p): Use range_compatible_p.
* gimple-range.cc (gimple_ranger::calc_stmt): Check
range_compatible_p
before casting the range.
(gimple_ranger::range_on_exit): Use range_compatible_p.
(gimple_ranger::range_on_edge): Ditto.
gcc/testsuite/
* gcc.dg/pr97360-2.c: New test.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (29 preceding siblings ...)
2020-10-19 23:11 ` cvs-commit at gcc dot gnu.org
@ 2020-10-19 23:28 ` amacleod at redhat dot com
2020-10-20 6:23 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: amacleod at redhat dot com @ 2020-10-19 23:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #30 from Andrew Macleod <amacleod at redhat dot com> ---
On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
> --- Comment #28 from Peter Bergner <bergner at gcc dot gnu.org> ---
> (In reply to Andrew Macleod from comment #25)
>> Wonder if it was suppose to be something like:
>>
>>
>> /* Vector pair and vector quad support. */
>> if (TARGET_EXTRA_BUILTINS)
>> {
>> - tree oi_uns_type = make_unsigned_type (256);
>> - vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
>> + vector_pair_type_node = make_unsigned_type (256);
>> SET_TYPE_MODE (vector_pair_type_node, POImode);
>> layout_type (vector_pair_type_node);
>> lang_hooks.types.register_builtin_type (vector_pair_type_node,
>> "__vector_pair");
>>
>> - tree xi_uns_type = make_unsigned_type (512);
>> - vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
>> + vector_quad_type_node = make_unsigned_type (512);
>> SET_TYPE_MODE (vector_quad_type_node, PXImode);
>> layout_type (vector_quad_type_node);
>> lang_hooks.types.register_builtin_type (vector_quad_type_node,
> So this passed bootstrap and regtesting with no regressions.
>
> Is this really the correct fix? Don't we want a distinct type compared to the
> unsigned type returned from make_unsigned_type()?
>
I actually dont know, Richi might have to comment on that.. Nothing was
referring to the original unsigned_type that was created? Its just
orphaned?
tree
make_unsigned_type (int precision)
{
tree type = make_node (INTEGER_TYPE);
TYPE_PRECISION (type) = precision;
fixup_unsigned_type (type);
return type;
}
All it does is create a new node, then fixup goes and creates the MIN
and MAX fields and sets a few other little things. The only reason
we saw the old unsigned type is we were picking it up from the MAX and
MIN fields,... which were set to the original type.
it sure *seems* like that is a resonable fix. Its not like that first
node is creating a system wide node?
our type system is a bit, umm, flakey, but it seems reasonable to me.
:-) And its in the spirit of what his patch was doing...
What could possibly go wrong? :-) :-)
Andrew
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (30 preceding siblings ...)
2020-10-19 23:28 ` amacleod at redhat dot com
@ 2020-10-20 6:23 ` rguenth at gcc dot gnu.org
2020-10-20 14:16 ` bergner at gcc dot gnu.org
` (7 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-10-20 6:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #30)
> On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
> >
> > --- Comment #28 from Peter Bergner <bergner at gcc dot gnu.org> ---
> > (In reply to Andrew Macleod from comment #25)
> >> Wonder if it was suppose to be something like:
> >>
> >>
> >> /* Vector pair and vector quad support. */
> >> if (TARGET_EXTRA_BUILTINS)
> >> {
> >> - tree oi_uns_type = make_unsigned_type (256);
> >> - vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> >> + vector_pair_type_node = make_unsigned_type (256);
> >> SET_TYPE_MODE (vector_pair_type_node, POImode);
> >> layout_type (vector_pair_type_node);
> >> lang_hooks.types.register_builtin_type (vector_pair_type_node,
> >> "__vector_pair");
> >>
> >> - tree xi_uns_type = make_unsigned_type (512);
> >> - vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> >> + vector_quad_type_node = make_unsigned_type (512);
> >> SET_TYPE_MODE (vector_quad_type_node, PXImode);
> >> layout_type (vector_quad_type_node);
> >> lang_hooks.types.register_builtin_type (vector_quad_type_node,
> > So this passed bootstrap and regtesting with no regressions.
> >
> > Is this really the correct fix?
Yes.
> > Don't we want a distinct type compared to the
> > unsigned type returned from make_unsigned_type()?
But make_unsigned_type already returns a distinct type. It's a low-level
worker unless for example make_nonstandard_integer_type which caches types.
> I actually dont know, Richi might have to comment on that.. Nothing was
> referring to the original unsigned_type that was created? Its just
> orphaned?
>
> tree
> make_unsigned_type (int precision)
> {
> tree type = make_node (INTEGER_TYPE);
>
> TYPE_PRECISION (type) = precision;
>
> fixup_unsigned_type (type);
> return type;
> }
>
>
> All it does is create a new node, then fixup goes and creates the MIN
> and MAX fields and sets a few other little things. The only reason
> we saw the old unsigned type is we were picking it up from the MAX and
> MIN fields,... which were set to the original type.
>
> it sure *seems* like that is a resonable fix. Its not like that first
> node is creating a system wide node?
>
> our type system is a bit, umm, flakey, but it seems reasonable to me.
> :-) And its in the spirit of what his patch was doing...
>
> What could possibly go wrong? :-) :-)
Nothing.
> Andrew
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (31 preceding siblings ...)
2020-10-20 6:23 ` rguenth at gcc dot gnu.org
@ 2020-10-20 14:16 ` bergner at gcc dot gnu.org
2020-10-20 14:41 ` rguenther at suse dot de
` (6 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-10-20 14:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #32 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #31)
> (In reply to Andrew Macleod from comment #30)
> > On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
> > >
> > > --- Comment #28 from Peter Bergner <bergner at gcc dot gnu.org> ---
> > > (In reply to Andrew Macleod from comment #25)
> > >> Wonder if it was suppose to be something like:
> > >>
> > >>
> > >> /* Vector pair and vector quad support. */
> > >> if (TARGET_EXTRA_BUILTINS)
> > >> {
> > >> - tree oi_uns_type = make_unsigned_type (256);
> > >> - vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> > >> + vector_pair_type_node = make_unsigned_type (256);
> > >> SET_TYPE_MODE (vector_pair_type_node, POImode);
> > >> layout_type (vector_pair_type_node);
> > >> lang_hooks.types.register_builtin_type (vector_pair_type_node,
> > >> "__vector_pair");
> > >>
> > >> - tree xi_uns_type = make_unsigned_type (512);
> > >> - vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> > >> + vector_quad_type_node = make_unsigned_type (512);
> > >> SET_TYPE_MODE (vector_quad_type_node, PXImode);
> > >> layout_type (vector_quad_type_node);
> > >> lang_hooks.types.register_builtin_type (vector_quad_type_node,
> > > So this passed bootstrap and regtesting with no regressions.
> > >
> > > Is this really the correct fix?
>
> Yes.
Just to verify, this is an approval for Andrew's patch above?
If so, I can push it to trunk for Andrew.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (32 preceding siblings ...)
2020-10-20 14:16 ` bergner at gcc dot gnu.org
@ 2020-10-20 14:41 ` rguenther at suse dot de
2020-10-20 16:03 ` bergner at gcc dot gnu.org
` (5 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: rguenther at suse dot de @ 2020-10-20 14:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #33 from rguenther at suse dot de <rguenther at suse dot de> ---
On October 20, 2020 4:16:37 PM GMT+02:00, "bergner at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
>--- Comment #32 from Peter Bergner <bergner at gcc dot gnu.org> ---
>(In reply to Richard Biener from comment #31)
>> (In reply to Andrew Macleod from comment #30)
>> > On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
>> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>> > >
>> > > --- Comment #28 from Peter Bergner <bergner at gcc dot gnu.org>
>---
>> > > (In reply to Andrew Macleod from comment #25)
>> > >> Wonder if it was suppose to be something like:
>> > >>
>> > >>
>> > >> /* Vector pair and vector quad support. */
>> > >> if (TARGET_EXTRA_BUILTINS)
>> > >> {
>> > >> - tree oi_uns_type = make_unsigned_type (256);
>> > >> - vector_pair_type_node = build_distinct_type_copy
>(oi_uns_type);
>> > >> + vector_pair_type_node = make_unsigned_type (256);
>> > >> SET_TYPE_MODE (vector_pair_type_node, POImode);
>> > >> layout_type (vector_pair_type_node);
>> > >> lang_hooks.types.register_builtin_type
>(vector_pair_type_node,
>> > >> "__vector_pair");
>> > >>
>> > >> - tree xi_uns_type = make_unsigned_type (512);
>> > >> - vector_quad_type_node = build_distinct_type_copy
>(xi_uns_type);
>> > >> + vector_quad_type_node = make_unsigned_type (512);
>> > >> SET_TYPE_MODE (vector_quad_type_node, PXImode);
>> > >> layout_type (vector_quad_type_node);
>> > >> lang_hooks.types.register_builtin_type
>(vector_quad_type_node,
>> > > So this passed bootstrap and regtesting with no regressions.
>> > >
>> > > Is this really the correct fix?
>>
>> Yes.
>
>Just to verify, this is an approval for Andrew's patch above?
Yes.
>If so, I can push it to trunk for Andrew.
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (33 preceding siblings ...)
2020-10-20 14:41 ` rguenther at suse dot de
@ 2020-10-20 16:03 ` bergner at gcc dot gnu.org
2020-10-20 20:27 ` segher at gcc dot gnu.org
` (4 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-10-20 16:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #34 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #32)
> (In reply to Richard Biener from comment #31)
> > > > Is this really the correct fix?
> >
> > Yes.
>
> Just to verify, this is an approval for Andrew's patch above?
> If so, I can push it to trunk for Andrew.
Heh, and of course this is a rs6000 port file, so Segher, do you have issues
with the above patch?
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (34 preceding siblings ...)
2020-10-20 16:03 ` bergner at gcc dot gnu.org
@ 2020-10-20 20:27 ` segher at gcc dot gnu.org
2020-10-21 19:30 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: segher at gcc dot gnu.org @ 2020-10-20 20:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #35 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Send it to gcc-patches@ please, with explanation and everything?
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (35 preceding siblings ...)
2020-10-20 20:27 ` segher at gcc dot gnu.org
@ 2020-10-21 19:30 ` cvs-commit at gcc dot gnu.org
2020-10-21 19:34 ` bergner at gcc dot gnu.org
` (2 subsequent siblings)
39 siblings, 0 replies; 41+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-10-21 19:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Peter Bergner <bergner@gcc.gnu.org>:
https://gcc.gnu.org/g:84cc3370d6d5972fe495b2114fb32f7b4a49a98d
commit r11-4193-g84cc3370d6d5972fe495b2114fb32f7b4a49a98d
Author: Richard Biener <rguenther@suse.de>
Date: Wed Oct 21 14:28:45 2020 -0500
rs6000: MMA type causes an ICE in ranger pass due to incompatible types
PR97360 shows a problem in how we create our PXI and POI modes that cause
an ICE in the ranger pass. The problem seems to be that the extra call
to build_distinct_type_copy() also creates new TYPE_{MIN,MAX}_VALUEs that
are not compatible/the same as the base type itself. The simple "fix" is
to actually remove the unneeded build_distinct_type_copy(), since according
to richi, the types returned from make_unsigned_type() are already
distinct.
gcc/
2020-10-21 Richard Biener <rguenther@suse.de>
PR target/97360
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Remove call
to
build_distinct_type_copy().
gcc/testsuite/
2020-10-21 Martin Liska <mliska@suse.cz>
PR target/97360
* gcc.target/powerpc/pr97360.c: New test.
Co-authored-by: Andrew MacLeod <amacleod@redhat.com>
Co-authored-by: Martin Liska <mliska@suse.cz>
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (36 preceding siblings ...)
2020-10-21 19:30 ` cvs-commit at gcc dot gnu.org
@ 2020-10-21 19:34 ` bergner at gcc dot gnu.org
2020-11-07 22:32 ` cvs-commit at gcc dot gnu.org
2020-11-07 22:36 ` bergner at gcc dot gnu.org
39 siblings, 0 replies; 41+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-10-21 19:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #37 from Peter Bergner <bergner at gcc dot gnu.org> ---
Fixed on trunk. I'll let this bake a week before backporting the rs6000 part
of the fix to GCC 10 (approved by Segher).
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (37 preceding siblings ...)
2020-10-21 19:34 ` bergner at gcc dot gnu.org
@ 2020-11-07 22:32 ` cvs-commit at gcc dot gnu.org
2020-11-07 22:36 ` bergner at gcc dot gnu.org
39 siblings, 0 replies; 41+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-07 22:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #38 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Peter Bergner
<bergner@gcc.gnu.org>:
https://gcc.gnu.org/g:06a191027749834e628f2c2bdd2256108bf532e9
commit r10-8992-g06a191027749834e628f2c2bdd2256108bf532e9
Author: Richard Biener <rguenther@suse.de>
Date: Wed Oct 21 14:28:45 2020 -0500
rs6000: MMA type causes an ICE in ranger pass due to incompatible types
PR97360 shows a problem in how we create our PXI and POI modes that cause
an ICE in the ranger pass. The problem seems to be that the extra call
to build_distinct_type_copy() also creates new TYPE_{MIN,MAX}_VALUEs that
are not compatible/the same as the base type itself. The simple "fix" is
to actually remove the unneeded build_distinct_type_copy(), since according
to richi, the types returned from make_unsigned_type() are already
distinct.
gcc/
2020-10-21 Richard Biener <rguenther@suse.de>
PR target/97360
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Remove call
to
build_distinct_type_copy().
gcc/testsuite/
2020-10-21 Martin Liska <mliska@suse.cz>
PR target/97360
* gcc.target/powerpc/pr97360.c: New test.
Co-authored-by: Andrew MacLeod <amacleod@redhat.com>
Co-authored-by: Martin Liska <mliska@suse.cz>
(cherry picked from commit 84cc3370d6d5972fe495b2114fb32f7b4a49a98d)
^ permalink raw reply [flat|nested] 41+ messages in thread* [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
2020-10-10 3:08 [Bug tree-optimization/97360] New: ICE in range_on_exit amodra at gmail dot com
` (38 preceding siblings ...)
2020-11-07 22:32 ` cvs-commit at gcc dot gnu.org
@ 2020-11-07 22:36 ` bergner at gcc dot gnu.org
39 siblings, 0 replies; 41+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-11-07 22:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
Peter Bergner <bergner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #39 from Peter Bergner <bergner at gcc dot gnu.org> ---
I pushed the fix to the GCC 10 release brnahc, so this is fixed everywhere now.
^ permalink raw reply [flat|nested] 41+ messages in thread