https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2022-07-28
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
e[0][0] should be handled here:
tree ref_to_array = ref;
while (handled_component_p (ref))
{
...
/* If we have a multi-dimensional array we do not consider
a non-innermost dimension as flex array if the whole
multi-dimensional array is at struct end.
Same for an array of aggregates with a trailing array
member. */
else if (TREE_CODE (ref) == ARRAY_REF)
return false;
maybe you are refering to e[0]?
In that case the issue is that we fail to consider the case when there is
no known padding. One would be if DECL_P (TREE_OPERAND (ref_to_array, 0)),
if the whole object is the array itself. Thus
diff --git a/gcc/tree.cc b/gcc/tree.cc
index 84000dd8b69..aaac7610f9c 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -12778,6 +12778,10 @@ array_at_struct_end_p (tree ref)
&& DECL_SIZE_UNIT (ref)
&& TREE_CODE (DECL_SIZE_UNIT (ref)) == INTEGER_CST)
{
+ /* If the object itself is the array it is not at struct end. */
+ if (DECL_P (TREE_OPERAND (ref_to_array, 0)))
+ return false;
+
/* Check whether the array domain covers all of the available
padding. */
poly_int64 offset;
we might be able to play tricks with alignment as well, if the alignment
of the object is the same or less as that of the array element alignment
(not sure if we can trust the alignment of the array element type here),
there's no room for padding. But maybe that breaks in strange cases.
