I'm not checking this in, I thought I'd ask for comments first.
In PR 26390 we are picking the wrong method to call. If a method m is
declared in A and inherited by B, gcj doesn't realize that this method
is also 'B.m'. In the PR this leads us to choose the wrong method
when making a super call. See the patch for a reduced test case.
This patch is a huge hack. However, I was reluctant to do anything
more complicated since, hopefully, we'll be removing this part of gcj
in the not-so-distant future.
FWIW I think a cleaner fix would look like adding 'invisible' methods
whenever we inherit a method from a superclass (and not just from
interfaces). My concern is that we would then have to unwrap these at
various places to refer to the method as actually declared; and that
there might also be other unknown fallout from doing this.
The idea in the patch is that if we're trying to pick the most
specific method, and we are comparing a method from a class to a
method from an interface, then we pretend that the method from the
concrete class was declared in the qualifying class -- and not its
actual declaring class.
I think this works in all the cases -- when comparing two interface
methods, or two methods from classes, we compare as before; this
leaves the choice of the most specific method unchanged (as compared
to before the patch).
Any method declared in a class will be considered more specific than a
method declared in an interface, but I don't know of a situation where
that can hurt.
This passes jacks and our test suite.