RE: Trouble with stdarg on ia64
We took a liberal view of return values from undeclared functions. These
default to "int" according to the standards but unlike Intel and gnu
compilers, we did not clear the upper 32 bits. Instead, we allowed the store
operation to deal with the type and size. Values returned from functions
that returned a long or pointer were okay even if there wasn't a function
prototype. We also made the choice to avoid parameter cleaning on function
calls for similar reasons. We were an early 64 bit system and knew it would
be difficult to port many of the 32 bit applications at the time. These and
other decisions were made to make it as easy as possible. So it's possible
that code ported to Alpha isn't quite clean enough to run on IPF.
> -----Original Message-----
> From: Martin Buck [mailto:firstname.lastname@example.org]
> Sent: Monday, April 28, 2003 6:32 PM
> To: Stefan Schroepfer
> Cc: email@example.com; firstname.lastname@example.org
> Subject: Re: Trouble with stdarg on ia64
> On Tue, Apr 29, 2003 at 12:11:18AM +0200, Stefan Schroepfer wrote:
> > "Ported to Alpha" doesn't necessarily mean "ported to 64-Bit".
> > Remember: The DEC linker has/had a "magic" switch to turn all
> > addresses into 32-Bit. This particular feature wasn't available
> > in earlier Linux/Alpha versions.
> I can't remeber me using any special linker switches and longs were
> definitely 64 bits. And sizeof(long)!=sizeof(int) is what's now causing
> problems on IA64 (XView basically treats everything as longs, and pointers
> happen to fit in there).
> I guess the main difference is the fact that the Alpha ABI guarantees that
> if the caller passes an int but the callee expects a long, then the upper
> 32 bits of the long are properly sign- or zero-extended. On IA64, they're
> undefined. :-(
> But hacking gcc is definitely not something I'm prepared to do
> just to make
> XView work...
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact