https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
Martin Jambor <jamborm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #13 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to rguent...@suse.de from comment #10)
[...]
>
> And still SRA should not use a random RHS "model" to build a new
> LHS access, most definitely not when the original aggregate LHS
> isn't TBAA compatible with it.
That could be accomplished by:
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index c26559edc66..f780285254f 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -3451,7 +3451,7 @@ create_total_scalarization_access (struct access *parent,
HOST_WIDE_INT pos,
access->grp_write = parent->grp_write;
access->grp_total_scalarization = 1;
access->grp_hint = 1;
- access->grp_same_access_path = path_comparable_for_same_access (expr);
+ access->grp_same_access_path = 0;
access->reverse = reverse_storage_order_for_component_p (expr);
access->next_sibling = next_sibling;
Which works for the testcase but I am afraid it might not be
sufficient. If there was a way to actually create a pre-SRA access to
an individual element of the array with the wrong (int) type in the
function and there wasn't any with the other type, then, SRA not being
flow sensitive pass, would happily use the type again because it would
not be "random" any more.
> The array assignment from the front-end is good enough for the
> middle-end as far as IL type hygiene is concerned given the
> element types are useless-type-convertible.
It is quite evil :-) What would be a good predicate to detect such
compatible but TBAA-different assignments, if there is one?
Because I think we need to prevent building of references "according to
a model" for all scalar replacements under them.
