From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21182 invoked by alias); 9 Mar 2010 17:11:55 -0000 Received: (qmail 21166 invoked by uid 22791); 9 Mar 2010 17:11:54 -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 17:11:48 +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 1Np2yA-000C34-Cu for gcc-help@gcc.gnu.org; Tue, 09 Mar 2010 18:11:46 +0100 Message-ID: <4B968150.8010004@htw-berlin.de> Date: Tue, 09 Mar 2010 17: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> In-Reply-To: <4B967A4D.8060905@redhat.com> 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/msg00119.txt.bz2 Am 09.03.2010 17:41, schrieb Andrew Haley: > On 03/09/2010 04:30 PM, Thomas Martitz wrote: > > >> EABI IIRC only mentions changed rules for passing 64bit types. This call >> should have been the same with 4.4.3. It eventually is if the parameters >> are in a different order. >> >> If this is really a gcc bug, how should we proceed? I assume a bug >> report on bugzilla? >> > This is very strange. Can you make a self-contained source file that shows > the problem on its own? We need to be able to try it. It doesn't have to > run, we just have to see the source it generates. > > Andrew. > I tried, but the following code doesn't show this problem :( ----- #define NULL (void*)0 typedef signed short int16_t; typedef unsigned char uint8_t; void foo(const int last, int16_t * block, uint8_t * dest, const int stride); int main(void) { const int a = 2, d = 3; int16_t *b = NULL; uint8_t *c = NULL; foo(a,b,c,d); return 0; } ----- compiled with arm-elf-eabi-gcc arm-elf-eabi-gcc -O0 -c -W -Wall -Wundef -nostdlib -ffreestanding -Wstrict-prototypes -pipe -mcpu=arm9tdmi -fomit-frame-pointer -Wno-pointer-sign -fno-strict-aliasing -Wno-override-init -O0 -c test-arm.c (that is the rockbox command line, stripped from a bunch of -I and -D) Best regards.