User account creation filtered due to spam.

Bug 20044 - Wrong method call semantics (maybe instanceof/invokespecial)
Summary: Wrong method call semantics (maybe instanceof/invokespecial)
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Andrew Haley
Keywords: wrong-code
Depends on:
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
Known to work:
Known to fail:
Last reconfirmed: 2006-07-19 03:52:21

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

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

$ gcj test/*.class
$ ./a.out

Tested with gcj 4.0.0 20050212.
Comment 1 Daniel Bonniot 2005-02-17 23:49:55 UTC
Created attachment 8219 [details]
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
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'
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.