This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
asynchronous_exceptions
- To: java-discuss at sources dot redhat dot com
- Subject: asynchronous_exceptions
- From: Richard Henderson <rth at redhat dot com>
- Date: Thu, 14 Dec 2000 00:43:14 -0800
- Cc: gcc at gcc dot gnu dot org
What, exactly, does this get used for in the java runtime?
As far as I can tell, the implementation of this in the generic part
of the compiler is completely broken, and has quite possibly never
Really Worked.
Further, I find indications in gcc/java/decl.c that you want to throw
from inside signal handlers, which will not work properly with dwarf2
EH as-is. (We'd need cpu+os specific code to help us interpret the
signal stack frame.)
What I'm thinking of doing is putting in a language-specific hook
allowing the front end to indicate whether a may_trap_p insn may
throw an exception, and if so, what set of exceptions might be seen.
(The exact interface for the later I havn't thought about too much.)
This cleanup will allow two things: One, we'll be able to create
correct control-flow graphs for things besides calls. Two, I'll
be able to remove NOTE_INSN_EH_REGION notes during the main body
of compilation and rely entirely on REG_EH_REGION tags. This will
in turn simplify several optimization passes.
r~