Re: [Patch] PR java/9685: Fix Catching Illegal Access to Package-PrivateFields/Members

[Ranjit Mathew <rmathew at gmail dot com>]

Tom Tromey wrote:
> Bryce> This patch looks good to me (see comments below), but Andrew or Per
> Bryce> will have to approve it. Did you run it against the jacks testsuite?
> Bryce> Hopefully it should fix some failures there.
> 
> Yeah, I think we should require that any (with exceptions for the
> weird situations) front end change be tested against Jacks and either
> accompanied by a new test case or a deletion from the Jacks xfail
> file.  Actually I'd like to go further and require that no new Jacks
> regressions ever be added.

I ran Jacks explicitly limiting the heap size because
of the problem I was facing with it and GCJ as explained
in:

   http://gcc.gnu.org/ml/java/2004-04/msg00232.html

With these "cheat runs" I see that my patch -

Turns FAILs into PASSes for:

  8.1.3-superclass-5
  8.8.7-inaccessible-default-constructor-toplevel-2
  15.9.1-qualified-concrete-24
  15.12.2.1-accessibility-method-2
  15.12.2.1-accessibility-method-4

Turns PASSes into FAILs ( :-( ) for:

  15.12.2.1-accessibility-method-3 PASSED
  15.12.2.1-accessibility-method-5 PASSED

I do not immediately understand the reasons
these two are failing - my Java language-laywer
skills are rather limited - and would appreciate
any insight into why GCJ thinks that the methods
in question should have package-private access.

BTW, for the current mainline (unpatched) GCJ and
Jacks, I get on i686-pc-linux-gnu:

  Total 4919
  Passed 4001
  Skipped 68
  Failed 850

for just the Jacks testsuite. Are these results in
line with what others see?

(After my patch, "Passed" become 4004 and "Failed
become 847.)

Thanks,
Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT gmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/