[Bug java/29013] gcj generates a MetalLookAndFeel class that fails cacao's verifier
--- Comment #2 from mark at gcc dot gnu dot org 2006-09-11 09:39 --- Subject: Re: New: gcj generates a MetalLookAndFeel class that fails cacao's verifier Hi, On Mon, 2006-09-11 at 06:05 +, cam-gcc-bugzilla at aka dot mcc dot id dot au wrote: > When compiling GNU classpath (CVS 20060901) with gcj, I get a > java.lang.VerifyError when running a Swing app with cacao: That is almost certainly a byte code generation bug in gcj. Could you try to recompile GNU Classpath with a different compiler (configure --with-jikes or --with-ecj) if you have one installed to double check? Thanks, Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29013
[Bug java/32638] Wrong selection of field in inner class when outer class and super class have a relevant filed named the same
--- Comment #2 from mark at gcc dot gnu dot org 2007-07-05 18:34 --- Subject: Re: Wrong selection of field in inner class when outer class and super class have a relevant filed named the same > --- Comment #1 from tromey at gcc dot gnu dot org 2007-07-05 17:31 > --- > I tried this with svn trunk and got 'false'. > If there is a bug here it is in ecj, not gcj. Wow, that is interesting. Which ecj version are you using? v_686_R32x, 3.2.2 release gives "true". > I'm not sure I agree with your interpretation here. > I don't see how specificity applies. Isn't that term only used > for overload resolution? It's been a while since I was completely > familiar with the JLS, though ... where are you reading? I am using the completely wrong terms, sorry about that. I got the idea from JLS second edition 8.3 Field Declarations (but admit to not have had it handy when I filed the bug report, it actually took me some time to find it back): http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#40898 If the class declares a field with a certain name, then the declaration of that field is said to hide any and all accessible declarations of fields with the same name in superclasses, and superinterfaces of the class. The field declaration also shadows (§6.3.1) declarations of any accessible fields in enclosing classes or interfaces, and any local variables, formal method parameters, and exception handler parameters with the same name in any enclosing blocks. If a field declaration hides the declaration of another field, the two fields need not have the same type. A class inherits from its direct superclass and direct superinterfaces all the non-private fields of the superclass and superinterfaces that are both accessible to code in the class and not hidden by a declaration in the class. Since it mentions that the field declaration shadows the local variables of the enclosing block (the method) and not the enclosing class and that it inherits the fields (which I take to mean also shadows) I believe my interpretation is correct. > IMO the JLS could be clearer here, but I believe the local 'o' > shadows the field a.o. See: > > http://java.sun.com/docs/books/jls/third_edition/html/names.html#34133 > > Anyway, I suggest filing against ecj or perhaps the JDK for resolution. Yeah, it certainly is confusing. I need all my language lawyer skills to even defend my bug report :) All I really want is a big fat warning from the compiler for this type of usage because it clearly is something that takes a long debate to even see who is right and why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32638
[Bug java/24162] internal compiler error, make_class_data
--- Additional Comments From mark at gcc dot gnu dot org 2005-10-01 17:40 --- Subject: Re: New: internal compiler error, make_class_data On Sat, 2005-10-01 at 15:33 +, bflat1 at gmx dot net wrote: > Class path starts here: > ./ > /usr/java/j2sdk1.4.1_03/jre/lib/rt.jar/ (zip) > /usr/share/java/libgcj-4.0.2.jar/ (system) (zip) > java/lang/String.java:18: internal compiler error: in make_class_data, at > java/class.c:1760 gcj shouldn't crash of course, but are you sure that rt.jar on your Class path is correct? Kaffe comes with an rt.jar which contains kaffe's bootstrap classes, some other runtimes also ship with something called rt.jar. But gcj doesn't. Mixing bootstrap classes from different compilers/runtimes doesn't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24162
[Bug java/23283] Sun's JIT faster than gcc for Random.nextDouble
--- Additional Comments From mark at klomp dot org 2005-08-23 14:31 --- Subject: Re: Sun's JIT faster than gcc for Random.nextDouble It looks like the problem is that we don't remove the synchronization for nextDouble() even though the test case is single-threaded. qprof: /tmp/x: 299 samples, 299 counts X::main(JArray*):X.java:8 5 ( 2%) libc.so.6(memchr)1 ( 0%) libgcj.so.6 2 ( 1%) libgcj.so.6(_Jv_MonitorEnter)110( 37%) libgcj.so.6(_Jv_MonitorExit) 108( 36%) libgcj.so.6(_ZN4java4util6Random4nextEi) 27 ( 9%) libgcj.so.6(_ZN4java4util6Random10nextDoubleEv) 46 ( 15%) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23283
[Bug java/19586] gij exits with SIGABR
--- Additional Comments From mark at klomp dot org 2005-01-27 20:56 --- Subject: Re: gij exits with SIGABR Do you hav some locale set? Try running your program with LANG=C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19586
[Bug java/19586] gij exits with SIGABR
--- Additional Comments From mark at klomp dot org 2005-01-27 22:44 ---
Subject: Re: gij exits with SIGABR
Could you try running it under gdb and show the backtrace when it
aborts.
$ gdb gij
> run Test
{... Abort ...}
> bt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19586
[Bug java/19882] fail to create shared lib from jar - 2 instances, xerces and log4
--- Additional Comments From mark at klomp dot org 2005-02-10 23:00 --- Subject: Re: New: fail to create shared lib from jar - 2 instances, xerces and log4 Hi, On Thu, 2005-02-10 at 22:08 +, delarosa at ilstechnology dot com wrote: > [EMAIL PROTECTED] xerces-2_5_0]$ gcj -shared -o xerces.so *.jar > org/apache/xerces/util/DOMUtil.java: In class > `org.apache.xerces.util.DOMUtil': > org/apache/xerces/util/DOMUtil.java: In method > `org.apache.xerces.util.DOMUtil.copyInto(org.w3c.dom.Node,org.w3c.dom.Node)': > org/apache/xerces/util/DOMUtil.java:0: error: cannot find file for class > org.w3c.dom.events.EventTarget > org/apache/xerces/util/DOMUtil.java:0: error: cannot find file for class > org.w3c.dom.events.DocumentEvent > org/apache/xerces/util/DOMUtil.java:0: error: cannot find file for class > org.w3c.dom.events.DocumentEvent > org/apache/xerces/util/DOMUtil.java:0: confused by earlier errors, bailing out The new org.w3c.dom.events packages were recently added to gcc 4.0 (CVS). Could you retry with a CVS version? > [EMAIL PROTECTED] lib]$ gcj --shared -o log4j.so *jar > org/apache/log4j/chainsaw/LoadXMLAction.java: In class > `org.apache.log4j.chainsaw.LoadXMLAction': > org/apache/log4j/chainsaw/LoadXMLAction.java: In constructor > `(javax.swing.JFrame,org.apache.log4j.chainsaw.MyTableModel)': > org/apache/log4j/chainsaw/LoadXMLAction.java:43: error: cannot find file for > class javax.xml.parsers.SAXParserFactory > org/apache/log4j/chainsaw/LoadXMLAction.java:43: error: cannot find file for > class javax.xml.parsers.SAXParserFactory > org/apache/log4j/chainsaw/LoadXMLAction.java:43: error: cannot find file for > class javax.xml.parsers.SAXParser > org/apache/log4j/chainsaw/LoadXMLAction.java:68: error: cannot find file for > class javax.xml.parsers.SAXParserFactory > org/apache/log4j/chainsaw/LoadXMLAction.java:68: confused by earlier errors, > bailing out Same for the javax.xml.parsers package. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19882
