* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
@ 2021-03-30 7:08 ` marxin at gcc dot gnu.org
2021-03-30 7:19 ` marxin at gcc dot gnu.org
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-30 7:08 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
2021-03-30 7:08 ` [Bug tree-optimization/99824] [10 Regression] " marxin at gcc dot gnu.org
@ 2021-03-30 7:19 ` marxin at gcc dot gnu.org
2021-03-30 7:42 ` rguenth at gcc dot gnu.org
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-30 7:19 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
2021-03-30 7:08 ` [Bug tree-optimization/99824] [10 Regression] " marxin at gcc dot gnu.org
2021-03-30 7:19 ` marxin at gcc dot gnu.org
@ 2021-03-30 7:42 ` rguenth at gcc dot gnu.org
2021-03-30 7:42 ` rguenth at gcc dot gnu.org
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-30 7:42 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (2 preceding siblings ...)
2021-03-30 7:42 ` rguenth at gcc dot gnu.org
@ 2021-03-30 7:42 ` rguenth at gcc dot gnu.org
2021-03-30 8:09 ` rguenth at gcc dot gnu.org
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-30 7:42 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (3 preceding siblings ...)
2021-03-30 7:42 ` rguenth at gcc dot gnu.org
@ 2021-03-30 8:09 ` rguenth at gcc dot gnu.org
2021-03-30 8:24 ` marxin at gcc dot gnu.org
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-30 8:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (4 preceding siblings ...)
2021-03-30 8:09 ` rguenth at gcc dot gnu.org
@ 2021-03-30 8:24 ` marxin at gcc dot gnu.org
2021-03-30 8:30 ` marxin at gcc dot gnu.org
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-30 8:24 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (5 preceding siblings ...)
2021-03-30 8:24 ` marxin at gcc dot gnu.org
@ 2021-03-30 8:30 ` marxin at gcc dot gnu.org
2021-03-30 9:14 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-30 8:30 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (6 preceding siblings ...)
2021-03-30 8:30 ` marxin at gcc dot gnu.org
@ 2021-03-30 9:14 ` rguenth at gcc dot gnu.org
2021-03-30 9:16 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-30 9:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (7 preceding siblings ...)
2021-03-30 9:14 ` rguenth at gcc dot gnu.org
@ 2021-03-30 9:16 ` rguenth at gcc dot gnu.org
2021-03-30 9:22 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-30 9:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (8 preceding siblings ...)
2021-03-30 9:16 ` rguenth at gcc dot gnu.org
@ 2021-03-30 9:22 ` rguenth at gcc dot gnu.org
2021-03-30 9:30 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-30 9:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (9 preceding siblings ...)
2021-03-30 9:22 ` rguenth at gcc dot gnu.org
@ 2021-03-30 9:30 ` rguenth at gcc dot gnu.org
2021-03-30 9:32 ` marxin at gcc dot gnu.org
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-30 9:30 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (10 preceding siblings ...)
2021-03-30 9:30 ` rguenth at gcc dot gnu.org
@ 2021-03-30 9:32 ` marxin at gcc dot gnu.org
2021-03-30 10:03 ` rguenther at suse dot de
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-30 9:32 UTC (permalink / raw)
To: gcc-bugs
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..
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (11 preceding siblings ...)
2021-03-30 9:32 ` marxin at gcc dot gnu.org
@ 2021-03-30 10:03 ` rguenther at suse dot de
2021-03-30 10:08 ` marxin at gcc dot gnu.org
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenther at suse dot de @ 2021-03-30 10:03 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (12 preceding siblings ...)
2021-03-30 10:03 ` rguenther at suse dot de
@ 2021-03-30 10:08 ` marxin at gcc dot gnu.org
2021-03-30 10:13 ` marxin at gcc dot gnu.org
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-30 10:08 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (13 preceding siblings ...)
2021-03-30 10:08 ` marxin at gcc dot gnu.org
@ 2021-03-30 10:13 ` marxin at gcc dot gnu.org
2021-03-30 12:01 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-03-30 10:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (14 preceding siblings ...)
2021-03-30 10:13 ` marxin at gcc dot gnu.org
@ 2021-03-30 12:01 ` cvs-commit at gcc dot gnu.org
2021-03-30 12:02 ` cvs-commit at gcc dot gnu.org
2021-03-30 12:02 ` rguenth at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-30 12:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (15 preceding siblings ...)
2021-03-30 12:01 ` cvs-commit at gcc dot gnu.org
@ 2021-03-30 12:02 ` cvs-commit at gcc dot gnu.org
2021-03-30 12:02 ` rguenth at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-30 12:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug tree-optimization/99824] [10 Regression] ICE in wide_int_to_tree_1, at tree.c:1572
2021-03-30 7:07 [Bug tree-optimization/99824] New: ICE in wide_int_to_tree_1, at tree.c:1572 marxin at gcc dot gnu.org
` (16 preceding siblings ...)
2021-03-30 12:02 ` cvs-commit at gcc dot gnu.org
@ 2021-03-30 12:02 ` rguenth at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-30 12:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread