This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: java/5794: gcj fails to verify .class file generated by Sun JDK1.4 compiler
Eric Blake writes:
> Tom Tromey wrote:
> >>>>>>"Jesse" == Jesse Rosenstock <jmr@ugcs.caltech.edu> writes:
> > Jesse> As previously discussed, I commented out the check that the
> > Jesse> exception handler target is outside of the range of the code
> > Jesse> the exception handler is for. This is not dangerous, the worst
> > Jesse> it could cause is an infinite loop.
> >
> > Also see Andrew's pending patch to turn this into a warning. I think
> > his approach makes sense, since it is unlikely that such bytecode has
> > a useful meaning.
>
> This does have useful meaning, and JDK 1.4.0 and above, as well as jikes
> 1.16 and above, now generate such bytecode. Sun has recently begun to
> insist that with the synchronized statement, that ALL possible
> instructions until a monitorexit has successfully executed be covered by
> a handler. This is because an asynchronous exception might occur, but
> the compiler must guarantee that no exception can interrupt the release
> of the monitor. In short, Sun no longer follows the 2nd bullet of JVMS
> 4.9.5.
In which case maybe I'd better remove the warning.
However, perhaps I'd better not do so until we make sure that the code
generated is correct. Do you know of a suitable test case?
Andrew.