[Bug tree-optimization/97360] New: ICE in range_on_exit

[Bug tree-optimization/97360] New: ICE in range_on_exit

[amodra at gmail dot com]

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

            Bug ID: 97360
           Summary: ICE in range_on_exit
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amodra at gmail dot com
  Target Milestone: ---

during GIMPLE pass: evrp
/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/mma-double-test.c: In
function 'MMA':
/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/mma-double-test.c:186:1:
internal compiler error: in range_on_exit, at gimple-range.cc:931

The types involved are:
 <integer_type 0x7ffff6622bd0 __vector_quad sizes-gimplified unsigned PXI
    size <integer_cst 0x7ffff653c660 type <integer_type 0x7ffff652d1f8
bitsizetype> constant 512>
    unit-size <integer_cst 0x7ffff661f180 type <integer_type 0x7ffff652d150
sizetype> constant 64>
    align:512 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6622bd0 precision:512 min <integer_cst 0x7ffff661f150 0> max
<integer_cst 0x7ffff6625000
0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff>
    pointer_to_this <pointer_type 0x7ffff6644000>>

and:
 <integer_type 0x7ffff6622b28 public unsigned XI
    size <integer_cst 0x7ffff653c660 type <integer_type 0x7ffff652d1f8
bitsizetype> constant 512>
    unit-size <integer_cst 0x7ffff661f180 type <integer_type 0x7ffff652d150
sizetype> constant 64>
    align:512 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6622b28 precision:512 min <integer_cst 0x7ffff661f150 0> max
<integer_cst 0x7ffff6625000
0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff>>

So this may well be a powerpc target bug.

[Bug tree-optimization/97360] ICE in range_on_exit

[msebor at gcc dot gnu.org]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenth at gcc dot gnu.org]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[marxin at gcc dot gnu.org]

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?

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amodra at gmail dot com]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amodra at gmail dot com]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[marxin at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[aldyh at gcc dot gnu.org]

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?

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amodra at gmail dot com]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amodra at gmail dot com]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[marxin at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amodra at gmail dot com]

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;
}

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com]

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?

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenth at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com]

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)));
+    }
+

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenth at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenther at suse dot de]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenther at suse dot de]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenther at suse dot de]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenth at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[bergner at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[bergner at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com]

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,

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[bergner at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[bergner at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[bergner at gcc dot gnu.org]

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()?

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[cvs-commit at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenth at gcc dot gnu.org]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[bergner at gcc dot gnu.org]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenther at suse dot de]

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.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[bergner at gcc dot gnu.org]

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?

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[segher at gcc dot gnu.org]

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?

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[cvs-commit at gcc dot gnu.org]

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>

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[bergner at gcc dot gnu.org]

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

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[cvs-commit at gcc dot gnu.org]

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)

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[bergner at gcc dot gnu.org]

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.