This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ia64 eh, part 20d [libjava]
- To: Richard Henderson <rth at redhat dot com>
- Subject: Re: ia64 eh, part 20d [libjava]
- From: Tom Tromey <tromey at redhat dot com>
- Date: 30 Mar 2001 19:27:15 -0700
- Cc: gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- References: <20010328022455.A14837@redhat.com>
- Reply-To: tromey at redhat dot com
>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:
Richard> * libgcj.spec.in (jc1): Remove EXCEPTIONSPEC.
This should mention removal of -fasynchronous-exceptions. But is that
removal actually correct? Maybe we should use -fnon-call-exceptions?
(Or maybe you added it directly to the compiler? I didn't read the
gcj patches.)
Richard> ! EH_COMMON_INCLUDE='-I$(top_srcdir)/../compat-include'
...
Richard> ! GCC_UNWIND_INCLUDE='-I$(top_srcdir)/../compat-include'
Could you change this to remove the compat-include case?
We only needed that when libgcj could be built in a separate tree from
gcc. I don't see any need to continue to support that.
Maybe simply adding the -I$(top_srcdir)/../gcc/ is best?
Richard> ! /* FIXME: If code == _URC_END_OF_STACK, then we reached top of
Richard> ! stack without finding a handler for the exception. I seem to
Richard> ! recall that Java has specific rules to handle this.
This is a "can't happen" for Java. The Java code for each thread is
run in a try/catch. This catches any otherwise uncaught Java throw
and forwards the exception to the ThreadGroup. See
java/lang/natThread.cc:run_().
I think abort() here is reasonable. You can remove the FIXME.
I don't understand most of the patch. Overall it seems reasonable to
me, but Andrew is really the EH expert.
Tom