From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28945 invoked by alias); 20 Apr 2002 01:36:04 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 28917 invoked by uid 71); 20 Apr 2002 01:36:03 -0000 Date: Fri, 19 Apr 2002 18:36:00 -0000 Message-ID: <20020420013603.28916.qmail@sources.redhat.com> To: davem@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Tom Tromey Subject: Re: libgcj/6092: sparc-sun-solaris2.7 gcc-3.1 has hundreds of libjava failures with -m64 Reply-To: Tom Tromey X-SW-Source: 2002-04/txt/msg01009.txt.bz2 List-Id: The following reply was made to PR libgcj/6092; it has been noted by GNATS. From: Tom Tromey To: "David S. Miller" 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 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