Re: aliasing problem with va_arg

[Mark Mitchell <mark@markmitchell.com>]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

    Jim> The sparc ABI does not align double-word arguments to a
    Jim> double-word boundary.  The sparc ldd instruction requires
    Jim> double-word alignment.  Thus we can't use an ldd instruction

Thanks.  That explains why the macro was doing what it was.  One other
ANSI C solution to this problem is to use `memcpy'.  Obviously, the
performance of even the builtin memcpy may not be ideal, especially if
it can't figure out that the storage will be word-aligned.

But, the short answer will be that this oddity of the SPARC ABI makes
efficient va_arg macros that are compliant ISO C just about
impossible; you can't access the memory with the type that it really
has, so you can only use `char'.  I suppose inline assembly is another
option.

I suggest that you proceed with your partially implemented
__builtin_va_arg support.  I think that your assertion that all 30
ports will have to be changed is false; only those with non-compliant
va_arg macros need to be changed.  It doesn't look to me like the MIPS
port does the same kind of trickery as the SPARC port, so I don't see
(at first glance) that it's va_arg macros will cause problems.

It looks like the PA port also does something odd with va_arg
involving treating a `char*' as an `int*' so it too probably needs
fixing.  I suggest that we finish up the machine-independent builtin
support, which seems better than doing other weird hacks because it
can't really be that hard and is something we know we want to do, and
then provide the machine-dependent implementations for it on the PA
and SPARC ports, if the PA macros cannot be fixed.

At that point we can also remove the bits in alias.c that disable
alias analysis for varargs functions.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com