From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3069 invoked by alias); 9 Mar 2010 19:46:29 -0000 Received: (qmail 3060 invoked by uid 22791); 9 Mar 2010 19:46:28 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 09 Mar 2010 19:46:24 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o29JkMKM004615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Mar 2010 14:46:22 -0500 Received: from zebedee.pink (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o29JkKUW025250; Tue, 9 Mar 2010 14:46:21 -0500 Message-ID: <4B96A58B.6010503@redhat.com> Date: Tue, 09 Mar 2010 19:46:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: thomas.martitz@student.HTW-Berlin.de CC: 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 Content-Transfer-Encoding: 7bit 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/msg00125.txt.bz2 On 03/09/2010 06:54 PM, Thomas Martitz wrote: > 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. Yeah, it's a bug. Mind you, it's pretty bizarre code: I'm not surprised we never came across this before. Why are you doing this, anyway? I would have expected char __attribute__((aligned(8))) *member; for a pointer to an 8-aligned buffer... Andrew.