From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31945 invoked by alias); 6 May 2009 11:46:04 -0000 Received: (qmail 31620 invoked by alias); 6 May 2009 11:45:10 -0000 Date: Wed, 06 May 2009 11:46:00 -0000 Message-ID: <20090506114510.31619.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: "rguenther at suse dot de" 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/msg00449.txt.bz2 ------- Comment #17 from rguenther at suse dot de 2009-05-06 11:45 ------- Subject: Re: [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c On Wed, 6 May 2009, matz at gcc dot gnu dot org wrote: > ------- Comment #16 from matz at gcc dot gnu dot org 2009-05-06 11:20 ------- > 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. I'm all for option (1), but concering (2) - a packed structure does have alignment 1, so how can we derive anything but alignment 1 from (the sizes of, supposedly) other members? That is, we would have to build an explicitly aligned _decl_ of the packed type to be able to derive more than 1 alignment. No? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954