From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3012 invoked by alias); 27 Sep 2010 20:46:11 -0000 Received: (qmail 2980 invoked by uid 22791); 27 Sep 2010 20:46:11 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50,TW_GC,TW_IB,TW_JS,TW_JV X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Sep 2010 20:46:07 +0000 From: "howarth at nitro dot med.uc.edu" To: java-prs@gcc.gnu.org Subject: [Bug java/45773] New: gcj fails to compile java X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: java X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: howarth at nitro dot med.uc.edu X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: aph at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Resolution Status Resolution CC CC CC CC Status Last reconfirmed date AssignedTo Ever Confirmed Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 27 Sep 2010 20:46:00 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2010-q3/txt/msg00064.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45773 Summary: gcj fails to compile java Product: gcc Version: 4.6.0 Status: ASSIGNED Severity: normal Priority: P3 Component: java AssignedTo: aph@gcc.gnu.org ReportedBy: howarth@nitro.med.uc.edu CC: aph@redhat.com, aph@gcc.gnu.org, joseph@codesourcery.com, iains@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 Last reconfirmed 2010-09-27 16:57:09 date: Andrew Pinski changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID Jack Howarth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | CC| |joseph at codesourcery dot | |com CC| |iains at gcc dot gnu.org CC| |aph at redhat dot com Andrew Haley changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aph at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2010.09.27 16:57:09 date| | AssignedTo|unassigned at gcc dot |aph at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Current gcc trunk, r164573, patched with... http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01914.html to solve the darwin bootstrap, fails to compile java files. The simple testme.java file... public class testme { public static void main(String args[]){ System.out.println("Hello"); } } fails to compile with... gcj --main=testme -O testme.java Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.GCCMain at gnu.java.lang.MainThread.run(libgcj.12.dylib) Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.batch.GCCMain not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/sw/share/java/ecj/ecj.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(libgcj.12.dylib) at java.lang.ClassLoader.loadClass(libgcj.12.dylib) at java.lang.ClassLoader.loadClass(libgcj.12.dylib) at gnu.java.lang.MainThread.run(libgcj.12.dylib) --- Comment #1 from Andrew Pinski 2010-09-24 02:56:31 UTC --- > java.lang.NoClassDefFoundError: > org.eclipse.jdt.internal.compiler.batch.GCCMain That means you don't have ecj installed. You can installed it via contrib/download_ecj and follow the instructions in that file. --- Comment #2 from Jack Howarth 2010-09-25 02:08:58 UTC --- ecj.jar is installed in the source directory before configure is executed. This approach has worked for several gcc releases including gcc 4.5.2. So far the regression appears as far back as r163970 so the stack boundary fixes at r163971 are not to blame. --- Comment #3 from Jack Howarth 2010-09-25 03:21:22 UTC --- Problem doesn't exist at r162829. --- Comment #4 from Jack Howarth 2010-09-25 07:05:40 UTC --- Regression is not present at r163768 but is present at r163770 with r163814 backported to allow libjava to build. Thus the regression is introduced with... Author: jsm28 Date: Thu Sep 2 11:41:22 2010 New Revision: 163770 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163770 Log: PR driver/44076 * opts.h (struct cl_option): Add alias_arg, neg_alias_arg and alias_target fields. * opt-functions.awk (opt_sanitized_name): Don't handle finline-limit=, Wlarger-than= and ftemplate-depth= specially. * optc-gen.awk: Generate alias fields. * opth-gen.awk: Explicitly give values for OPT_* enum constants. Don't generate such constants for aliases. * opts-common.c (generate_canonical_option): New. (decode_cmdline_option): Handle aliases. Use generate_canonical_option for known options instead of copying the input option text. * doc/options.texi (Alias): Document. * common.opt (W, Wlarger-than-, aux-info=, finline-limit-, fstack-check, specs): Mark as aliases. * gcc.c (driver_handle_option): Canonicalize -L options to joined arguments. (driver_handle_option): Don't handle OPT_specs. * opts.c (common_handle_option): Don't handle options marked as aliases. (enable_warning_as_error): Handle aliases. * stor-layout.c (layout_decl): Use OPT_Wlarger_than_ instead of OPT_Wlarger_than_eq. * tree-optimize.c (tree_rest_of_compilation): Use OPT_Wlarger_than_ instead of OPT_Wlarger_than_eq. c-family: * c.opt (Wcomments, Werror-implicit-function-declaration, ftemplate-depth-, std=c89, std=c9x, std=gnu89, std=gnu9x, std=iso9899:1990, std=iso9899:1999, std=iso9899:199x): Mark as aliases. * c-common.c (option_codes): Use OPT_Wcomment instead of OPT_Wcomments. * c-opts.c (warning_as_error_callback, c_common_handle_option): Don't handle options marked as aliases. java: * lang.opt (CLASSPATH, bootclasspath, classpath, encoding, fCLASSPATH=): Mark as Java options and as aliases. * jvspec.c (jvgenmain_spec): Don't handle -fCLASSPATH*. (lang_specific_driver): Don't handle options marked as aliases. * lang.c (java_handle_option): Don't handle OPT_fCLASSPATH_. testsuite: * gcc.dg/cpp/warn-comments-3.c: New. Based on warn-comments-2.c but using -Werror=comment. * gcc.dg/cpp/warn-comments.c, gcc.dg/cpp/warn-comments-2.c: Adjust expected error messages. --- Comment #5 from Jack Howarth 2010-09-25 14:20:13 UTC --- The libjava testsuite is badly in need of testcase for compiling a java source file. Currently all of the test gcj tests are done using precompiled class files and breakage in gcj for compilation of java source files goes unreported on gcc-testresults. --- Comment #6 from joseph at codesourcery dot com 2010-09-25 17:36:07 UTC --- The only Java issue I know of with r163770 was fixed in r163814. If the problem you have was not fixed there you'll need to investigate further. --- Comment #7 from joseph at codesourcery dot com 2010-09-25 17:39:37 UTC --- That is, exactly what is different about how subprocesses are invoked before/after those changes? --- Comment #8 from Jack Howarth 2010-09-26 01:53:53 UTC --- This problem is also reproducible under x86_64 Fedora 10 Linux with current gcc trunk using the following steps... cd gcc wget -c ftp://sourceware.org/pub/java/ecj-latest.jar mv ecj-latest.jar ecj.jar cd ../work ../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr --prefix=/home/howarth/dist --enable-languages=c,c++,java make -j 8 make install cd .. ./dist/bin/gcj --main=testme -O testme.java Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.GCCMain at gnu.java.lang.MainThread.run(libgcj.so.9) Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.batch.GCCMain not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(libgcj.so.9) at java.lang.ClassLoader.loadClass(libgcj.so.9) at java.lang.ClassLoader.loadClass(libgcj.so.9) at gnu.java.lang.MainThread.run(libgcj.so.9) --- Comment #9 from Jack Howarth 2010-09-26 02:54:13 UTC --- (In reply to comment #7) > That is, exactly what is different about how subprocesses are invoked > before/after those changes? I don't see any particular differences in the command generated for ecj1. In both cases, it is... /home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/ecj1 -v testme.java -fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency testme.zip -fzip-target testme.jar however after r163770, this results in the error... Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.GCCMain at gnu.java.lang.MainThread.run(libgcj.so.9) Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.batch.GCCMain not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(libgcj.so.9) at java.lang.ClassLoader.loadClass(libgcj.so.9) at java.lang.ClassLoader.loadClass(libgcj.so.9) at gnu.java.lang.MainThread.run(libgcj.so.9) whereas before r163770 the commands... COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v' '-save-temps' '-O' '-fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/jc1 testme.jar -fsource-filename=testme.java -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase testme.java -mtune=generic -march=x86-64 -auxbase testme -O -version -fsaw-java-file -fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar -faux-classpath testme.zip -o testme.s were executed instead. --- Comment #10 from joseph at codesourcery dot com 2010-09-26 14:47:56 UTC --- On Sun, 26 Sep 2010, howarth at nitro dot med.uc.edu wrote: > --- Comment #1 from Andrew Pinski 2010-09-24 02:56:31 UTC --- > --- Comment #2 from Jack Howarth 2010-09-25 02:08:58 UTC --- > --- Comment #3 from Jack Howarth 2010-09-25 03:21:22 UTC --- > --- Comment #4 from Jack Howarth 2010-09-25 07:05:40 UTC --- > --- Comment #5 from Jack Howarth 2010-09-25 14:20:13 UTC --- > --- Comment #6 from joseph at codesourcery dot com 2010-09-25 17:36:07 UTC --- > --- Comment #7 from joseph at codesourcery dot com 2010-09-25 17:39:37 UTC --- > --- Comment #8 from Jack Howarth 2010-09-26 01:53:53 UTC --- > --- Comment #9 from Jack Howarth 2010-09-26 02:54:13 UTC --- The messages from this bug are becoming less and less useful as each one repeats all of the previous comments and none are actually being CC:ed to me. > I don't see any particular differences in the command generated for ecj1. In > both cases, it is... > > /home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/ecj1 -v > testme.java -fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar > -fsource=1.5 -ftarget=1.5 -fzip-dependency testme.zip -fzip-target testme.jar > > however after r163770, this results in the error... So, if you build and install a version that works for you, then run this command manually, it works, but if you build and install a version that doesn't work for you, and run the same ecj1 command, that ecj1 command fails? So there is some issue with ecj1 being miscompiled? (I don't think ecj1 contains any code affected by my patch at all.) --- Comment #11 from Jack Howarth 2010-09-26 15:17:23 UTC --- (In reply to comment #10) > So, if you build and install a version that works for you, then run this > command manually, it works, but if you build and install a version that > doesn't work for you, and run the same ecj1 command, that ecj1 command > fails? So there is some issue with ecj1 being miscompiled? (I don't > think ecj1 contains any code affected by my patch at all.) No, it is very simple. If you build gcc with ecj.jar in the source directory and attempt to compile java source files using gcj (not using precompiled classes as the test suite does), the gcj compiler crashes before it can emit the subprocess for ecj1. This issue appears with the commit of r163770 and is still present in current gcc trunk. It did not exist before r163770. You should be able to very easily reproduce this bug under linux. --- Comment #12 from Jack Howarth 2010-09-26 15:48:33 UTC --- FYI, the original patch which added support for building against ecj.jar can be found here... http://gcc.gnu.org/ml/java-patches/2006-q4/msg00061.html --- Comment #13 from joseph at codesourcery dot com 2010-09-26 17:40:16 UTC --- On Sun, 26 Sep 2010, howarth at nitro dot med.uc.edu wrote: > --- Comment #11 from Jack Howarth 2010-09-26 15:17:23 UTC --- > (In reply to comment #10) > > > So, if you build and install a version that works for you, then run this > > command manually, it works, but if you build and install a version that > > doesn't work for you, and run the same ecj1 command, that ecj1 command > > fails? So there is some issue with ecj1 being miscompiled? (I don't > > think ecj1 contains any code affected by my patch at all.) > > No, it is very simple. If you build gcc with ecj.jar in the source directory > and attempt to compile java source files using gcj (not using precompiled > classes as the test suite does), the gcj compiler crashes before it can emit > the subprocess for ecj1. This issue appears with the commit of r163770 and is This doesn't make sense to me. You previously quoted an exception which appeared to come from the ecj1 process (or at least, from some program written in Java). Please clarify: does ecj1 run or not in each case? Does it give an error or not in each case? What if you swap ecj1 binaries from before/after the change, given a driver from before the change? What if you swap driver (gcj) binaries from before/after the change, given ecj1 from before the change? --- Comment #14 from Jack Howarth 2010-09-26 18:24:40 UTC --- The crash under x86_64 linux.... ./dist/bin/gcj -v --main=testme -O testme.java Using built-in specs. Reading specs from /home/howarth/dist/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig COLLECT_GCC=./dist/bin/gcj COLLECT_LTO_WRAPPER=/home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr --prefix=/home/howarth/dist --enable-languages=c,c++,java Thread model: posix gcc version 4.6.0 20100926 (experimental) (GCC) COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v' '-O' '-fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/ecj1 testme.java -fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /tmp/ccBcVSIa.zip -fzip-target /tmp/ccMm0Hhb.jar Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.GCCMain at gnu.java.lang.MainThread.run(MainThread.java:100) Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.batch.GCCMain not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(URLClassLoader.java:531) at java.lang.ClassLoader.loadClass(ClassLoader.java:452) at java.lang.ClassLoader.loadClass(ClassLoader.java:387) at gnu.java.lang.MainThread.run(MainThread.java:96) and the crash under x86_64-apple-darwin10... gcj -v --main=testme -O testme.java Using built-in specs. Reading specs from /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig COLLECT_GCC=gcj COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.5.0 Configured with: ../gcc-4.6-20100925/configure --prefix=/sw --prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6 --enable-checking=yes Thread model: posix gcc version 4.6.0 20100925 (experimental) (GCC) COLLECT_GCC_OPTIONS='-fsaw-java-file' '-mmacosx-version-min=10.6.5' '-v' '-O' '-fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.6/share/java/libgcj-4.6.0.jar' '-shared-libgcc' '-mtune=generic' /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.6/share/java/libgcj-4.6.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccIICjFy.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccDWYcg6.jar Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.GCCMain at gnu.java.lang.MainThread.run(libgcj.12.dylib) Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.batch.GCCMain not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/sw/share/java/ecj/ecj.jar,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} at java.net.URLClassLoader.findClass(libgcj.12.dylib) at java.lang.ClassLoader.loadClass(libgcj.12.dylib) at java.lang.ClassLoader.loadClass(libgcj.12.dylib) at gnu.java.lang.MainThread.run(libgcj.12.dylib) are both in ecj1 and effectively identical. --- Comment #15 from Jack Howarth 2010-09-26 18:28:19 UTC --- Also note comment 2. The regression caused by r163770 looks very much like what one would get from not having ecj.jar installed (or in this case not being able to fine the classes from ecj.jar). --- Comment #16 from Andrew Haley 2010-09-27 15:28:07 UTC --- The problem is due to gcj's arg processing being broken. This test case: public class Test { public static void main(String[] args) { System.out.println(System.getProperty("java.class.path")); } } $ javac Test.java $ ~/gcc/trunk/install/bin/gcj Test.class --main=Test -Djava.class.path=/home/aph/gcc/trunk/install/share/java/ecj.jar $ $ LD_LIBRARY_PATH=~/gcc/trunk/install/lib64/ ./a.out . Should be: $ /usr/bin/gcj Test.java --main=Test -Djava.class.path=/home/aph/gcc/trunk/install/share/java/ecj.jar $ ./a.out /home/aph/gcc/trunk/install/share/java/ecj.jar So, -D arguments are no longer being processed after the arg processing changes. --- Comment #17 from joseph at codesourcery dot com 2010-09-27 16:55:35 UTC --- On Mon, 27 Sep 2010, aph at gcc dot gnu.org wrote: > The problem is due to gcj's arg processing being broken. > > This test case: > > public class Test > { > public static void main(String[] args) > { > System.out.println(System.getProperty("java.class.path")); > } > } > > $ javac Test.java > $ ~/gcc/trunk/install/bin/gcj Test.class --main=Test > -Djava.class.path=/home/aph/gcc/trunk/install/share/java/ecj.jar > $ $ LD_LIBRARY_PATH=~/gcc/trunk/install/lib64/ ./a.out > . > > Should be: > > $ /usr/bin/gcj Test.java --main=Test > -Djava.class.path=/home/aph/gcc/trunk/install/share/java/ecj.jar > $ ./a.out > /home/aph/gcc/trunk/install/share/java/ecj.jar > > So, -D arguments are no longer being processed after the arg processing > changes. Thanks. Since ecj1 doesn't appear to receive -D options I think the most likely possibility is that HJ's patch to make jvgenmain handle -D options with separate argument was not in fact a complete fix for this issue. Try this untested patch or something similar. Index: jvgenmain.c =================================================================== --- jvgenmain.c (revision 164647) +++ jvgenmain.c (working copy) @@ -124,7 +124,10 @@ { const char *p; fprintf (stream, " \""); - for (p = &argv[i][2]; *p; ++p) + p = &argv[i][2]; + if (*p == '\0') + p = &argv[++i][0]; + for (; *p; ++p) { if (! ISPRINT (*p)) fprintf (stream, "\\%o", *p); --- Comment #18 from Andrew Haley 2010-09-27 16:56:12 UTC --- Created attachment 21896 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21896 It's a patch. --- Comment #19 from Jack Howarth 2010-09-27 20:45:45 UTC --- (In reply to comment #18) > Created attachment 21896 [details] > It's a patch. This patch solves both test cases under x86_64 Fedora 10 linux (although a complete bootstrap was required).