Re: Patch: Fix MIPS wrong code regression for java front-end.

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > The java front-end is setting DECL_EXTERNAL properly for some symbols.  
 > This causes the MIPS back-end to generate incorrect function call code 
 > for the effected symbols.  According to the comments in:
 > 
 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
 > 
 > It seems that hpux is experiancing the same problem.
 > 
 > As noted in: http://gcc.gnu.org/ml/gcc/2007-02/msg00016.html
 > 
 > <quote>
 > The bad code was in class.c when green committed it over 8 years ago.  
 > Several months ago Tromey removed it and then added it back a few days 
 > later.
 > 
 > The problem is that in is_compiled_class() we were erroneously saying 
 > that a candidate class was being emitted to the object file *if* it was 
 > the current_class being parsed.  This does not hold because many classes 
 > are parsed that are not emitted so that jc1 can calculate the class 
 > layout and load the symbol tables.
 > 
 > The real fix,I think, is the one I made to is_compiled_class().  I left 
 > the change to layout_class_method() where we don't re-check for 
 > DECL_EXTERNAL if it is already set as a micro-optimization.  I tested 
 > both with and without this and obtained correct results, so it is not 
 > really needed.
 > </quote>
 > 
 > This fixes at least some of the MIPS regressions caused by the 
 > gcj-eclipse merge, also tested with a bootstrap of c,c++,java on 
 > x86_64-pc-linux-gnu with no regressions.
 > 
 > OK for the trunk?
 > 
 > gcc/java:
 > 2007-02-01  David Daney  <ddaney@avtrex.com>
 > 
 >     * class.c (is_compiled_class): Move check to avoid reloading
 >     current class.
 >     (layout_class_method): Don't calculate DECL_EXTERNAL if it is
 >     already set.

OK.  Ping me when it's in and I'll merge to
gcc-4_1-branch-java-merge-20070117.  We really do nee it on that
branch, as we are seeing related failures on PPC64.

Thanks,
Andrew.