java/5794: gcj fails to verify .class file generated by Sun JDK 1.4 compiler

[Andrew Haley]

Per Bothner writes:
 > Jesse Rosenstock wrote:
 > 
 > > In case the patch is ok, a ChangeLog entry:
 > > 
 > > 2002-09-03  Jesse Rosenstock  <jmr@ugcs.caltech.edu>
 > > 
 > >         For PR java/5794:
 > >         * verify.c (verify_jvm_instructions): Don't require that the
 > >         exception handler target doesn't overlap the range it's guarding.
 > >         For OPCODE_jsr, only push the return label if a ret instruction
 > >         for the jsr has been reached.
 > 
 > Could you split up the patch, and check them in separately?  (You don't
 > need to re-run the testsuite separately.)
 > 
 > --- verify.c    4 Jun 2002 20:32:08 -0000       1.48
 > +++ verify.c    4 Sep 2002 19:19:23 -0000
 > @@ -470,9 +470,8 @@
 > 
 >         if (start_pc < 0 || start_pc >= length
 >            || end_pc < 0 || end_pc > length || start_pc >= end_pc
 >            || handler_pc < 0 || handler_pc >= length
 > -         || (handler_pc >= start_pc && handler_pc < end_pc)
 >            || ! (instruction_bits [start_pc] & BCODE_INSTRUCTION_START)
 >            || (end_pc < length &&
 >               ! (instruction_bits [end_pc] & BCODE_INSTRUCTION_START))
 >            || ! (instruction_bits [handler_pc] & BCODE_INSTRUCTION_START))
 > 
 > I'm still not really comfortable with this.  I'm be happier with a
 > warning, at least until I get a better explaination of why the bytecode
 > makes sense.

Ah, I already changed that case to a warning because a fair bit of
case was not being compiled.  I posted the patch and eventually
checked it in as "obvious", which I thought it was.  Looks like I
shouldn't have done so; mea culpa.

Andrew.