java/1466: Compiler optimizes away private methods when native methods might access them
bryce@albatross.co.nz
bryce@albatross.co.nz
Wed Dec 20 12:29:00 GMT 2000
>Number: 1466
>Category: java
>Synopsis: Compiler optimizes away private methods when native methods might access them
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tromey
>State: feedback
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 20 12:20:20 PST 2000
>Closed-Date:
>Last-Modified: Fri Nov 5 11:16:01 PST 1999
>Originator: Bryce McKinlay <bryce@albatross.co.nz>
>Release: 19991104
>Organization:
>Environment:
linux
>Description:
When attempting to compile libgcj with optimization (-O2),
native methods which attempt to access certain private
static methods fail to link.
For example:
.libs/libgcj.so: undefined reference to
`java::net::InetAddress::checkConnect(java::lang::String *)'
>How-To-Repeat:
The following test code also demonstrates the problem. It
works ok without optimization, but with -O it fails to link:
// java
public class A
{
public static void main(String args[])
{
new A();
}
public A()
{
a();
}
native void a();
private void b()
{
System.out.println("ok");
}
}
// c++
#include <gcj/cni.h>
#include "A.h"
void A::a()
{
b();
}
>Fix:
gcj should not optimize away private methods when native
methods exist in the class.
>Release-Note:
>Audit-Trail:
Formerly PR gcj/85
From: Tom Tromey <tromey@cygnus.com>
To: Java Gnats Server <java-gnats@sourceware.cygnus.com>
Cc: Alexandre Petit-Bianco <apbianco@cygnus.com>,
Bryce McKinlay <bryce@albatross.co.nz>
Subject: gcj/85
Date: 05 Nov 1999 09:55:57 -0700
I looked at this bug. I believe this patch implements the heuristic
we discussed on java-discuss: if the class has any native methods, all
methods, even private methods, are generated.
I'm not sure this works in every case. I only tried rebuilding
libjava with it. I suspect that compilation from .class works
differently, but I'm not certain. (In any case, this patch shouldn't
make things worse there.)
Before the patch, building with -O3 gave me several undefined symbols.
After the patch (and one minor bug fix in libjava, which I'll commit
soon), compilation worked with -O3.
Alex, is this ok to commit? Or would you prefer to put a "native
method" flag on the class and compute it incrementally? I'm not sure
how to go about doing that, but I'd be willing to try if that is what
you want.
1999-11-05 Tom Tromey <tromey@cygnus.com>
* class.c (finish_class): Emit inlined methods if any native
methods exist in the class.
Tom
Index: class.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/class.c,v
retrieving revision 1.46
diff -u -r1.46 class.c
--- class.c 1999/10/29 21:32:27 1.46
+++ class.c 1999/11/05 16:43:01
@@ -1205,7 +1205,21 @@
{
tree method;
tree type_methods = TYPE_METHODS (CLASS_TO_HANDLE_TYPE (current_class));
-
+ int saw_native_method = 0;
+
+ /* Find out if we have any native methods. We use this information
+ later. */
+ for (method = type_methods;
+ method != NULL_TREE;
+ method = TREE_CHAIN (method))
+ {
+ if (METHOD_NATIVE (method))
+ {
+ saw_native_method = 1;
+ break;
+ }
+ }
+
/* Emit deferred inline methods. */
for (method = type_methods; method != NULL_TREE; )
{
@@ -1214,7 +1228,8 @@
/* It's a deferred inline method. Decide if we need to emit it. */
if (flag_keep_inline_functions
|| TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (method))
- || ! METHOD_PRIVATE (method))
+ || ! METHOD_PRIVATE (method)
+ || saw_native_method)
{
temporary_allocation ();
output_inline_function (method);
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: gcj/85
Date: Fri, 5 Nov 1999 09:53:55 -0800 (PST)
Tom Tromey writes:
> I'm not sure this works in every case. I only tried rebuilding
> libjava with it. I suspect that compilation from .class works
> differently, but I'm not certain. (In any case, this patch shouldn't
> make things worse there.)
finish_class() will be called on a class selected for code generation
regardless of its provenance.
> Alex, is this ok to commit?
Yes.
> Or would you prefer to put a "native method" flag on the class and
> compute it incrementally?
No, especially if we want that to work for both source and bytecode
read classes without having to really think about it.
./A
Responsible-Changed-From-To: apbianco->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Fri Nov 5 11:05:16 1999
Responsible-Changed-Why:
I fixed it.
State-Changed-From-To: open->feedback
State-Changed-By: tromey
State-Changed-When: Fri Nov 5 11:05:16 1999
State-Changed-Why:
I've checked in a fix for this. Part of the fix is
in gcc, and part in libgcj. Please try it and get
back to me. If you can't try it, tell me and I'll
just close the PR (since it works for me).
From: tromey@cygnus.com
To: apbianco@cygnus.com, bryce@albatross.co.nz,
java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Cc:
Subject: Re: gcj/85
Date: 5 Nov 1999 19:05:16 -0000
Synopsis: Compiler optimizes away private methods when native methods might access them
Responsible-Changed-From-To: apbianco->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Fri Nov 5 11:05:16 1999
Responsible-Changed-Why:
I fixed it.
State-Changed-From-To: open->feedback
State-Changed-By: tromey
State-Changed-When: Fri Nov 5 11:05:16 1999
State-Changed-Why:
I've checked in a fix for this. Part of the fix is
in gcc, and part in libgcj. Please try it and get
back to me. If you can't try it, tell me and I'll
just close the PR (since it works for me).
http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=java&pr=85
>Unformatted:
More information about the Gcc-prs
mailing list