This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Old gcc method parameter error


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]