[Bug libgcj/27066] libgcj native socket code does not support IPv6
--- Comment #4 from mckinlay at redhat dot com 2006-04-11 18:08 --- You are correct - I didn't notice that setTcpNoDelay, etc, call getImpl() - however, this could be fixed if neccessary. The question is whether this fix is the best one. Is there any disadvantage (performance or otherwise) to always using PF_INET6 sockets, even for IPv4 addresses? -- mckinlay at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-11 18:08:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
[Bug libgcj/27219] bogus-looking code in natPlainSocketImplPosix.cc
--- Comment #3 from mckinlay at redhat dot com 2006-04-20 21:45 --- It does look like these should be made robust in the case of an EINTR which was caused by a signal other than the interrupt signal. As for ignoring ENOTCONN and ECONNRESET, I have a vague recollection that there is a good reason for doing this (compatibility with Sun?) - but this probably does warrant more testing/investigation, and a better comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27219
[Bug libgcj/27170] Deadlock in garbage collector
--- Comment #9 from mckinlay at redhat dot com 2006-04-20 23:55 --- I have checked in the fix to the trunk and gcc-4_1-branch. -- mckinlay at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug tree-optimization/27389] [4.2 Regression] bootstrap fails building libjava, verify_flow_info fails
--- Comment #2 from mckinlay at redhat dot com 2006-05-02 15:33 --- I could not reproduce the bootstrap failure on x86-64 as of revision 113466. The test case does fail, however, when built with -findirect-dispatch. Looks like a dupe of bug 26447 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27389
[Bug tree-optimization/27389] [4.2 Regression] java: verify_flow_info fails
--- Comment #3 from mckinlay at redhat dot com 2006-05-02 17:32 --- *** This bug has been marked as a duplicate of 26447 *** -- mckinlay at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|[4.2 Regression] bootstrap |[4.2 Regression] java: |fails building libjava, |verify_flow_info fails |verify_flow_info fails | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27389
[Bug tree-optimization/26447] [4.2 Regression] verify_flow_info failed, load PRE with java program
--- Comment #13 from mckinlay at redhat dot com 2006-05-02 17:32 --- *** Bug 27389 has been marked as a duplicate of this bug. *** -- Bug 26447 depends on bug 27389, which changed state. Bug 27389 Summary: [4.2 Regression] java: verify_flow_info fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27389 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
[Bug libgcj/27352] SecurityManager.checkPermission() called unnecessarily
--- Comment #6 from mckinlay at redhat dot com 2006-05-16 01:03 --- I've posted a suggested fix here: http://gcc.gnu.org/ml/java-patches/2006-q2/msg00168.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27352
[Bug libgcj/27352] SecurityManager.checkPermission() called unnecessarily
--- Comment #8 from mckinlay at redhat dot com 2006-05-17 15:18 --- Fixed -- mckinlay at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27352
[Bug java/27643] New: ICE in java_mark_cni_decl_local compiling bytecode->native
The following test case crashes:
$ gcj -C PipeImpl.java
$ gcj -c *.class -o t.o
PipeImpl.java:0: internal compiler error: in java_mark_cni_decl_local, at
java/decl.c:2182
class PipeImpl
{
public PipeImpl ()
{
VMPipe.init (this);
}
}
final class VMPipe
{
static native void init(PipeImpl self);
}
--
Summary: ICE in java_mark_cni_decl_local compiling bytecode-
>native
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27643
[Bug java/27812] New: Classpath AWT Demo: anonymous class call miscompilation
GCJ miscompiles part of the classpath AWT demo application in:
classpath/examples/gnu/classpath/examples/awt/Demo.java
In an anonoymous inner class ActionListener implementation, an unqualified call
to a superclass of the outer class is called on "this" instead of the outer
class.
This happens with either source->native or source->bytecode compilation.
class Super
{
void dispose()
{
System.out.println("OK");
}
}
public class PR27812
{
public static void main(String[] args)
{
Y y = new Y();
y.y();
}
static interface I
{
abstract void actionPerformed();
}
static class Y extends Super
{
void y()
{
new I () {
public void actionPerformed () {
dispose();
}
}.actionPerformed();
}
}
}
$ gcj -C PR27812.java
$ gij PR27812
Exception in thread "main" java.lang.NoSuchMethodError: method
PR27812$Y$1.dispose with signature ()V was not found.
at PR27812$Y$1.actionPerformed (PR27812.java:28)
at PR27812$Y.y (PR27812.java:30)
at PR27812.main (PR27812.java:14)
--
Summary: Classpath AWT Demo: anonymous class call miscompilation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27812
[Bug libgcj/20047] runtime 'protected' access checks
--- Comment #2 from mckinlay at redhat dot com 2006-06-01 11:07 --- This rule is mentioned in the last paragraph of JVMS, S 5.4.4: http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#75929 It is explicitly stated that this is checked during verification, unlike other accessibility checks which are performed at link time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20047
[Bug java/27925] Trampolines not generated for private inner class methods.
--- Comment #2 from mckinlay at redhat dot com 2006-06-07 18:06 --- *** This bug has been marked as a duplicate of 19870 *** -- mckinlay at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27925
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
--- Comment #20 from mckinlay at redhat dot com 2006-06-07 18:06 --- *** Bug 27925 has been marked as a duplicate of this bug. *** -- mckinlay at redhat dot com changed: What|Removed |Added CC||csm at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug libgcj/27938] New: gij should dlopen() libgcj
Recently, gij was changed to re-exec itself after resetting its own
LD_LIBRARY_PATH.
This change almost doubles the time needed to execute "Hello World", from 0.13s
to 0.25s on my system (and compared to 0.08s for the Sun VM).
The reason is that since gij is linked against libgcj.so, the linker's work is
being done twice as libgcj is loaded twice.
Instead, we could dlopen() libgcj only on the second invocation of gij. This
may require some cleanups to avoid accessing libgcj methods/symbols during the
first gij invocation, before the dlopen() occurs.
--
Summary: gij should dlopen() libgcj
Product: gcc
Version: 2.95
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27938
[Bug libgcj/27938] gij should dlopen() libgcj
--- Comment #1 from mckinlay at redhat dot com 2006-06-07 21:58 --- No longer neccessary, since Tom has changed gij to not re-exec itself: http://gcc.gnu.org/ml/java-patches/2006-q2/msg00330.html -- mckinlay at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27938
[Bug libgcj/28175] libgcj install tree should be relocatable
--- Comment #1 from mckinlay at redhat dot com 2006-06-29 18:10 --- Using /proc/self/exe would only work for "gij" - we'd want a solution that can work for native binaries as well, so figuring out the prefix based on libgcj.so's location is probably better. On Linux, this can be found with dl_iterate_phdr(). -- mckinlay at redhat dot com changed: What|Removed |Added CC| |mckinlay at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-29 18:10:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28175
[Bug java/22299] Even length strings (not odd) placed in .section .rodata.jutf8.# at -O1 or above.
--- Comment #1 from mckinlay at redhat dot com 2006-06-30 19:01 --- The sizes of the constant-merging sections must be a multiple of the alignment of their contents. UtfConsts have 2-byte alignment, so odd-sized strings are rounded up and go in the next-sized bucket. So, it is correct for "ODD" and "" to both go in .rodata.jutf8.8, which is what is happening here. Constant merging is not performed below -O1. -- mckinlay at redhat dot com changed: What|Removed |Added CC| |mckinlay at redhat dot com Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22299
[Bug java/22299] Even length strings (not odd) placed in .section .rodata.jutf8.# at -O1 or above.
--- Comment #2 from mckinlay at redhat dot com 2006-06-30 19:04 --- Correction: Both "XX" and "ODD" go in .rodata.jutf8.8. "" would go in .rodata.jutf8.10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22299
[Bug libgcj/1907] symbol demangling by Throwable.printStackTrace
--- Comment #8 from mckinlay at redhat dot com 2006-07-06 22:56 --- Fixed. libgcj no longer needs to do symbol demangling. -- mckinlay at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1907
[Bug libgcj/13139] gcj throws exception with faulty stacktrace with freenet
--- Comment #7 from mckinlay at redhat dot com 2006-07-06 23:06 --- Verified that freenet-0.5.2.1 now produces valid stack traces running under gcj. -- mckinlay at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13139
[Bug libgcj/28352] New: Interpreter: Stack trace line numbers sometimes missing or incorrect
When the following test case is built with gcj -C, the innermost frame is
missing from the stack trace:
public class Ex {
void snafu( ) throws Exception {
throw new Exception();
}
void bar( ) throws Exception {
snafu( );
}
void foo( ) throws Exception {
bar( );
}
public static void main( String[] args) throws Exception {
new Ex( ).foo( );
}
}
$ gij Ex
Exception in thread "main" java.lang.Exception
at Ex.snafu(Ex.java)
at Ex.bar(Ex.java:6)
at Ex.foo(Ex.java:9)
at Ex.main(Ex.java:12)
In addition, when built with a different bytecode compiler (ecj), the stack
trace is complete, but has off-by-one line number errors:
$ gij Ex
Exception in thread "main" java.lang.Exception
at Ex.snafu(Ex.java:3)
at Ex.bar(Ex.java:7)
at Ex.foo(Ex.java:10)
at Ex.main(Ex.java:13)
--
Summary: Interpreter: Stack trace line numbers sometimes missing
or incorrect
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28352
[Bug libgcj/28352] Interpreter: Stack trace line numbers sometimes missing or incorrect
--- Comment #1 from mckinlay at redhat dot com 2006-07-11 21:32 --- Correction: the description should read "the line number for the inner-most frame is missing from the stack trace". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28352
[Bug java/28352] gcj -C fails to generate line number info for method
--- Comment #4 from mckinlay at redhat dot com 2006-07-12 13:59 --- I've committed a patch which fixes the "off by one" error seen with ecj-produced bytecode. The missing line number issue is a different bug. It seems that "gcj -C" simply does not generate any debug info for the "snafu" method in the example below. I'm reassigning this as a front-end bug. -- mckinlay at redhat dot com changed: What|Removed |Added Component|libgcj |java Summary|Interpreter: Stack trace|gcj -C fails to generate |line numbers sometimes |line number info for method |missing or incorrect| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28352
[Bug libgcj/9250] runtime should only use non-visible locks
--- Comment #4 from mckinlay at redhat dot com 2005-11-17 17:38 --- I'm curious whether other Java implementations do this - my guess is no, since some of these locks are mandated by the spec (during class initialization, for example), so it seems that denial-of-service attacks would always be possible. Its my understanding that the Java security model is not really designed or intended to guard against DOS attacks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9250
[Bug java/24980] GCJ/GIJ segfaults on Workout.java from Click and Hack's "Java Puzzlers"
--- Comment #7 from mckinlay at redhat dot com 2005-11-21 22:02 ---
> Except that under Bryce's GCJ, the function terminates successfully
> even if you throw in System.out.println's into it, thus tainting its
> "purity".
No, when I add a System.out.println("hi"), and compile with a trunk gcj, the
example behaves as expected - "hi" is printed many times until a stack overflow
eventually occurs, resulting in a segfault. Removing the try/finally, the
example runs forever thanks to tail-call optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24980
[Bug libgcj/19823] java fails with non-executable memory
--- Additional Comments From mckinlay at redhat dot com 2005-02-16 04:22 --- Michael (or someone else who has seen this bug), Could you confirm that this patch fixes it? Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
[Bug java/20338] Program compiled with gcj crashes when accessing private static method from nested class
--- Additional Comments From mckinlay at redhat dot com 2005-03-09 18:06 --- Other Java compilers generate "accessor" methods for calls to private methods in a nested class, the real bug here is that GCJ doesn't do this - thats why the javac bytecode works fine on gij but gcj-produced bytecode does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
[Bug java/19870] gcj -C doesn't generate accessors for private members in inner class
--- Additional Comments From mckinlay at redhat dot com 2005-03-09 18:22 --- gcj is generating code which references private members across class boundaries, which isn't legal at the class/VM level. To fix this, we need to generate package-private accessor methods when a private member is referenced from an enclosed or enclosing class. eg: jikes generates: Method name:"main" public static Signature: (java.lang.String[])void Attribute "Code", length:38, max_stack:2, max_locals:1, code_length:10 0: getstatic 3: invokestatic 6: invokevirtual 9: return Attribute "LineNumberTable", length:10, count: 2 line: 10 at pc: 0 line: 11 at pc: 9 Method name:"access$0" static Signature: ()int Attribute "Synthetic", length:0 Attribute "Code", length:28, max_stack:1, max_locals:0, code_length:4 0: getstatic 3: ireturn Attribute "LineNumberTable", length:6, count: 1 line: 3 at pc: 0 -- What|Removed |Added Summary|gcj -C compiled code|gcj -C doesn't generate |accessing private fields of |accessors for private |inner classes from outer|members in inner class |class give | |IllegalAccessError | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug java/13124] Included test case produced verfication error
--- Additional Comments From mckinlay at redhat dot com 2005-03-10 00:52 --- Fixed with the new verifier. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13124
[Bug java/12734] gcj verifier doesn't merge interface types correctly
--- Additional Comments From mckinlay at redhat dot com 2005-03-10 00:53 --- Fixed with the new verifier. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12734
[Bug java/13378] gcj compiling from jar files - verification error
--- Additional Comments From mckinlay at redhat dot com 2005-03-10 01:29
---
This is failing because the bytecode in this .jar really is broken:
public class Test
{
public static void main(String[] args) throws Exception
{
Class f = Class.forName("org.eclipse.jface.util.OpenStrategy$1");
System.out.println (f);
}
}
$ java Test
Exception in thread "main" java.lang.VerifyError: (class:
org/eclipse/jface/util/OpenStrategy$1, method: handleEvent signature:
(Lorg/eclipse/swt/widgets/Event;)V) Register 2 contains wrong type
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at Test.main(Test.java:7)
However, its questionable whether gcj should actually report this error with
--indirect-dispatch. The verifier is correctly deferring this type check to
runtime via a type assertion but code in expr.c is still doing its own check
(hangover from the old verifier, I guess). Then again its probably a reasonable
assumption to make that java.lang.Object is never assignment-compatible to
anything else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13378
[Bug java/20338] Program compiled with gcj crashes when accessing private static method from nested class
--- Additional Comments From mckinlay at redhat dot com 2005-03-10 11:30 --- Why not check in the test case and XFAIL it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
[Bug java/20502] gcj failure if .jar contains same .class twice
--- Additional Comments From mckinlay at redhat dot com 2005-03-16 19:01 --- I think in general, if a .jar is valid for the VM, then we should do our best to compile it without an error. So - we should just ignore (well, issue a warning perhaps) duplicately-named class files in a jar. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-16 19:01:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20502
[Bug java/20502] gcj failure if .jar contains same .class twice
--- Additional Comments From mckinlay at redhat dot com 2005-03-16 19:33
---
I wonder why this check doesn't catch it (jcf-parse.c):
if (CLASS_PARSED_P (current_class))
{
/* FIXME - where was first time */
fatal_error ("reading class %s for the second time from %s",
IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (current_class))),
jcf->filename);
}
CLASS_PARSED_P (current_class) = 1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20502
[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs
--- Additional Comments From mckinlay at redhat dot com 2005-03-16 22:27 --- The patch looks reasonable to me. Is the quoting feature something that should be used in Perl style regular expressions as well, or is this a difference between Perl-style and Java-style? If it is a difference, this feature should only be enabled when RE_SYNTAX_JAVA_1_4 is enabled. Ziga, do you have a copyright assignment for GNU Classpath? This patch will need a changelog entry, too? -- What|Removed |Added CC||ziga dot mahkovec at klika ||dot si Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-16 22:27:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20504
[Bug libgcj/20504] java.util.regex implementation doesn't support quoting constructs
--- Additional Comments From mckinlay at redhat dot com 2005-03-17 01:29 --- Please make sure the ChangeLog is properly formatted. You're missing the name of the changed method, and a "*" beside the filename. We're quite picky about this ;-) Otherwise, the patch looks great. Please check it in once your assignment paperwork is complete. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20504
[Bug libgcj/20508] New: gij prints too much information if an incorrect class is given
When the name of a non-existant class is given to gij, the error given is far
too verbose:
$ gij Blah
Exception in thread "main" java.lang.NoClassDefFoundError: Blah
at gnu.java.lang.MainThread.run (MainThread.java:98)
Caused by: java.lang.ClassNotFoundException: Blah not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.VMClassLoader{urls=[core:/], parent=null}}
at java.net.URLClassLoader.findClass (URLClassLoader.java:923)
at java.lang.ClassLoader.loadClass (ClassLoader.java:309)
at java.lang.Class.forName (natClass.cc:88)
at gnu.java.lang.MainThread.run (MainThread.java:94)
This is a lot more information than the user needs. Compare this with Sun's VM:
$ java Blah
Exception in thread "main" java.lang.NoClassDefFoundError: Blah
We should not wrap the ClassNotFoundException in MainThread.run, and the stack
trace code should supress stack trace printing when main() has not yet been
called (or, at least, for this special case - when the exception is thrown from
MainThread.run).
--
Summary: gij prints too much information if an incorrect class is
given
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20508
[Bug libgcj/20704] CNI code is called/loaded without any security checks
--- Additional Comments From mckinlay at redhat dot com 2005-03-31 19:01 --- I'm not sure that this should really be considered a bug. loadLibrary() must obviously be a privileged function because arbritary code could be loaded by calling it (possibly from an insecure context), but having/calling a CNI method does not in itself cause anything to be loaded. A CNI method implementation must already be loaded by being explicitly linked into an application binary. To put it another way: is there a way that insecure bytecode can actually turn this into an exploit? Perhaps some kind of validity check is needed at link time to ensure that native method declarations in insecure code do not link against an inappropriate native method (for example, make sure that insecure classes cannot call themselves gnu.foo.Whatever and get linked to a private CNI method implementation in another class of the same name). In any case, checking the loadLibrary permission is the wrong approach because there is no library actually being loaded. The correct behaviour would be to simply not link the method if something isn't right, resulting in an UnsatisfiedLinkError. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20704
[Bug libgcj/20750] libgcj needs a --with-java-home configure option
--- Additional Comments From mckinlay at redhat dot com 2005-04-04 20:03 --- Whats the advantage to setting these at configure time? Couldn't java-gcj-compat just set them when it invokes gij? It seems a little awkward to hardcode paths like "java-1.4.2-gcj-1.4.2.0" into libgcj when this is really a property of java-gcj-compat. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20750
[Bug libgcj/20750] libgcj needs a --with-java-home configure option
--- Additional Comments From mckinlay at redhat dot com 2005-04-04 21:27 --- Yeah, in the case where java-gcj-compat is merged into libgcj (ie libgcj is set up to look like a JVM) then this option makes sense. libgcj would install its .jars and whatever other JVMish files applications expect to find into this directory, and set java.home accordingly. I don't see a reason why we couldn't go ahead and implement this on HEAD now, even though an external wrapper would still be needed for now to use ecj as javac. I so think it seems a bit non-intuitive to have --with-java-home just set a property and not actually install things into that directory, relying on an external package to actually populate it, however. We should at least install libgcj.jar into the directory given? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20750
[Bug libgcj/20761] fastjar not correctly defined when compiling with cross compilers.
-- What|Removed |Added Status|UNCONFIRMED |NEW Component|java|libgcj Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-04 22:17:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20761
[Bug libgcj/20761] fastjar not correctly defined when compiling with cross compilers.
--- Additional Comments From mckinlay at redhat dot com 2005-04-04 22:31 --- Thanks, I've checked in your patch for this. Note that in theory, fastjar should be target-neutral, so I don't think it makes much sense to call it $(target)-fastjar... oh well. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20761
[Bug java/20768] Bytecode -> native code doesn't handle exception properly
--- Additional Comments From mckinlay at redhat dot com 2005-04-05 18:33 --- Confirmed. There seems to be something unique about the exception table generated by ecj which confuses gcj. Note that this happens both with or without optimization. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-05 18:33:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20768
[Bug libgcj/20775] Crash in libgcj.so on linux alpha
--- Additional Comments From mckinlay at redhat dot com 2005-04-05 21:46 --- Is this is a Multi-processor machine? Does the crash always occur 100% in the same place or is it intermittent? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20775
[Bug libgcj/20975] Remove scripts/TexinfoDoclet.java
--- Additional Comments From mckinlay at redhat dot com 2005-04-12 19:56 --- Yes, this should be removed - it has been superceeded by texidoclet in classpath-tools, anyway. I will check in this patch. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-12 19:56:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20975
[Bug libgcj/20975] Remove scripts/TexinfoDoclet.java
--- Additional Comments From mckinlay at redhat dot com 2005-04-12 20:09 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20975
[Bug java/20977] New: Invalid long to int promotion permitted in array initializer
The following code is invalid as implicitly converting a long to int could
result in the value being truncated. However, GCJ accepts this code.
public class Arraybound
{
public byte[] x(long l)
{
return new byte[l];
}
}
--
Summary: Invalid long to int promotion permitted in array
initializer
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20977
[Bug java/20978] New: Failure to detect unhandled exception
In some cases GCJ fails to detect unhandled exceptions. In the code below, the
method x() is invalid because FileChannel.close() can throw an IOException. GCJ
should report an error stating that the exception must be caught or declared to
be thrown.
import java.nio.channels.*;
public class FCIO
{
FileChannel fc;
public void x()
{
fc.close();
}
}
--
Summary: Failure to detect unhandled exception
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20978
[Bug libgcj/20958] Compile Errors In two files in gnu.gcj
--- Additional Comments From mckinlay at redhat dot com 2005-04-12 23:26 --- Fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20958
[Bug libgcj/10353] [3.3/3.4/4.0/4.1 regression] Java testsuite failures
--- Additional Comments From mckinlay at redhat dot com 2005-04-18 14:55 --- I don't think a gij test failure is expected. Array_3 is known to fail when native compiled, however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
[Bug libgcj/23739] JNI: IsAssignableFrom reverses arguments
--- Additional Comments From mckinlay at redhat dot com 2005-09-05 22:20
---
IMO Sun actually got it wrong here ;-) Reading function arguments from
left-to-right, I'd expect the first argument to be the context ("Is") and the
second to be the class refered to in (the "From").
Having said that, it is rather confusing that the order is reversed between JNI
and libgcj's internal function. I agree we should fix it, though there are a lot
of callers to update. It is not an issue for CNI, because IsAssignableFrom is
not exposed as a public CNI function.
--
What|Removed |Added
Summary|IsAssignableFrom reverses |JNI: IsAssignableFrom
|arguments |reverses arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23739
[Bug java/23891] New: Problem folding static fields across packages
The following test case, derived from Eclipse/ecj, fails to compile on HEAD and
current 4.0 branch. This is a regression since 4.0.0.
package ast;
import classfmt.*;
public abstract class ASTNode implements ClassFileConstants {
}
---
package ast;
public class EqualExpression extends ASTNode {
public void resolveType() {
long foo = JDK1_5;
}
}
---
package classfmt;
public interface ClassFileConstants {
int MINOR_VERSION_0 = 0;
long JDK1_5 = (long) ClassFileConstants.MINOR_VERSION_0;
}
$ gcj -c ast/EqualExpression.java
./classfmt/ClassFileConstants.java: In class 'ast.EqualExpression':
./classfmt/ClassFileConstants.java: In method
'ast.EqualExpression.resolveType()':
./classfmt/ClassFileConstants.java:5: error: Undefined variable or class name:
‘ClassFileConstants.MINOR_VERSION_0’.
long JDK1_5 = (long) ClassFileConstants.MINOR_VERSION_0;
^
1 error
--
Summary: Problem folding static fields across packages
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23891
[Bug java/23891] Problem folding static fields across packages
--- Additional Comments From mckinlay at redhat dot com 2005-09-15 00:08 --- The problem is that fold_constant_for_init() saves the current_class state when resolving other dependent constants, but not the current package (ctxp->package). If a constant in another package is referenced, then when resolving/folding the value of that constant, the wrong package context is used. I'm testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mckinlay at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-15 00:08:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23891
[Bug java/23891] Problem folding static fields across packages
--- Additional Comments From mckinlay at redhat dot com 2005-09-15 14:19 --- Fixed checked in to HEAD, but this should also be applied to 4.0 branch because its a regression from 4.0.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23891
[Bug java/23891] Problem folding static fields across packages
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23891
[Bug java/24018] New: [meta-bug] Patches that should be applied to 4.0 branch
This is a tracker for Java patches that should be appled to 4.0 branch, once it thaws after the 4.0.2 release. Please add PR fixes as dependencies, and for other patches link to their URLs in a comment. -- Summary: [meta-bug] Patches that should be applied to 4.0 branch Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mckinlay at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
--- Additional Comments From mckinlay at redhat dot com 2005-09-22 17:28 --- PR 23891 fix. This is required to build ECJ. -- What|Removed |Added BugsThisDependsOn||23891 Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-22 17:28:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
--- Additional Comments From mckinlay at redhat dot com 2005-09-22 17:30 --- Patch to fix classloader deadlock. Needed for Jonas. http://gcc.gnu.org/ml/java-patches/2005-q3/msg00412.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
--- Additional Comments From mckinlay at redhat dot com 2005-09-22 17:34 --- PR 21418. Needed to build classpath reliably. -- What|Removed |Added BugsThisDependsOn||21418 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
--- Additional Comments From mckinlay at redhat dot com 2005-09-22 17:39 --- PR 23182. Fixes a miscompilation affecting Eclipse. -- What|Removed |Added BugsThisDependsOn||23182 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug libgcj/23182] instanceof sometimes fails if compiled with -findirect-dispatch
-- What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23182
[Bug java/23891] [4.0 Regression] Problem folding static fields across packages
-- What|Removed |Added Target Milestone|4.0.2 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23891
[Bug java/21418] Order of source files matters when compiling
--- Additional Comments From mckinlay at redhat dot com 2005-09-22 17:45 --- This patch should go into the 4.0 branch, once that thaws. -- What|Removed |Added Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
--- Additional Comments From mckinlay at redhat dot com 2005-09-23 22:05 --- PR 19870. Although these patches are largeish, they have been tested in HEAD for some time and should be pretty safe. They are needed for OO.org. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug libgcj/24051] [4.1 Regression]: libjava failed to configure
--- Additional Comments From mckinlay at redhat dot com 2005-09-26 22:36 --- AC_PROG_CXX is, presumably, needed by classpath in order to build the Qt peers. Although this is not the default configuration, it means we can't remove AC_PROG_CXX. The libjava configure gets around this issue using GCC_NO_EXECUTABLES, which disables linking of configure tests where possible. One solution is to add GCC_NO_EXECUTABLES to the classpath configure. Unfortunatly this introduces a divergance from the upstream configure.ac. We also need to butcher classpath's AC_CHECK_FUNCs because many of these do not work with GCC_NO_EXECUTABLES. However, they are probably not needed anyway because we do not build classpath's JNI code - only the AWT peers. Perhaps the AC_CHECK_FUNCs can be made conditional so as to reduce divergance from upstream? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24051
[Bug libgcj/24057] [4.1 regression] libgcj installs jawt.h and jni.h in version independent location
--- Additional Comments From mckinlay at redhat dot com 2005-09-26 22:41 --- Please ignore this patch, I attached it to the wrong bug. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24057
[Bug java/23891] [4.0 Regression] Problem folding static fields across packages
--- Additional Comments From mckinlay at redhat dot com 2005-10-01 06:58 --- Fixed on both HEAD and 4.0 branch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23891
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
-- Bug 24018 depends on bug 23891, which changed state. Bug 23891 Summary: [4.0 Regression] Problem folding static fields across packages http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23891 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug java/24018] [meta-bug] Patches that should be applied to 4.0 branch
--- Comment #14 from mckinlay at redhat dot com 2005-10-05 19:39 --- All patches from this bug have now been ported to the 4.0 branch, so I'm closing it. Future fixes for 4.0 should be considered on a case-by-case basis, or a new meta-bug opened if it freezes again. -- mckinlay at redhat dot com changed: What|Removed |Added CC||mckinlay at redhat dot com Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug java/21540] switch stmt problem
--- Comment #10 from mckinlay at redhat dot com 2005-10-13 01:12 --- Fixed checked in to 4.0 branch. -- mckinlay at redhat dot com changed: What|Removed |Added Known to fail|3.0.4 3.2.3 3.2.2 3.3.3 |3.0.4 3.2.3 3.2.2 3.3.3 |3.4.0 4.0.0 4.1.0 |3.4.0 4.0.0 Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug java/13788] Zero propogate right shift in static final int initializer causes error
--- Comment #9 from mckinlay at redhat dot com 2005-10-13 01:14 --- Fixed checked in to 4.0 branch. -- mckinlay at redhat dot com changed: What|Removed |Added Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13788
[Bug libgcj/17021] libgcj verifier resolves classes too eagerly
--- Comment #14 from mckinlay at redhat dot com 2005-10-25 20:36 --- Robert, thanks very much for working on this. Examining the behaviour of Sun's verifier a bit more shows that it does attempt to resolve classes where type compatibility can not be proven by a simple string comparison, so I think that your approach is correct. I have one pedantic concern about the implementation of _Jv_equalUtf8Const_classnames: Say we're comparing a class called "Lfoo" and one called "fool", and fool is given in the bytecode form while "Lfoo" is in the regular form. So, _Jv_equalUtf8Const_classnames would end up comparing the strings "Lfoo" and "Lfool;". Whats to stop it falsely returning true in this case? Also, how about a more concise name for this function: _Jv_equalUtf8Classnames? It will also need a ChangeLog entry, of course - other than these issues, this patch looks pretty good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021
[Bug java/20697] Invalid Can't find method error on call to super
--- Additional Comments From mckinlay at redhat dot com 2005-06-23 15:02 --- Fix checked in. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20697
[Bug java/18131] [meta-bug] inner class problems in java front-end
-- Bug 18131 depends on bug 20697, which changed state. Bug 20697 Summary: Invalid Can't find method error on call to super http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20697 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131
[Bug java/19674] Empty declaration through semicolon (;) causes compile failure
--- Additional Comments From mckinlay at redhat dot com 2005-07-06 19:05 --- Fixed in HEAD -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19674
[Bug java/18131] [meta-bug] inner class problems in java front-end
-- Bug 18131 depends on bug 19674, which changed state. Bug 19674 Summary: Empty declaration through semicolon (;) causes compile failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19674 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131
[Bug java/21045] Anonymous inner class constructor's exceptions can't be caught or thrown
--- Additional Comments From mckinlay at redhat dot com 2005-07-07 14:46 --- Fixed on HEAD. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045
[Bug java/18131] [meta-bug] inner class problems in java front-end
-- Bug 18131 depends on bug 21045, which changed state. Bug 21045 Summary: Anonymous inner class constructor's exceptions can't be caught or thrown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131
[Bug java/18119] Private inner class is visible when it shouldn't be
--- Additional Comments From mckinlay at redhat dot com 2005-07-07 14:47 --- Fixed on HEAD. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18119
[Bug java/20697] Invalid Can't find method error on call to super
-- Bug 20697 depends on bug 18119, which changed state. Bug 18119 Summary: Private inner class is visible when it shouldn't be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18119 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20697
[Bug java/18131] [meta-bug] inner class problems in java front-end
-- Bug 18131 depends on bug 18119, which changed state. Bug 18119 Summary: Private inner class is visible when it shouldn't be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18119 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131
[Bug java/20697] Invalid Can't find method error on call to super
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20697
[Bug java/22377] BC compilation fails to detect abstract instantiation
--- Additional Comments From mckinlay at redhat dot com 2005-07-11 15:44 --- There might be a way to implement this without additional _Jv_AllocObject cost and without adding new ABI tables. If abstract classes and interfaces were given a zero or negative value in their size field, I think the GC will call GC_oom_fn if an attempt were made to allocate them. We could then throw InstantiationException instead of OutOfMemoryError in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377
[Bug libgcj/22463] New: libgcj verifier attempts to resolve dependent classes
The libgcj verifier attempts to resolve dependent classes using Class.forName().
This causes ClassNotFoundException to be thrown too early - the exception should
occur when an attempt to use the missing class is made, not during verification.
public class Test
{
Missing a()
{
return new Missing();
}
public static void main(String[] args)
{
System.out.println ("Missing not needed.");
}
}
public class Missing {}
$ gcj -C Missing.java Test.java
$ rm Missing.class
$ java -verify Test
Missing not needed.
$ gij -noverify Test
Missing not needed.
$ gij -verify Test
Exception in thread "main" java.lang.NoClassDefFoundError: Test
at java.lang.Class.initializeClass (natClass.cc:715)
at java.lang.Class.forName (Class.h:582)
at gnu.java.lang.MainThread.run (MainThread.java:95)
Caused by: java.lang.ClassNotFoundException: Missing not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass (URLClassLoader.java:948)
at java.lang.ClassLoader.loadClass (ClassLoader.java:317)
at java.lang.ClassLoader.loadClass (ClassLoader.java:260)
at java.lang.Class.forName (natClass.cc:88)
at java.lang.Class.initializeClass (natClass.cc:709)
...2 more
--
Summary: libgcj verifier attempts to resolve dependent classes
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22463
[Bug libgcj/22580] New: "make -j" doesn't effect source->bytecode compilation
X-Bugzilla-Reason: CC
Since the classpath merge, I have noticed that the source->bytecode stage of the
libgcj build is not being paralellized.
This warning was also seen:
make[4]: Entering directory
`/home/mckinlay/cvs/gcc/build-x86_64/x86_64-unknown-linux-gnu/libjava/classpath/lib
make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent make
rule.
--
Summary: "make -j" doesn't effect source->bytecode compilation
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22580
[Bug libgcj/22580] 'make -j' doesn't effect source->bytecode compilation
-- What|Removed |Added Summary|"make -j" doesn't effect|'make -j' doesn't effect |source->bytecode compilation|source->bytecode compilation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22580
[Bug libgcj/16902] GIJ: Garbage collection related failure with interpreter
--- Comment #4 from mckinlay at redhat dot com 2006-02-06 18:38 --- You might need a multiprocessor or hyper-threaded machine to reproduce it. I was able to reproduce it with HEAD just now: $ while (true) do gij GCTest; done [20]: Success java.lang.LinkageError: field type mismatch with different loaders at GCTest$GCTest_Object. (GCTest.java:18) at GCTest.testObjChain (GCTest.java:245) at GCTest.run (GCTest.java:126) at java.lang.Thread.run (Thread.java:653) Caused by: java.lang.NoClassDefFoundError: this$0 at GCTest$GCTest_Object. (GCTest.java:18) ...3 more [41]: Failure: testObjChain: Caught exception: field type mismatch with different loaders -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16902
[Bug libgcj/16902] GIJ: Garbage collection related failure with interpreter
--- Comment #5 from mckinlay at redhat dot com 2006-02-06 18:41 --- Another example of failure: [5]: Success java.lang.NullPointerException at GCTest.testObjChain (GCTest.java:251) at GCTest.testObjArray (GCTest.java:191) at GCTest.run (GCTest.java:104) at java.lang.Thread.run (Thread.java:653) [44]: Failure: testObjArray: Caught exception: null [44]: Success java.lang.NullPointerException at GCTest.testObjChain (GCTest.java:251) at GCTest.testObjArray (GCTest.java:191) at GCTest.run (GCTest.java:104) at java.lang.Thread.run (Thread.java:653) [33]: Failure: testObjArray: Caught exception: null java.lang.NullPointerException at GCTest.testObjChain (GCTest.java:251) at GCTest.testObjArray (GCTest.java:191) at GCTest.run (GCTest.java:104) at java.lang.Thread.run (Thread.java:653) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16902
[Bug libgcj/25187] dereferencing type-punned pointer warnings while building libgcj
--- Comment #4 from mckinlay at redhat dot com 2006-02-09 01:38 --- Fixed. -- mckinlay at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25187
[Bug libgcj/26113] More warnings in libjava
--- Comment #4 from mckinlay at redhat dot com 2006-02-09 01:39 --- Fixed. -- mckinlay at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26113
[Bug libgcj/24860] java.util.Calendar needs updating
--- Comment #2 from mckinlay at redhat dot com 2006-02-13 22:02 --- libgcj is not yet using Classpath's locale database, so classes (including Calendar) that rely on the old locale information are yet to be merged. I'm working on a patch for the trunk that will switch libgcj to use Classpath's locale information. Once that it done, the libgcj-local versions of Calendar and other locale-dependent classes will go away. -- mckinlay at redhat dot com changed: What|Removed |Added CC| |mckinlay at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24860
[Bug libgcj/26351] Native Momory Leak in ResourceBundle
--- Comment #2 from mckinlay at redhat dot com 2006-02-20 19:47 --- You must be using a very old GCJ - this was fixed a long time ago. *** This bug has been marked as a duplicate of 12475 *** -- mckinlay at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26351
[Bug libgcj/12475] Stack traces leak memory
--- Comment #7 from mckinlay at redhat dot com 2006-02-20 19:47 --- *** Bug 26351 has been marked as a duplicate of this bug. *** -- mckinlay at redhat dot com changed: What|Removed |Added CC||fexx at fexx dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12475
[Bug libgcj/12740] Stack trace infrastructure improvements
--- Comment #3 from mckinlay at redhat dot com 2006-03-08 18:36 --- Yes. This is fixed in GCC 4.1. -- mckinlay at redhat dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12740
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #2 from mckinlay at redhat dot com 2006-03-09 03:16 --- Can anyone make a test case for this? I was unable to reproduce it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug libgcj/26858] NullPointerException not generated for large classes...
--- Comment #3 from mckinlay at redhat dot com 2006-03-27 18:28 --- GCJ could be made to generate explicit null checks when large offsets are used. It is probably relatively rare to have a normal object that is larger than a page, so performance for most apps shouldn't be effected. Note that array accesses should not need this as the "length" field will be dereferenced first, triggering NullPointerException, assuming bounds checks are used. I would also expect Strings should not have a problem. Do we know who's heap exactly is mapped at such a low address? If its mapped by Java/Boehm GC, then we can probably just fix the GC to not map things at such low addresses (or to insert guard pages there instead). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26858
[Bug libgcj/11780] Method.invoke() is slow
--- Comment #7 from mckinlay at redhat dot com 2006-03-29 18:59 --- With a public call, as in the current test case, it is "only" about 2.5X slower than HotSpot for me: $ ./a.out public call: 499 ms private call: 7344 ms $ java RefTest3 public call: 182 ms private call: 808 ms Private calls show a larger difference due to the requirement for an accessibility check, which involves stack inspection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11780
[Bug libgcj/11780] Method.invoke() is slow
--- Comment #8 from mckinlay at redhat dot com 2006-03-29 19:00 --- Created an attachment (id=11156) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11156&action=view) Test Case New version of the test case, which tests both public and private method invocation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11780
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #30 from mckinlay at redhat dot com 2006-03-30 07:00 --- Created an attachment (id=11161) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11161&action=view) patch implementing GC_register_my_thread Here's a patch that fixes this by adding functions to the GC that allow thread registration directly from JNI_AttachCurrentThread. Aside from being fragile, solutions that rely on intercepting pthread_create are problematic because the GC will attempt to suspend other non-Java threads (see rh bug 180637 for an example) This patch has been tested sucessfully with openoffice.org. -- mckinlay at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mckinlay at redhat dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #32 from mckinlay at redhat dot com 2006-03-30 15:51 --- (In reply to comment #31) Yes, this patch should fix all the OpenOffice issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
