Re: libgcj/6092: sparc-sun-solaris2.7 gcc-3.1 has hundreds of libjava failures with -m64

[Tom Tromey <tromey@redhat.com>]

The following reply was made to PR libgcj/6092; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: "David S. Miller" <davem@redhat.com>
Cc: davem@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libgcj/6092: sparc-sun-solaris2.7 gcc-3.1 has hundreds of  libjava failures with -m64
Date: 19 Apr 2002 19:38:58 -0600

 >>>>> "David" == David S Miller <davem@redhat.com> writes:
 
 David> If it is a GC problem, is it Solaris specific.
 
 That's right.
 
 David> I bet it is a non-working definition of STACKBOTTOM or similar.
 David> The CPP_WORDSZ protection of DYNAMIC_LOADING for Solaris in
 David> gcconfig.h seems suspicious too.
 
 Thanks.  I've played with it a little but haven't seriously debugged
 it yet.  Hans has given a lot of good advice though.
 
 David> As Richard has told me numerous times, we need some description
 David> language for this stuff so we only need to do it in one file.
 
 I completely agree.  Right now libffi has two APIs.  Sometimes people
 write one but not the other.  For instance there is no Sparc port of
 the raw API; this means the libgcj bytecode interpreter doesn't work
 there.  I'd love it if doing a base gcc port meant that all of libffi
 (and thus the hardest-to-port parts of libgcj) were done
 automatically.
 
 Tom