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.