> Yes we do, even for struct { struct { int a; char a[1] } }; (note the not
> really "trailing" as there is padding after the trailing array). We do
> take size limitations from a DECL (if we see one) into account to limit the
> effect of this trailing-array-supporting, so it effectively only applies to
> indirect accesses (and the padding example above, you can use the whole
> padding if DECL_SIZE allows that).
OK, so we want the attached patch? FWIW it passed
make -k check-c check-c++ RUNTESTFLAGS="compat.exp struct-layout-1.exp"
on x86/Linux, x86-64/Linux, PowerPC/Linux [*], IA-64/Linux, SPARC/Solaris and
SPARC64/Solaris with ALT_CC_UNDER_TEST set to the unpatched compiler.
[*] the failures (DFP related) are the same as with the unpatched compiler.
--
Eric Botcazou
Index: stor-layout.c
===================================================================
--- stor-layout.c (revision 205881)
+++ stor-layout.c (working copy)
@@ -1605,6 +1605,15 @@ compute_record_mode (tree type)
|| ! tree_fits_uhwi_p (DECL_SIZE (field)))
return;
+ /* As a GNU extension, we support out-of-bounds accesses for a trailing
+ array in a record type. In this case, if the element type has a non
+ zero size, then the record type effectively has variable size so it
+ needs to have BLKmode. */
+ if (!DECL_CHAIN (field)
+ && TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
+ && !integer_zerop (TYPE_SIZE (TREE_TYPE (TREE_TYPE (field)))))
+ return;
+
/* If this field is the whole struct, remember its mode so
that, say, we can put a double in a class into a DF
register instead of forcing it to live in the stack. */
