From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4103 invoked by alias); 9 Mar 2010 19:11:38 -0000 Received: (qmail 4087 invoked by uid 22791); 9 Mar 2010 19:11:37 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail2.rz.htw-berlin.de (HELO mail2.rz.htw-berlin.de) (141.45.10.102) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 09 Mar 2010 19:11:31 +0000 Envelope-to: gcc-help@gcc.gnu.org Received: from e178085094.adsl.alicedsl.de ([85.178.85.94] helo=[192.168.178.2]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Np4q0-0009Zf-VG for gcc-help@gcc.gnu.org; Tue, 09 Mar 2010 20:11:29 +0100 Message-ID: <4B969D5F.6080501@htw-berlin.de> Date: Tue, 09 Mar 2010 19:11:00 -0000 From: Thomas Martitz Reply-To: thomas.martitz@student.htw-berlin.de User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100307 Icedove/3.0.3 MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Re: Problems migrating to gcc 4.4.3&eabi - apparently a gcc bug References: <4B9677C1.6040502@htw-berlin.de> <4B967A4D.8060905@redhat.com> <4B968150.8010004@htw-berlin.de> <4B96953E.10305@redhat.com> <4B96994D.40904@htw-berlin.de> In-Reply-To: <4B96994D.40904@htw-berlin.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg00122.txt.bz2 Am 09.03.2010 19:54, schrieb Thomas Martitz: > Am 09.03.2010 19:36, schrieb Andrew Haley: >> That does not surprise me. I think you're seeing a problem that is >> caused by something elsewhere in your program. I'm guessing that >> there may be a bad prototype or somesuch. >> >> I think you need to strip down your sources until you find something. >> >> Maybe you should try -save-temps and have a look at the actual >> preprocessd source. Maybe some bastard has done >> >> #define int long >> >> or something evil like that! >> >> Andrew. > > No, I know our codebase pretty well. This is not the problem. Not that > int or long matters, anyway. > > In the mean time we found a test case: > > ---- > void foo(int last, char * block); > > void bar(void) > { > struct { > char * __attribute__((aligned(8))) member; > } s; > > foo(0,s.member); > } > ---- > > compiled with arm-elf-eabi-gcc -c test.c > > This example exposes the problem. > > We found the problem is related to struct addressing and the aligned > attribute. > > - normal stack variables work > - struct members work with __attribute__((aligned(4))) > - struct members with __attribute__((aligned(X))) where X >= 8 *do > not* work. > > Look at the assembly output for this very example. block is passed in > r2, while it's supposed to be passed in r1. > > Our temporary "fix" is to make it "void foo(int last, volatile char * > block);" [notice the volatile keyword] and it works as well (block > passed in r1). > > This is definitely a gcc bug. The generated call is dependent on the > parameter passed. The callee can't know about this. And it also > happens with -O0. > > > Best regards. A bit more on this issue. In the rockbox code, this struct member caused the behavior: int16_t * ATTR_ALIGN(16) DCTblock; /* put buffer separately to have it in IRAM */ Actually we don't need the pointer to be 16byte aligned, but the buffer it points to. Hence, removing the ATTR_ALIGN(16) (a #define for __attribute__((aligned(X)) ) works for us. Nevertheless, it is a gcc bug. It seems likely that gcc confuses something here 64bit values must be 8byte aligned afaik. On ARM EABI, 64bit types need to be passed into an even (and the next odd, e.g. r2 and r3) registers. Maybe now treats all 8+ byte aligned data as 64bit, which would explain why it wants to put normal 32bit into even registers, which violates the calling convention. Best regards.