Bug 20044

Summary: Wrong method call semantics (maybe instanceof/invokespecial)
Product: gcc Reporter: Daniel Bonniot <bonniot>
Component: javaAssignee: Andrew Haley <aph>
Status: RESOLVED WONTFIX    
Severity: normal CC: aph, gcc-bugs, java-prs
Priority: P2 Keywords: wrong-code
Version: 4.0.0   
Target Milestone: ---   
Host: i386-debian-linux-gnu Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2006-07-19 03:52:21
Attachments: testcase

Description Daniel Bonniot 2005-02-17 23:49:12 UTC 
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
Java sources).

# Normal behaviour, using Sun's JDK
$ java test.fun
true

$ gcj --main=test.fun test/*.class
$ ./a.out
false

Tested with gcj 4.0.0 20050212.
Comment 1 Daniel Bonniot 2005-02-17 23:49:55 UTC 
Created attachment 8219 [details]
testcase
Comment 2 Andrew Pinski 2005-02-17 23:51:03 UTC 
Well it cannot be really that critial because nobody has hit this before.
Comment 3 Andrew Pinski 2005-02-18 00:00:09 UTC 
Confirmed.
Comment 4 Tom Tromey 2005-02-18 00:53:07 UTC 
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'
  superclass)
Comment 5 Ben Konrath 2005-05-04 17:45:50 UTC 
Daniel, could you post the actual source for those classes? Thanks, Ben
Comment 6 Tom Tromey 2005-05-04 20:53:40 UTC 
Ben -- 

As I recall the original test case was written in 'nice', not in java.
The sources may be of limited usefulness here.
Comment 7 Andrew Haley 2005-12-15 15:54:00 UTC 
This should now be fixed on trunk and 4.1 branch.
Comment 8 Tom Tromey 2006-03-29 22:39:24 UTC 
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.
Comment 9 Andrew Pinski 2016-09-30 22:49:13 UTC 
Closing as won't fix as the Java front-end has been removed from the trunk.