------- Comment #16 from matz at gcc dot gnu dot org 2009-05-06 11:20 -------
Joseph: I'd need some advise where best starting to fix this. I see some
options, when we want to deal with such construct:
struct S { T member __attribute__((packed)); };
... struct S s; ... &s->member ...
(1) make the type of the FIELD_DECL not be T but an aligned(1) variant
of it. Currently simply DECL_PACKED is set on the FIELD_DECL, but
that's ignored in some contextes, which results in the other options:
(2) make the type of the COMPONENT_REF "s->member" not be T but an aligned(1)
variant of it, and
(3) make the type of the ADDR_EXPR "&s->member" not be T* but (T-aligned1)*.
It seems that option (1) would be the most thorough one as then surely no
other code can accidentally construct an aligned access to it. I think
amending handle_packed_attribute to retroactively patch TREE_TYPE if called
on a FIELD_DECL might do it.
Option (3) I think is the least appealing one, as I'd always fear that there
might be other usages of the COMPONENT_REF than the ADDR_EXPR where the
alignment might matter. It would also mean constructing the pointer type
not from the RHS but using some variant, which seems to introduce a conceptual
inconsistency.
Option (2) lies somewhere in between, although it should be nearly equivalent
to option 1, as there aren't many other contexts than COMPONENT_REF where
a pure FIELD_DECL could be used. But option (2) has the advantage that the
structure type is completely laid out already, not so for option (1). That
might be important for performance sometimes, e.g. when the user declares
a field as packed (or aligned(1)), but it so happens (due to other members)
that it got it's natural alignment in the end. In that case we don't _have_
to construct unaligned types.
--
matz at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joseph at codesourcery dot
| |com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
