asynchronous_exceptions

[Andrew Haley <aph at redhat dot com>]

Richard Henderson writes:
 > 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.

Yes, we know it's something that needs attention.  When we first did
this work it seemed that this would solve our problems with divide
overflows and null pointer traps.

 > 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.)

We already do that for a couple of CPUs.  However, there are real
problems with this approach.  For example, sched can move memory
accesses into prologues and prevent the unwinder from working.

 > 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.

That would help a lot.  

 > 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.

Will this ensure memory accesses aren't moved out of their try blocks
by cse and/or sched?

Andrew.