[Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572

[Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org]

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

            Bug ID: 99824
           Summary: ICE in wide_int_to_tree_1, at tree.c:1572
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Created attachment 50484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50484&action=edit
ltrans object file

The following happens for the current gcc-10 branch when building Linux kernel
with LTO.

$ ./lto1 vmlinux.o.ltrans720.o -fltrans -quiet
during GIMPLE pass: fre
../../../../home/marxin/Programming/linux-misc/drivers/media/pci/cx18/cx18-i2c.c:
In function ‘init_cx18_i2c’:
../../../../home/marxin/Programming/linux-misc/drivers/media/pci/cx18/cx18-i2c.c:217:
internal compiler error: in wide_int_to_tree_1, at tree.c:1572
  217 | int init_cx18_i2c(struct cx18 *cx)
      | 
0x5e2780 wide_int_to_tree_1
        /home/marxin/Programming/gcc2/gcc/tree.c:1572
0xa59ac3 set_min_and_max_values_for_integral_type(tree_node*, int, signop)
        /home/marxin/Programming/gcc2/gcc/stor-layout.c:2822
0xa5e766 set_min_and_max_values_for_integral_type(tree_node*, int, signop)
        /home/marxin/Programming/gcc2/gcc/stor-layout.c:2816
0xa5e766 fixup_signed_type(tree_node*)
        /home/marxin/Programming/gcc2/gcc/stor-layout.c:2834
0xcb07ae build_nonstandard_integer_type(unsigned long, int)
        /home/marxin/Programming/gcc2/gcc/tree.c:8020
0xbd6245 vn_reference_lookup_3
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:2890
0xb32522 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
        /home/marxin/Programming/gcc2/gcc/tree-ssa-alias.c:3691
0xbd124f vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*)
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:3545
0xbd6e8e visit_reference_op_load
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:4934
0xbd6e8e visit_stmt
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:5374
0xbd7b96 process_bb
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7047
0xbd9a3e do_rpo_vn
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7566
0xbda300 execute
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7834
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/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
            Summary|ICE in wide_int_to_tree_1,  |[10 Regression] ICE in
                   |at tree.c:1572              |wide_int_to_tree_1, at
                   |                            |tree.c:1572
   Last reconfirmed|                            |2021-03-30
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
The issue is likely fixed on master.
Is it something familiar Richi?

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
valgrind tells:

==2489== Conditional jump or move depends on uninitialised value(s)
==2489==    at 0xCFBD22: wi::force_to_size(long*, long const*, unsigned int,
unsigned int, unsigned int, signop) (wide-int.cc:370)
==2489==    by 0xCB2CD3: from (wide-int.h:1172)
==2489==    by 0xCB2CD3: wide_int_to_tree_1(tree_node*,
generic_wide_int<wide_int_ref_storage<false, true> > const&) (tree.c:1515)
==2489==    by 0xA59AC3: set_min_and_max_values_for_integral_type(tree_node*,
int, signop) [clone .part.0] (stor-layout.c:2822)
==2489==    by 0xA5E766: set_min_and_max_values_for_integral_type
(stor-layout.c:2816)
==2489==    by 0xA5E766: fixup_signed_type(tree_node*) (stor-layout.c:2834)
==2489==    by 0xCB079E: build_nonstandard_integer_type(unsigned long, int)
(tree.c:8020)
==2489==    by 0xBD6245: vn_reference_lookup_3(ao_ref*, tree_node*, void*,
translate_flags*) (tree-ssa-sccvn.c:2890)
==2489==    by 0xB32522: walk_non_aliased_vuses(ao_ref*, tree_node*, bool,
void* (*)(ao_ref*, tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*,
translate_flags*), tree_node* (*)(tree_node*), unsigned int&, void*)
(tree-ssa-alias.c:3691)
==2489==    by 0xBD124F: vn_reference_lookup(tree_node*, tree_node*,
vn_lookup_kind, vn_reference_s**, bool, tree_node**, tree_node*)
(tree-ssa-sccvn.c:3545)
==2489==    by 0xBD6E8E: visit_reference_op_load (tree-ssa-sccvn.c:4934)
==2489==    by 0xBD6E8E: visit_stmt(gimple*, bool) [clone .isra.0]
(tree-ssa-sccvn.c:5374)
==2489==    by 0xBD7B96: process_bb(rpo_elim&, basic_block_def*, bool, bool,
bool, bool, bool, bitmap_head*, bool) [clone .constprop.0]
(tree-ssa-sccvn.c:7047)
==2489==    by 0xBD9A3E: do_rpo_vn(function*, edge_def*, bitmap_head*, bool,
bool) (tree-ssa-sccvn.c:7566)
==2489==    by 0xBDA300: (anonymous namespace)::pass_fre::execute(function*)
(tree-ssa-sccvn.c:7834)

#0  fancy_abort (file=file@entry=0x148dfb8
"/home/marxin/Programming/gcc2/gcc/tree.c", line=line@entry=1572,
function=function@entry=0x148cba0 "wide_int_to_tree_1") at
/home/marxin/Programming/gcc2/gcc/diagnostic.c:1778
#1  0x00000000005e2781 in wide_int_to_tree_1 (type=<string_cst 0x7fffffffd410>,
pcst=...) at /home/marxin/Programming/gcc2/gcc/tree.c:1572
#2  0x0000000000a59ac4 in set_min_and_max_values_for_integral_type
(type=<string_cst 0x7fffffffd410>, type@entry=<integer_type 0x7ffff6ef97e0>,
precision=6, sgn=sgn@entry=SIGNED) at
/home/marxin/Programming/gcc2/gcc/poly-int.h:671
#3  0x0000000000a5e767 in set_min_and_max_values_for_integral_type (sgn=SIGNED,
precision=<optimized out>, type=<integer_type 0x7ffff6ef97e0>) at
/home/marxin/Programming/gcc2/gcc/stor-layout.c:2816
#4  fixup_signed_type (type=<integer_type 0x7ffff6ef97e0>) at
/home/marxin/Programming/gcc2/gcc/stor-layout.c:2834
#5  0x0000000000cb079f in build_nonstandard_integer_type
(precision=precision@entry=384, unsignedp=0) at
/home/marxin/Programming/gcc2/gcc/tree.c:8020
#6  0x0000000000bd6246 in vn_reference_lookup_3 (ref=ref@entry=0x7fffffffd760,
vuse=vuse@entry=<ssa_name 0x7ffff6185ea0 170>,
data_=data_@entry=0x7fffffffd7f0,
disambiguate_only=disambiguate_only@entry=0x7fffffffd694)
    at /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:2890

It's called for a string constant:

(gdb) p debug_tree((tree)0x7fffffffd410)
 <string_cst 0x7fffffffd410 "">
$1 = void

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
It doesn't reproduce for me with a debug build.  The backtrace you cite is
impossible (with that STRING_CST).  The GCC10 package from leap unfortunately
doesn't have zstd support enabled...  I'm trying a local
profile-LTO-bootstrapped build.

What exact rev. were you testing and how did you configure/build GCC?

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.3
            Version|11.0                        |10.2.1
      Known to fail|10.2.0                      |10.2.1

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so I guess that things go wrong in wi::min_value where we nowhere check
that the precision we're asking for (384) fits in a wide_int,
WIDE_INT_MAX_PRECISION should be 160 (MAX_BITSIZE_MODE_ANY_INT) rounded up
to 64bits thus 192.  That then clobbers the stack somewhere and things go
wrong.

This is likely uncovered by the PR98834 "fix"
g592388d4f6e8a6adb470428fef6195694f4a3dce (but this fix shouldn't expose
such large precisions by itself)

I still like to reproduce it to see what events lead to such large requested
precision.  On trunk sth like

diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 784f131ebb8..94b8b21c7a8 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -2838,6 +2838,8 @@ set_min_and_max_values_for_integral_type (tree type,
   if (precision < 1)
     return;

+  gcc_assert (precision <= WIDE_INT_MAX_PRECISION);
+
   TYPE_MIN_VALUE (type)
     = wide_int_to_tree (type, wi::min_value (precision, sgn));
   TYPE_MAX_VALUE (type)

should uncover any similar issue and eventually allow producing smaller
testcases.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> It doesn't reproduce for me with a debug build.  The backtrace you cite is
> impossible (with that STRING_CST).  The GCC10 package from leap unfortunately
> doesn't have zstd support enabled...  I'm trying a local
> profile-LTO-bootstrapped build.


> 
> What exact rev. were you testing and how did you configure/build GCC?

Please build it locally for

commit 982df4d606e8f3e8f41369672bf0c6ff22ee58c1 (HEAD -> releases/gcc-10,
origin/releases/gcc-10)
Author: GCC Administrator <gccadmin@gcc.gnu.org>
Date:   Tue Mar 30 00:17:29 2021 +0000

    Daily bump.

$ ./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=./gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: /home/marxin/Programming/gcc2/configure
--prefix=/home/marxin/bin/gcc2 --enable-languages=c,c++,fortran
--disable-bootstrap --disable-multilib --disable-libsanitizer
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210330 (GCC)

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
> diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> index 784f131ebb8..94b8b21c7a8 100644
> --- a/gcc/stor-layout.c
> +++ b/gcc/stor-layout.c
> @@ -2838,6 +2838,8 @@ set_min_and_max_values_for_integral_type (tree type,
>    if (precision < 1)
>      return;
>  
> +  gcc_assert (precision <= WIDE_INT_MAX_PRECISION);
> +
>    TYPE_MIN_VALUE (type)
>      = wide_int_to_tree (type, wi::min_value (precision, sgn));
>    TYPE_MAX_VALUE (type)
> 
> should uncover any similar issue and eventually allow producing smaller
> testcases.

Where would you expect the assert to be triggered? In LTO/non-LTO mode?

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we're value-numbering a char load

Value numbering stmt = _177 = *sc_175;

with sc_175 == _7 and

  _7 = &cx_41(D)->i2c_adap[i_24].name;

which get's us a valueized ref (of type 'char') that looks like
cx_41(D)->i2c_adap[i_24].name and ao_ref_init_from_vn_reference turning
that into

$1 = {ref = <tree 0x0>, base = <mem_ref 0x7ffff521cf28>, 
  offset = {<poly_int_pod<1, long>> = {coeffs = {388000}}, <No data fields>}, 
  size = {<poly_int_pod<1, long>> = {coeffs = {384}}, <No data fields>}, 
  max_size = {<poly_int_pod<1, long>> = {coeffs = {384}}, <No data fields>}, 
  ref_alias_set = 0, base_alias_set = 0, volatile_p = false}

because it looks at COMPONENT_REF/BIT_FIELD_REF sizes but those really only
represent offsets (well, not really really, but ...).

We then arrive at

# .MEM_170 = VDEF <.MEM_169>
cx_41(D)->i2c_adap[i_24].name = "cx18 i2c driver";

So this looks like a latent thing waiting to happen.  The GIMPLE FE is
currently not happy to produce a testcase.  Trunk is somewhat more
resilent to produce the situation since vn_reference_maybe_forwprop_address
uses the SSA lattice for the address offset calculation (in this case
i_24 has value zero).

With the proposed assert at least the LTRANS unit reproduces an ICE
with a debug build for me.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #6)
> > diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> > index 784f131ebb8..94b8b21c7a8 100644
> > --- a/gcc/stor-layout.c
> > +++ b/gcc/stor-layout.c
> > @@ -2838,6 +2838,8 @@ set_min_and_max_values_for_integral_type (tree type,
> >    if (precision < 1)
> >      return;
> >  
> > +  gcc_assert (precision <= WIDE_INT_MAX_PRECISION);
> > +
> >    TYPE_MIN_VALUE (type)
> >      = wide_int_to_tree (type, wi::min_value (precision, sgn));
> >    TYPE_MAX_VALUE (type)
> > 
> > should uncover any similar issue and eventually allow producing smaller
> > testcases.
> 
> Where would you expect the assert to be triggered? In LTO/non-LTO mode?

Eventually in both.  The assert also triggers with the cited change reverted
so I do think the issue is latent.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Changing ao_ref_init_from_vn_reference to avoid excess sizes (in excess of the
access type specified) like with

diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 4b280f21006..926b4a976ae 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -996,22 +996,26 @@ ao_ref_init_from_vn_reference (ao_ref *ref,
   poly_offset_int size = -1;
   tree size_tree = NULL_TREE;

-  /* First get the final access size from just the outermost expression.  */
+  machine_mode mode = TYPE_MODE (type);
+  if (mode == BLKmode)
+    size_tree = TYPE_SIZE (type);
+  else
+    size = GET_MODE_BITSIZE (mode);
+  if (size_tree != NULL_TREE
+      && poly_int_tree_p (size_tree))
+    size = wi::to_poly_offset (size_tree);
+
+  /* Lower the final access size from the outermost expression.  */
   op = &ops[0];
+  size_tree = NULL_TREE;
   if (op->opcode == COMPONENT_REF)
     size_tree = DECL_SIZE (op->op0);
   else if (op->opcode == BIT_FIELD_REF)
     size_tree = op->op0;
-  else
-    {
-      machine_mode mode = TYPE_MODE (type);
-      if (mode == BLKmode)
-       size_tree = TYPE_SIZE (type);
-      else
-       size = GET_MODE_BITSIZE (mode);
-    }
   if (size_tree != NULL_TREE
-      && poly_int_tree_p (size_tree))
+      && poly_int_tree_p (size_tree)
+      && (!known_size_p (size)
+         || known_lt (wi::to_poly_offset (size_tree), size)))
     size = wi::to_poly_offset (size_tree);

   /* Initially, maxsize is the same as the accessed element size.

avoids hitting the assert.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 50486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50486&action=edit
patch I am testing

I'm testing this patch, on trunk first, but it also applies to the branch where
it fixes the issue on the LTRANS unit in question.  Maybe you can check a
kernel LTO build with this?

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #10)
> Created attachment 50486 [details]
> patch I am testing
> 
> I'm testing this patch, on trunk first, but it also applies to the branch
> where it fixes the issue on the LTRANS unit in question.  Maybe you can
> check a kernel LTO build with this?

All right, I'll try first reducing a test-case..

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 30 Mar 2021, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99824
> 
> --- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #10)
> > Created attachment 50486 [details]
> > patch I am testing
> > 
> > I'm testing this patch, on trunk first, but it also applies to the branch
> > where it fixes the issue on the LTRANS unit in question.  Maybe you can
> > check a kernel LTO build with this?
> 
> All right, I'll try first reducing a test-case..

That would be nice - I don't even have a GIMPLE FE one even if I know
exactly how it goes "wrong" in VN...

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška <marxin at gcc dot gnu.org> ---
Reduced test-case:

$ cat ice.i
unsigned int
strlen(char *s) {
  for (; *s;)
    ;
}

struct i2c_adapter {
  char name[48];
};

struct {
  int instance;
  struct i2c_adapter i2c_adap[];
} * init_cx18_i2c_cx;

const struct i2c_adapter cx18_i2c_adap_template = {""};
int init_cx18_i2c___trans_tmp_1;

void
init_cx18_i2c() {
  int i = 0;
  for (;; i++) {
    init_cx18_i2c_cx->i2c_adap[i] = cx18_i2c_adap_template;
    init_cx18_i2c___trans_tmp_1 = strlen(init_cx18_i2c_cx->i2c_adap[i].name);
  }
}

$ gcc -O2 ice.i -c
ice.i:2:1: warning: conflicting types for built-in function ‘strlen’; expected
‘long unsigned int(const char *)’ [-Wbuiltin-declaration-mismatch]
    2 | strlen(char *s) {
      | ^~~~~~
ice.i:1:1: note: ‘strlen’ is declared in header ‘<string.h>’
  +++ |+#include <string.h>
    1 | unsigned int
during GIMPLE pass: fre
ice.i: In function ‘init_cx18_i2c’:
ice.i:26:1: internal compiler error: in
set_min_and_max_values_for_integral_type, at stor-layout.c:2819
   26 | }
      | ^
0x5eaa0e set_min_and_max_values_for_integral_type(tree_node*, int, signop)
        /home/marxin/Programming/gcc2/gcc/stor-layout.c:2819
0xb1ad14 fixup_signed_type(tree_node*)
        /home/marxin/Programming/gcc2/gcc/stor-layout.c:2836
0xd6d15e build_nonstandard_integer_type(unsigned long, int)
        /home/marxin/Programming/gcc2/gcc/tree.c:8020
0xc92c55 vn_reference_lookup_3
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:2890
0xbeef32 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
        /home/marxin/Programming/gcc2/gcc/tree-ssa-alias.c:3691
0xc8dc5f vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*)
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:3545
0xc9389e visit_reference_op_load
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:4934
0xc9389e visit_stmt
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:5374
0xc945a6 process_bb
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7047
0xc9644e do_rpo_vn
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7566
0xc96d10 execute
        /home/marxin/Programming/gcc2/gcc/tree-ssa-sccvn.c:7834
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.

Fixed on master with r11-198-g1595a1cb7bfac8d5 and started with
r10-1823-g8389386c6d55d57a (one needs -fno-finite-loops).

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
> Fixed on master with r11-198-g1595a1cb7bfac8d5

Reverting the match.pd hunk does not help with reproduction on the current
master.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

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

commit r11-7906-gbd3d919b58466a9837e423c1255b88215f89bc9d
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Mar 30 11:22:52 2021 +0200

    tree-optimization/99824 - avoid excessive integer type precision in VN

    VN sometimes builds new integer types to handle accesss where precision
    of the access type does not match the access size.  The way
    ao_ref_init_from_vn_reference is computing the access size ignores
    the access type in case the ref operands have an outermost
    COMPONENT_REF which, in case it is an array for example, can be
    way larger than the access size.  This can cause us to try
    building an integer type with precision larger than WIDE_INT_MAX_PRECISION
    eventually leading to memory corruption.

    The following adjusts ao_ref_init_from_vn_reference to only lower
    access sizes via the outermost COMPONENT_REF but otherwise honor
    the access size as specified by the access type.

    It also places an assert in integer type building that we remain
    in the limits of WIDE_INT_MAX_PRECISION.  I chose the shared code
    where we set TYPE_MIN/MAX_VALUE because that will immediately
    cross the wide_ints capacity otherwise.

    2021-03-30  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/99824
            * stor-layout.c (set_min_and_max_values_for_integral_type):
            Assert the precision is within the bounds of
            WIDE_INT_MAX_PRECISION.
            * tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use
            the outermost component ref only to lower the access size
            and initialize that from the access type.

            * gcc.dg/torture/pr99824.c: New testcase.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

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

commit r10-9618-gee15832c53d52656e562c29110f2be1cfb66c450
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Mar 30 11:22:52 2021 +0200

    tree-optimization/99824 - avoid excessive integer type precision in VN

    VN sometimes builds new integer types to handle accesss where precision
    of the access type does not match the access size.  The way
    ao_ref_init_from_vn_reference is computing the access size ignores
    the access type in case the ref operands have an outermost
    COMPONENT_REF which, in case it is an array for example, can be
    way larger than the access size.  This can cause us to try
    building an integer type with precision larger than WIDE_INT_MAX_PRECISION
    eventually leading to memory corruption.

    The following adjusts ao_ref_init_from_vn_reference to only lower
    access sizes via the outermost COMPONENT_REF but otherwise honor
    the access size as specified by the access type.

    It also places an assert in integer type building that we remain
    in the limits of WIDE_INT_MAX_PRECISION.  I chose the shared code
    where we set TYPE_MIN/MAX_VALUE because that will immediately
    cross the wide_ints capacity otherwise.

    2021-03-30  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/99824
            * stor-layout.c (set_min_and_max_values_for_integral_type):
            Assert the precision is within the bounds of
            WIDE_INT_MAX_PRECISION.
            * tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use
            the outermost component ref only to lower the access size
            and initialize that from the access type.

            * gcc.dg/torture/pr99824.c: New testcase.

[Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.