[RFC/RFT] Patch (java): Switch to new verifier

[Ranjit Mathew]

Hi,

  The attached patch proposes to switch GCJ to use the new
verifier. If approved and found to be reliable enough (please
help test), I'll submit a patch to remove the then redundant
old verifier code separately.

I have tested this on i686-pc-linux-gnu, Jacks included, and
I get no new failures, but I do get:

  XPASS: pr13107_2 compilation from bytecode
  XPASS: pr13107_2 -O3 compilation from bytecode
  XPASS: pr13107_3 compilation from bytecode
  XPASS: pr13107_3 -O3 compilation from bytecode

In the Mauve verifier testsuite, I see an improvement
of FAILs from 35 to just 15. I do see an "interesting"
failure here though (glibc 2.3.4):

/extra/src/verify/build > $MYGCJ -c locals/fail/toofew.class
locals/fail/toofew.j: In class 'locals.fail.toofew':
locals/fail/toofew.j: In method
'locals.fail.toofew.doit(java.lang.String[])':
locals/fail/toofew.j:0: error: verification failed: invalid local variable
*** glibc detected *** free(): invalid pointer: 0x084d7740 ***
locals/fail/toofew.j:0: confused by earlier errors, bailing out

FWIW, the new verifier does seem a bit slower than
the old one, but it sure is a *lot* more comprehensive and
correct in a lot of cases.

Without the change to build_java_array_length_access, I get
a FAIL in the "Array_3 -O3 bytecode -> native" test. You can
see it even now by using -findirect-dispatch with a method
like:

  int foo( )
  {
    int[] x = (int[] )null;
    int y = x.length;
    return 666;
  }

At -O3, the "y = x.length" part seems to be thrown away
even though it could SEGFAULT. Whether this is a fault
of the front-end or the middle-end or whatever, we seemed
to have a special case to handle it explicitly and
for some reason, we were disabling it for the new verifier.

OK for mainline?

Thanks,
Ranjit.

-- 
Ranjit Mathew       Email: rmathew AT gmail DOT com

Bangalore, INDIA.     Web: http://ranjitmathew.hostingzero.com/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: t1.txt
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20050228/d57599d3/attachment.txt>