[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594 Bug 109594 depends on bug 109607, which changed state. Bug 109607 Summary: IPA replaces stmt with invalid gimple https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109607 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7bcdcf86e8272eeb524cc1dcb0ada8c8cfe6f27e commit r14-285-g7bcdcf86e8272eeb524cc1dcb0ada8c8cfe6f27e Author: Richard Biener Date: Mon Apr 24 13:20:25 2023 +0200 tree-optimization/109594 - wrong register promotion We fail to verify the constraints under which we allow handled components to wrap registers. The gcc.dg/pr70022.c testcase shows that we happily end up with _2 = VIEW_CONVERT_EXPR(v_1(D)) as produced by SSA rewrite and update_address_taken. But the intent was that we wrap registers with at most a single level of handled components and specifically only allow __real, __imag, BIT_FIELD_REF and VIEW_CONVERT_EXPR on them, but not ARRAY_REF or COMPONENT_REF. Together with the improved gimple_load predicate taking advantage of the above and ASAN this eventually ICEd. The following fixes update_address_taken as to this constraint. PR tree-optimization/109594 * tree-ssa.cc (non_rewritable_mem_ref_base): Constrain what we rewrite to a register based on the above.
[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594
--- Comment #2 from Richard Biener ---
This goes wrong in update_address_taken before into-SSA which removes
TREE_ADDRESSABLE from 'v' without transforming it in any way.
:
D.3193 = VIEW_CONVERT_EXPR(v)[18446744073709551615];
return D.3193;
update_address_taken uses maybe_rewrite_mem_ref_base to rewrite rvalues
but that leaves all outer handled components in place - in fact it
even puts a VIEW_CONVERT_EXPR around it.
For a "valid" testcase
typedef int v4si __attribute__((vector_size(16)));
int foo (v4si v)
{
return v[1];
}
the frontend produces
return VIEW_CONVERT_EXPR(v)[1];
and we then gimplify it to
D.2755 = BIT_FIELD_REF ;
via folding the stmt and maybe_canonicalize_mem_ref_addr, but we refrain from
doing that for out-of-bound accesses.
We do not have good IL verification for the differences between valid GIMPLE
and valid GIMPLE SSA - verify_gimple_* verifies GIMPLE and verify_ssa
doesn't apply any additional IL constraints.
I think we do not want ARRAY_REF of SSA_NAMEs nor do we want multi-level
handled_components on SSA_NAMEs.
Either we have to be way more aggressive in rewriting the refs
(use get_ref_base_and_extent?) to BIT_FIELD_REFs or in this case to
in-bound refs or zero or we have to restrict the rewrite to the cases
we already handle (which is very few special cases around MEM_REF[]).
I'm trying to see what doing the latter regresses.
[Bug sanitizer/109594] [14 Regression] ICE verify_gimple failed with ASAN since r14-67-g2c800ed8d59cff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109594 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Last reconfirmed||2023-04-24 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Biener --- I will have a look.
