User account creation filtered due to spam.

Bug 20044 - Wrong method call semantics (maybe instanceof/invokespecial)
Summary: Wrong method call semantics (maybe instanceof/invokespecial)
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Andrew Haley
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2005-02-17 23:49 UTC by Daniel Bonniot
Modified: 2016-09-30 22:49 UTC (History)
3 users (show)

See Also:
Host: i386-debian-linux-gnu
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-07-19 03:52:21


Attachments
testcase (1.02 KB, application/x-gtar)
2005-02-17 23:49 UTC, Daniel Bonniot
Details

Note You need to log in before you can comment on or make changes to this bug.
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.