Patch: Fix PR 23891 / Eclipse bootstrap

[Bryce McKinlay]

Bootstrapping of gcj-compiled native Eclipse, which uses gcj to build 
Eclipse's own bytecode compiler, ecj, broke recently on both HEAD and 
the 4.0 branch.

The problem is that when folding constants which depend on other 
constants, the current_class context is pushed, but the package context 
(cxtp->context) is not, so it attempts to resolve using the wrong 
package. This regression was introduced (and subsequently backported to 
the 4.0 branch) with the fix for java/17845. Although that patch itself 
is correct, it exposed this problem by removing a (bogus) fallback case 
where gcj would search in all known packages for a class definition.

 This patch fixes the problem by introducing a TYPE_PACKAGE lang 
specific field, and changing do_resolve_class so that the package is 
determined based on current_class and not ctxp->package which may not be 
valid except during parsing. Adding TYPE_PACKAGE also allows other parts 
of the compiler to be simplified, eg class_in_current_package().

No libjava testsuite regressions, and ecj now builds. However, currently 
I see the following changes in JACKS results with this patch applied:

FAIL: 15.9.1-qualified-concrete-24
XPASS: 15.12.2.1-accessibility-method-2
FAIL: 15.12.2.1-accessibility-method-3
XPASS: 15.12.2.1-accessibility-method-4
FAIL: 15.12.2.1-accessibility-method-5

These are cross-package hidden member visibility tests. They seem to be 
cases that we "accidentally" passed or failed for the wrong reasons 
previously. Even if they compiled before, the code generated was 
unlikely to be correct. I think that given the need for this patch to 
get Eclipse working again, they can be addressed in a follow up patch.

OK to commit?

Bryce

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PR23891.patch
Type: text/x-patch
Size: 5650 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20050915/5b2752a4/attachment.bin>