patch for sparc 'long long' vararg failures

Geoff Keating geoffk@geoffk.com
Thu Nov 9 00:16:00 GMT 2000


> Date: Thu, 9 Nov 2000 02:04:48 -0500
> From: Jakub Jelinek <jakub@redhat.com>

> On Wed, Nov 08, 2000 at 04:21:46PM -0800, Geoffrey Keating wrote:
> > 
> > This fixes the following testsuite failures on sparc:
> 
> This is what my http://gcc.gnu.org/ml/gcc-patches/2000-04/msg00690.html
> patch was about, but was not installed because rth wanted to do it using
> ADDRESSOF which I haven't written yet.

That's what the first FIXME is about.  However, in the long term we
don't want to do any of this at all, instead we want to do it all with
trees and just return the equivalent of

((unsigned *)addr_rtx)[0] << 32 | ((unsigned *)addr_rtx)[1]

as this would let GCC do things like better handle:

unsigned t = va_arg (v, unsigned long long);

by optimising out a memory reference.

As I said, though, this requires changing all the backends which is
more work than I can do right now.

> I'm not 100% sure your patch won't do unnecessary things with say 10 byte
> structure on sparc64 (that can have alignment just BITS_PER_WORD), so
> it should at least be guarded by TARGET_ARCH32.

It doesn't.  The test in the patch checks only to see if the alignment
we know we have (which is BITS_PER_WORD) is less than the alignment
required by the type (TYPE_ALIGN xxx).  If the type is only aligned to
BITS_PER_WORD, then no copying will be done.  (Note that when
TARGET_ARCH64, of course BITS_PER_WORD is 64.)

In fact, for TARGET_ARCH64, 'align' will not be zero in the
interesting case anyway.


Anyway, please feel free to try to fix this area better.  You can see
from the FIXMEs I'm not completely happy about it either.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


More information about the Gcc-patches mailing list