From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31143 invoked by alias); 20 Feb 2007 17:06:52 -0000 Received: (qmail 31128 invoked by uid 48); 20 Feb 2007 17:06:44 -0000 Date: Tue, 20 Feb 2007 17:06:00 -0000 Message-ID: <20070220170644.31127.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/30826] alignment error when optimizing with inlining In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "sje at cup dot hp dot com" 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: 2007-02/txt/msg02365.txt.bz2 ------- Comment #9 from sje at cup dot hp dot com 2007-02-20 17:06 ------- I did mean 256 bits and not bytes in comment #5. Forcing -fno-inline wouldn't necessarily help, the compiler is forcing the return structure to be 4 byte aligned and it is going to be a 50/50 proposition whether or not it also gets 8 byte aligned by chance. Any optimization that changed the layout of local variables could affect the alignment of the return structure (which might be the local variable or might be a temporary created by GCC). I was able to workaround the bug in inline.c by putting __attribute__ ((aligned(16))) on the declaration of mi. This should work as long as GCC doesn't need to create a temporary for the return value being returned and puts it directly in the mi variable. If it creates a temporary there is no way to control the alignment used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30826