From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23409 invoked by alias); 30 Sep 2011 19:20:06 -0000 Received: (qmail 23395 invoked by uid 22791); 30 Sep 2011 19:20:04 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,TW_CR,TW_LW,TW_RX X-Spam-Check-By: sourceware.org Received: from kirk.baltic.net (HELO kirk.baltic.net) (193.189.247.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Sep 2011 19:19:48 +0000 Received: (qmail 9128 invoked by uid 89); 30 Sep 2011 19:19:45 -0000 Received: from p548bcd3b.dip.t-dialin.net (HELO sirius.local) (84.139.205.59) by with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Sep 2011 19:19:45 -0000 Message-ID: <4E861656.8060308@users.sourceforge.net> Date: Fri, 30 Sep 2011 20:31:00 -0000 From: Gunther Nikl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100317 SeaMonkey/1.1.19 NOT FireFox/2.0 MIME-Version: 1.0 To: Fabian Cenedese CC: gcc-help@gcc.gnu.org Subject: Re: Old gcc method parameter error References: <5.2.0.9.1.20110929090457.047063b8@localhost> In-Reply-To: <5.2.0.9.1.20110929090457.047063b8@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2011-09/txt/msg00263.txt.bz2 Fabian Cenedese wrote: > I have a problem with an old gcc 2.95.2. If you really need GCC 2.95, then you should use the latest version from the GCC 2.95 CVS branch. > Before you say that I should update I can tell you that we have > a new gcc4.5 based toolchain. But we still need to support existing > projects that work with the old compiler. But if the old compiler has a bug, what are you going to do? And what you are describe later seems to be a bug of GCC 2.95.2/2.95.3. > This is a cross-compiled gcc for PowerPC-EABI (e.g. 603, 750 etc) > > The problem is with the way the parameters are placed on the stack if there's > not enough space in the registers (r3-r10, f1-f8). > > unsigned long MyClass::Func(unsigned long a1, unsigned long a2, unsigned long a3, unsigned long a4, > unsigned long a5, unsigned long a6, unsigned long a7, unsigned long a8, double d, char* s) > { > printf("Received string: '%s'.", s); > return 0; > } > > void MyClass::Func2() > { > Func(1, 2, 3, 4, 5, 6, 7, 8, 9.9, "testing"); > } FWIW, GCC 4.5.0 complained the string argument. > I'd expect that r3 would hold the 'this' pointer, r4-r10 would hold the first > seven arguments, f1 would hold the double value and a8 and the string > pointer would be passed on the stack as two consecutive values > (e.g. x+8 and x+12, x is some offset in the stack). > > The problem is now that the caller exactly does the described thing, > but the called function expects a different layout on the stack. The > string pointer is read from x+16 where of course no useful value is > stored. It's as if it thinks that at x+12 should be the double value > which makes no sense as this would need 8 bytes anyway. If I take > out the double value from the argument list then the two values are > as expected. > > This function and the call are in the same file so any compiler flag > (calling convention) would apply to both places. > > Does this ring a bell? I already tried to look at the diff to gcc 2.95.3 > to find if this may have been solved but I couldn't understand the > gcc internal termini. I can understand if nobody has interest in > compiler archeology but I thought I'd ask anyway. I am in no way a PPC expert, but AFAICT it seems to me that GCC 2.95.2/GCC 2.95.3 had a bug with argument passing and it looks like that the bug is fixed with 2.95.4 (from the CVS branch of GCC 2.95): @@ -25,7 +25,7 @@ stfd 1,40(31) lis 9,.LC0@ha la 3,.LC0@l(9) - lwz 4,80(31) + lwz 4,76(31) crxor 6,6,6 bl printf li 3,0 @@ -139,4 +139,4 @@ blr .Lfe3: .size Func2__7MyClass,.Lfe3-Func2__7MyClass - .ident "GCC: (GNU) 2.95.2 19991024 (release)" + .ident "GCC: (GNU) 2.95.4 20020320 (prerelease)" Regards, Gunther