This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]