This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Old gcc method parameter error
- From: Gunther Nikl <gnikl at users dot sourceforge dot net>
- To: Fabian Cenedese <Cenedese at indel dot ch>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Fri, 30 Sep 2011 21:19:50 +0200
- Subject: Re: Old gcc method parameter error
- References: <5.2.0.9.1.20110929090457.047063b8@localhost>
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