From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21265 invoked by alias); 6 May 2009 11:21:24 -0000 Received: (qmail 20763 invoked by uid 48); 6 May 2009 11:20:31 -0000 Date: Wed, 06 May 2009 11:21:00 -0000 Message-ID: <20090506112031.20762.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "matz at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00443.txt.bz2 ------- 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