User account creation filtered due to spam.
This is a very small testcase, in which the code generated by gcj does not
behave correctly at runtime. I set the severity as critical because there is no
notification that something went wrong while the wrong method gets called, and I
see no workaround.
I suppose that there is a problem either with an instanceof test, or with the
implementation of invokespecial. Feel free to update the summary if this turns
out to be the wrong intuitition.
Attached are three small bytecode classes (I could not reproduce the bug from
# Normal behaviour, using Sun's JDK
$ java test.fun
$ gcj --main=test.fun test/*.class
Tested with gcj 4.0.0 20050212.
Created attachment 8219 [details]
Well it cannot be really that critial because nobody has hit this before.
This bug occurs in 3 places.
* In the interpreter and the old abi, the problem is similar.
We do not properly implement the ACC_SUPER semantics of the
invokespecial opcode. The fix in both these cases is similar,
the "invokespecial Object.equals" must be changed into a
non-virtual call to "A.equals"
* In the BC ABI, the problem is the same, but the solution is different.
We can't search the concrete class hierarchy in the compiler.
Instead we must emit an atable (not otable, as the resulting call
will be nonvirtual) reference for the method. However, it must be
a special atable reference, since we cannot know the precise name
of the declaring class. One approach to fixing this would be to
emit a name like "+ClassNameHere" to indicate that we must search.
Or, better, some magic value like (void*)1 or NULL would suffice here
(since we know we must always start the search with the current class'
Daniel, could you post the actual source for those classes? Thanks, Ben
As I recall the original test case was written in 'nice', not in java.
The sources may be of limited usefulness here.
This should now be fixed on trunk and 4.1 branch.
I tried this today with svn head.
The test program still prints 'false' no matter how I run it:
gij, compiled, or compiled with the BC ABI.
Closing as won't fix as the Java front-end has been removed from the trunk.