On Wed, Dec 11, 2013 at 8:19 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>> 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.
+ /* 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)
The next field may be a TYPE_DECL with
struct { char c[8]; typedef int x; };
Instead I'd suggest to keep a 'last_field_array_p' flag that you can
check at the end of the loop.
+ && TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
+ && !integer_zerop (TYPE_SIZE (TREE_TYPE (TREE_TYPE (field)))))
+ return;
+
Why does this exclude zero-sized element types? That looks odd to me ;)
Btw, the loop already has
if (TREE_CODE (TREE_TYPE (field)) == ERROR_MARK
|| (TYPE_MODE (TREE_TYPE (field)) == BLKmode
&& ! TYPE_NO_FORCE_BLK (TREE_TYPE (field))
&& !(TYPE_SIZE (TREE_TYPE (field)) != 0
&& integer_zerop (TYPE_SIZE (TREE_TYPE (field)))))
|| ! tree_fits_uhwi_p (bit_position (field))
|| DECL_SIZE (field) == 0
|| ! tree_fits_uhwi_p (DECL_SIZE (field)))
return;
which then is supposed to
handle struct { struct { char c[8]; } a; } - but it seems to
special-case zero-sized
members again, thus struct { struct { char c[0]; } a; } would still be
broken after
your patch?
The issue Bernd raises is real as well, though we probably should fix this
in a different way by using a different DECL_MODE based on the types
size for asm register vars?
Btw, do you think we can recover from some of the now BLKmodes by
having DECL_MODE != TYPE_MODE?
Thanks,
Richard.
> --
> Eric Botcazou
