Bug 21722 - gcj miscompiles accesses to static final vars with indirect dispatch
Summary: gcj miscompiles accesses to static final vars with indirect dispatch
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.0.1
: P2 normal
Target Milestone: 4.0.1
Assignee: Tom Tromey
URL:
Keywords:
Depends on: 1259
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-23 16:51 UTC by Michael Matz
Modified: 2005-06-03 05:34 UTC (History)
3 users (show)

See Also:
Host:
Target: i686-linux
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-06-01 21:36:08


Attachments
tarball showing the problem (541 bytes, application/x-tgz)
2005-05-23 16:52 UTC, Michael Matz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Matz 2005-05-23 16:51:00 UTC
Below I attached a tarball which contains two packages with one class each. 
B.java defines a static final String initilized to "foo", and A.java 
tries to call the 'equals' method on that object (and another string). 
This actually is reduced from trang.  The problem happens when this is 
compiled like the doit.sh script does.  I.e. first creating the .class files 
and then compiling both .class files at once into one object file with 
-findirect-dispatch. 
 
The generated program will segfault.  The segfault happens because 
the generated code for A.main() accesses the ->vtable member of the global 
object '_ZN1b1B3FOOE' (== b::B::FOO) directly (if I read the .t03.generic dump 
correctly).  But it is defined like so in the assembler: 
_ZN1b1B3FOOE: 
        .long   _Utf1 
        .section        .rodata.jutf8.10 
 
I.e. the first (and only) member of that symbol actually is the UTF-8 
string itself, not a pointer to the vtable.  But the code trying to resolve 
the address of the 'equals' method assumes so, and hence calls some random 
address. 
 
Note that this is not the same as the usual -findirect-dispatch only supports 
compiling from .class problem.  This is the case here.
Comment 1 Michael Matz 2005-05-23 16:52:03 UTC
Created attachment 8953 [details]
tarball showing the problem
Comment 2 Andrew Pinski 2005-05-23 16:59:49 UTC
Related to PR 1259.
Comment 3 Andrew Pinski 2005-05-23 18:03:47 UTC
Confirmed, I don't get a seg fault but a NPE (NullPointerException) instead.
Comment 4 Tom Tromey 2005-06-01 20:30:01 UTC
Interestingly, if I compile the two .class files separately
and then link the results, it works.
Comment 5 Michael Matz 2005-06-01 20:59:01 UTC
Yes.  I think this is because the compiler needs to see the definition and the use site 
to exhibit this bug.  Without the def it will correctly emit the code walking the table 
to get to the member. 
Comment 6 Tom Tromey 2005-06-01 21:36:08 UTC
I'm testing a patch.
Comment 7 CVS Commits 2005-06-03 04:06:00 UTC
Subject: Bug 21722

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	tromey@gcc.gnu.org	2005-06-03 04:05:53

Modified files:
	gcc/java       : ChangeLog class.c 

Log message:
	PR java/21722:
	* class.c (build_static_field_ref): Don't fold constant fields if
	current class is from a .class file and we're using indirect
	dispatch.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1556.2.22&r2=1.1556.2.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.220.8.2&r2=1.220.8.3

Comment 8 CVS Commits 2005-06-03 04:06:27 UTC
Subject: Bug 21722

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	tromey@gcc.gnu.org	2005-06-03 04:06:19

Modified files:
	gcc/java       : ChangeLog class.c 

Log message:
	PR java/21722:
	* class.c (build_static_field_ref): Don't fold constant fields if
	current class is from a .class file and we're using indirect
	dispatch.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1621&r2=1.1622
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&r1=1.230&r2=1.231

Comment 9 Tom Tromey 2005-06-03 04:12:36 UTC
I've checked in the fix for this.
Comment 10 Tom Tromey 2005-06-03 05:34:37 UTC
Forgot to mark as fixed earlier.