This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
RE: Many Failures In libjava Testsuite!
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: <tromey at redhat dot com>, "Bryce McKinlay" <mckinlay at redhat dot com>
- Cc: "Kelley Cook" <kcook at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>,<java-patches at gcc dot gnu dot org>, "Nathanael Nerode" <neroden at gcc dot gnu dot org>
- Date: Wed, 1 Dec 2004 09:29:49 -0800
- Subject: RE: Many Failures In libjava Testsuite!
Good point. I had forgotten than GC_LINUX_THREADS also gets
defined this way.
There is actually an alternative here. If you unconditionally define
GC_THREADS before including gc.h, gc_config_macros.h (included from
gc.h) should define the right platform-dependent GC_..._THREADS
macro for you, precisely to address this problem. But this has
probably not been exhaustively tested on all platforms. (If it
breaks somewhere, the fix will be pretty obvious.)
Eventually we should switch to just defining GC_THREADS.
Whether this should happen for 4.0 is another issue.
Hans
> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org
> [mailto:java-patches-owner@gcc.gnu.org]On Behalf Of Tom Tromey
> Sent: Wednesday, December 01, 2004 8:33 AM
> To: Bryce McKinlay
> Cc: Kelley Cook; gcc-patches@gcc.gnu.org; java-patches@gcc.gnu.org;
> Nathanael Nerode
> Subject: Re: Many Failures In libjava Testsuite!
>
>
> >>>>> "Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:
>
> Bryce> I suspect there will still be problems with only
> THREAD_LOCAL_ALLOC
> Bryce> defined - see PR 18699. These problems didn't show up in the
> Bryce> regression suite for me, only with the TT.java file
> given in that PR.
>
> On my machine, gc_config.h defines GC_LINUX_THREADS. This is
> examined by gc_config_macros.h to define GC_PTHREADS. This in turn
> is examined by gc.h to include gc_pthread_redirects.h, which is
> needed for the GC to intercept various pthread calls.
>
> Kelley, this general idea looks ok to me. I would suggest changing
> the logic to remove the problem defines and leave the rest. But, it
> would be prudent to wait for the test case before committing anything.
>
> Tom
>