[Bug java/9861] method name mangling ignores return type
--- Comment #8 from rmathew at gcc dot gnu dot org 2006-05-15 07:04 --- This was fixed by TJ's patch applied on 2005-12-10. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9861
[Bug java/27643] ICE in java_mark_cni_decl_local compiling bytecode->native
--- Comment #1 from rmathew at gcc dot gnu dot org 2006-05-18 07:36 --- I'm not able to reproduce this problem with the current mainline (2006-05-18). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27643
[Bug java/27643] ICE in java_mark_cni_decl_local compiling bytecode->native
--- Comment #3 from rmathew at gcc dot gnu dot org 2006-05-22 08:56 --- OK, I was able to reproduce this. My problem was that I had a "--disable-checking" build. If the order of the class files is "PipeImpl.class VMPipe.class", I get an error; if the order is the other way around, I don't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27643
[Bug bootstrap/25502] Werror problem in build
--- Comment #6 from rmathew at gcc dot gnu dot org 2006-06-04 09:47 --- By the way, x-mingw32 contains: # On MinGW, we use "%IA64d" to print 64-bit integers, and the format-checking # code does not handle that, so we have to disable checking here. WERROR_FLAGS += -Wno-format This should have fixed the problem, but it doesn't for some reason. See also: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02223.html (and the follow-up messages). -- rmathew at gcc dot gnu dot org changed: What|Removed |Added CC| |rmathew at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug target/19970] Java Disabled for MinGW
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-06-07 12:55 --- Via this change: http://gcc.gnu.org/viewcvs/trunk/configure.in?r1=114048&r2=114435 we now have Boehm-GC also added to the things that are unnecessarily disabled for MinGW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19970
[Bug libgcj/28263] New: [win32] Memory Leak In Cleaning Exception Handling Contexts
There is a leak of 24 bytes of exception handling context per Java thread on MinGW due to a hack that fools the MinGW runtime into thinking that multi-threaded exception handling is in effect but avoids linking to the correct __mingwthr_key_dtor() from mingwm10.dll and instead links to a dummy version from libmingw32.a. See also: http://gcc.gnu.org/ml/java/2003-04/msg00046.html http://gcc.gnu.org/ml/java/2006-07/msg00014.html http://gcc.gnu.org/ml/java/2006-07/msg00017.html A workaround for avoiding this leak is to explicitly use -mthreads while linking Java programmes with GCJ. -- Summary: [win32] Memory Leak In Cleaning Exception Handling Contexts Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmathew at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28263
[Bug libstdc++/28265] New: iconv-related errors while building a cross-compiler for MinGW
"libstdc++-v3/include/ext/codecvt_specializations.h" uses iconv_t and causes
errors while building an i686-pc-linux-gnu to i686-pc-mingw32 cross-compiler.
(I'm at trunk revision 115196.)
Strangely however, this does not cause a build failure and is therefore not
catastrophic for this target.
GCC was configured as:
$GCC_SRC_DIR/configure --prefix=$PREFIX \
--with-sysroot="$SYSROOT" --with-build-sysroot="$SYSROOT" \
--target=$TARGET --host=$HOST --build=$BUILD \
--enable-languages=c,c++,java \
--with-gnu-as --with-gnu-ld \
--disable-nls --disable-debug --disable-shared --disable-checking \
--enable-threads=win32 --disable-win32-registry --enable-sjlj-exceptions \
--enable-libgcj
I will attach the part of the build log that shows this error.
--
Summary: iconv-related errors while building a cross-compiler for
MinGW
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmathew at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28265
[Bug libstdc++/28265] iconv-related errors while building a cross-compiler for MinGW
--- Comment #1 from rmathew at gcc dot gnu dot org 2006-07-05 07:32 --- Created an attachment (id=11823) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11823&action=view) The portion of the build log that shows the error reported in this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28265
[Bug java/28329] [ecj] gcj leaves .jar and .zip files in /tmp
--- Comment #1 from rmathew at gcc dot gnu dot org 2006-07-11 01:20 --- Perhaps the "%d" string was omitted in the relevant specs: http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html Just guessing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28329
[Bug libgcj/28352] Interpreter: Stack trace line numbers sometimes missing or incorrect
--- Comment #2 from rmathew at gcc dot gnu dot org 2006-07-12 01:46 --- Confirmed. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-12 01:46:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28352
[Bug java/25001] dos equis
--- Comment #2 from rmathew at gcc dot gnu dot org 2005-11-24 09:33 --- Confirmed on mainline. Also confirmed that GCJX does not have this bug. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-24 09:33:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25001
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
-- rmathew at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rmathew at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug libgcj/20135] Returning true from LinkedHashMap.removeEldestEntry does not remove entry
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-22 07:51 --- This was fixed a couple of days ago: http://lists.gnu.org/archive/html/classpath/2005-02/msg00085.html -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20135
[Bug libgcj/20136] Endless loop when using a SecurityManager
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-22 08:02 --- I *hate* to be doing this, but once again, this is fixed on current mainline. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20136
[Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-23 11:10 --- Does backing out this patch help? http://gcc.gnu.org/ml/java-patches/2005-q1/msg00402.html (See also: PR 20155) -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug java/5537] Error compiling simple bytecode with jsr
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-02 07:54 --- (In reply to comment #13) > What's the take on this bug? Can indirect-dispatch be made the default in the > foreseable future? Can the old verifier be fixed? > > I'm now running nightly builds of gcj on the Nice compiler testsuite (1250 > testcases). There are currently 11 failures, and 4 seem to be instances of > this > verifier bug. So fixing this would be a great improvement. See: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00568.html which makes even the non-indirect-dispatch case use the new shiny verifier. It definitely fixes this PR and a whole lot of other verifier bugs. Can you test it with your application too? (Thanks in advance for doing it.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5537
[Bug java/5537] Error compiling simple bytecode with jsr
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-02 13:09 --- > OK, I patched my tree, I'll report the results (fixes and regressions) > after the next build. Thanks. > In your list message, you mention only one fix in the gcc testsuite, > pr13107. Does this mean pr5537 is not fixed, or it does not have a testcase? The latter. We do not have any bytecode verification tests in the libjava testsuite (yet). We use the Mauve verifier testsuite instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5537
[Bug java/20351] compilation with a redundant jar fails, if output file specified
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-08 09:56 --- FWIW, with the new verifier enabled this seems to work just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20351
[Bug java/20362] ICE: bus error if missed interface used in abstract class and output file specified
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-08 10:05 --- As of 2005-03-08, this testcase works quite fine for me with mainline CVS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20362
[Bug libgcj/20391] New: gcj-dbtool shows incorrect error message if JAR and DSO are switched on the command line
If the JAR and DSO are switched on the command line
to "gcj-dbtool -a", it shows an incorrect error message:
~/src/tmp > gcj-dbtool -a foo.db foo.so foo.jar
error: could not update foo.db: java.lang.NullPointerException
--
Summary: gcj-dbtool shows incorrect error message if JAR and DSO
are switched on the command line
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmathew at gcc dot gnu dot org
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=20391
[Bug java/5537] Error compiling simple bytecode with jsr
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 09:04 --- Now that the new verifier has been enabled, this bug has been fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5537
[Bug java/12734] gcj verifier doesn't merge interface types correctly
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 09:06 --- This bug should have been fixed by enabling the new verifier. Can you please check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12734
[Bug java/13378] gcj compiling from jar files - verification error
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 09:11 --- (In reply to comment #0) > > The jar-files which caused the problem: > http://www.scheinwelt.at/~norbertf/gcj/tests/gcjverifybug_test.tar.gz I could not download this file - can you please put it back in? Mainline CVS now has GCJ using a new verifier that should fix most verifier bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13378
[Bug java/19344] Java verification error: types could not be merged
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 09:15 --- Fixed on the mainline after the new verifier was enabled. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19344
[Bug java/13378] gcj compiling from jar files - verification error
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 10:26 --- Thanks. Now the verification errors are gone, but I'm still not able to build the package (with or without -findirect-dispatch): 8< ~/src/tmp/PR13378/gcjverifybug > make /home/ranmath/src/gcc/build/gcc/gcj -B/home/ranmath/src/gcc/build/gcc/ -B/home/r anmath/src/gcc/build/i686-pc-linux-gnu/libjava/ -I/home/ranmath/src/gcc/build/i6 86-pc-linux-gnu/libjava/libgcj-4.1.0.jar -L/home/ranmath/src/gcc/build/i686-pc-l inux-gnu/libjava/.libs -findirect-dispatch -fCLASSPATH=swt.jar:xerces.jar -c jfa ce-standalone.jar -o jface_standalone.o org/eclipse/jface/util/OpenStrategy.java: In class 'org.eclipse.jface.util.OpenS trategy$1': org/eclipse/jface/util/OpenStrategy.java: In method 'org.eclipse.jface.util.Open Strategy$1.handleEvent(org.eclipse.swt.widgets.Event)': org/eclipse/jface/util/OpenStrategy.java:336: error: expected type 'java.lang.Ru nnable[]' but stack contains 'java.lang.Object' org/eclipse/jface/util/OpenStrategy.java:336: error: stack underflow org/eclipse/jface/util/OpenStrategy$1.java:0: confused by earlier errors, bailin g out make: *** [default] Error 1 8< -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13378
[Bug java/20362] ICE: bus error if missed interface used in abstract class and output file specified
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 10:55 --- I do not see an ICE with the given testcase as of 2005-03-09 and mainline CVS. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20362
[Bug java/20351] compilation with a redundant jar fails, if output file specified
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 10:57 --- Now that the new verifier has been enabled, this works quite fine. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20351
[Bug java/18212] nativ compilation with multiple jars fails / gives internal compiler error
-- Bug 18212 depends on bug 20351, which changed state. Bug 20351 Summary: compilation with a redundant jar fails, if output file specified http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20351 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18212
[Bug java/18212] nativ compilation with multiple jars fails / gives internal compiler error
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 11:03 --- I can still see a crash similar to what Tom is seeing, but the other two bugs are fixed - the break-up was not correct. -- What|Removed |Added BugsThisDependsOn|20351 | Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18212
[Bug java/20338] Program compiled with gcj crashes when accessing private static method from nested class
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 12:39 --- The problem is that we leave out a call to _Jv_InitClass for a static private method thinking that it is unreachable. This is not the case for a private static inner class method. A simple pessimistic fix is: Index: decl.c === --- decl.c 2005-03-09 17:16:36.0 +0530 +++ decl.c 2005-03-09 17:17:18.0 +0530 @@ -2039,5 +2039,5 @@ finish_method (tree fndecl) /* Prepend class initialization for static methods reachable from other classes. */ - if (METHOD_STATIC (fndecl) && ! METHOD_PRIVATE (fndecl) + if (METHOD_STATIC (fndecl) && ! DECL_CLINIT_P (fndecl) && ! CLASS_INTERFACE (TYPE_NAME (DECL_CONTEXT (fndecl -- What|Removed |Added Last reconfirmed|2005-03-05 23:20:15 |2005-03-09 12:39:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
[Bug java/20338] Program compiled with gcj crashes when accessing private static method from nested class
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-09 14:51 --- A proposed patch is here: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00684.html As noted there, there is still a problem with either GCJ or gij for this testcase. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
[Bug java/20338] Program compiled with gcj crashes when accessing private static method from nested class
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-10 11:00 --- While the main problem reported by the filer has now been fixed on mainline, I think we should not close this PR just yet - not until we check in a testcase for our testsuite for this, which is not possible till PR19870 is fixed. Otherwise, we can close this one and add a note to PR19870 to remember to add in the testcase for this PR when that is fixed. -- What|Removed |Added BugsThisDependsOn||19870 Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
[Bug java/20338] Program compiled with gcj crashes when accessing private static method from nested class
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-10 12:00 --- (In reply to comment #7) > Why not check in the test case and XFAIL it? I feel dumb for not having thought of it myself... I am closing this bug and will submit the testcase as a separate patch. Thanks. -- What|Removed |Added BugsThisDependsOn|19870 | Status|SUSPENDED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20338
[Bug java/20312] No warning on bad method
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-10 13:30 --- A patch is here: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00710.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20312
[Bug java/20418] New: ICE if variable name is ommitted in an initialiser and a qualified type for the variable is used
This very simple testcase fails with an ICE on mainline:
-- 8< --
~/src/tmp > $MYGCJ --version
gcj (GCC) 4.1.0 20050311 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
~/src/tmp > cat Snafu.java
public class Snafu
{
public static void main( String[] args)
{
java.io.File = new java.io.File( "junk");
}
}
~/src/tmp > $MYGCJ --syntax-only Snafu.java
Snafu.java: In class 'Snafu':
Snafu.java: In method 'Snafu.main(java.lang.String[])':
Snafu.java:5: internal compiler error: internal error in check-init: tree code n
ot implemented: type_decl
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
-- 8< --
--
Summary: ICE if variable name is ommitted in an initialiser and a
qualified type for the variable is used
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmathew at gcc dot gnu dot org
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=20418
[Bug java/20418] ICE if variable name is ommitted in an initialiser and a qualified type for the variable is used
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-11 09:16 --- Of course it's true - you think I'd lie? ;-) -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-11 09:16:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20418
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-09-01 09:36 --- I think it is the same problem with Boehm-GC on ARM/Linux that has been solved in upstream sources. See: http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-July/000943.html http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-August/000963.html The relevant file can be found as $GCC_SRC_DIR/boehm-gc/include/private/gcconfig.h You should rebuild GCC after making this change and try if it solves the problem for you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-09-02 09:41 --- (In reply to comment #10) > (In reply to comment #9) > > I think it is the same problem with Boehm-GC on ARM/Linux that > > has been solved in upstream sources. > > Has this fix been officially submited to gcc for inclusion in 4.0.X? We import the Boehm-GC from time to time into mainline CVS (GCC) from upstream sources. I think upstream sources already have this patch applied. It is unlikely that the 4.0.x series will pick up an updated Boehm-GC, though mainline can (although it is a bit too close to the 4.1 freeze). In the interim, you can see if this resolves your issue and get by with a local patch. > Are any fixes required on the target itself (ie. in it's libraries) or just on > the arm-linux-gcj cross compiler source? Sorry, I don't know the answer to this as I work on x86-linux only. But from perusing the related messages, it does not look like any other change is needed, but I might be mistaken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug libgcj/20684] FileChannelImpl.java fails to sync filedescriptor on force() invocation
-- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20684
[Bug java/23431] [4.0/4.1 regression] gcj allows overriding with more restrictive access
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-09-05 15:06 --- Fix checked in to mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23431
[Bug java/13607] [meta-bug] access problems in java front-end
-- Bug 13607 depends on bug 23431, which changed state. Bug 23431 Summary: [4.0/4.1 regression] gcj allows overriding with more restrictive access http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23431 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13607
[Bug java/20031] [4.0/4.1 regression] ICE on missing files
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-09-09 10:13 --- One proposal for a patch is here: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00313.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/java- ||patches/2005- ||q3/msg00313.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20031
[Bug libgcj/23856] New: Modification Time Incorrectly Set From Extension Entry
I am filing this bug because we still diverge from Classpath for java.util.zip and we need to track this issue. The base bug is PR classpath/23854 and it also applies to libgcj. See: http://gcc.gnu.org/ml/java/2005-09/msg00070.html http://gcc.gnu.org/ml/java/2005-09/msg00072.html The archives in question are attached to the other PR. -- Summary: Modification Time Incorrectly Set From Extension Entry Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmathew at gcc dot gnu dot org 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=23856
[Bug java/21418] Order of source files matters when compiling
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-09-21 09:55 --- Proposed patch: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00401.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/java- ||patches/2005- ||q3/msg00401.html Keywords||patch, rejects-valid 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 rmathew at gcc dot gnu dot org 2005-09-29 07:45 --- (In reply to comment #9) > (In reply to comment #5) > > 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. > > A "naive" backport doesn't work, see the thread starting at > http://gcc.gnu.org/ml/java/2005-09/msg00118.html That's because PR21844 addresses a minor fallout of the first part of the fix for PR19870. The complete fix for PR19870 should only be applied if the fix for PR21844 is also applied after that. -- 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 rmathew at gcc dot gnu dot org 2005-09-29 12:52 --- The fix for PR20338 is also needed by the fix for PR19870. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
[Bug java/24127] ICE in libjava.compile/PR6865.java reported as "PASS" in testsuite.
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-09-30 09:21 --- Confirmed. Patch here: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00484.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/java- ||patches/2005- ||q3/msg00484.html Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-09-30 09:21:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24127
[Bug java/24127] ICE in libjava.compile/PR6865.java reported as "PASS" in testsuite.
--- Comment #3 from rmathew at gcc dot gnu dot org 2005-10-03 17:31 --- Fix checked in. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24127
[Bug java/24454] GCJ does not correctly support strictfp
--- Comment #4 from rmathew at gcc dot gnu dot org 2005-10-21 10:23 --- (In reply to comment #0) > Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch > compiler into ECJ using GCJ. The goal was to provide an executable form of > Eclipse's compiler. Unfortunately, the effort had to be abandoned because the > resulting ECJ compiler would fail the floating point section of Java > Compatibility Kit (JCK). It would be nice if you could at least indicate what kind of non-compliance you are talking of here. Is it strictfp, accuracy of results, rounding of floating-point literals, or something else? Of course, you should not reproduce tests verbatim from the JCK, but please provide some indication of what you're talking about in this bug report. For example, are you talking of JLS3 section 4.2.4 here? If yes, can you please elaborate exactly how using GCJ as the compiler to compile your compiler is affecting its status w.r.t. the JCK? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
[Bug java/24454] GCJ does not correctly support strictfp
--- Comment #5 from rmathew at gcc dot gnu dot org 2005-10-21 10:26 --- (In reply to comment #4) > > It would be nice if you could at least indicate what kind > of non-compliance you are talking of here. Is it strictfp, > accuracy of results, rounding of floating-point literals, > or something else? Of course, you should not reproduce > tests verbatim from the JCK, but please provide some > indication of what you're talking about in this bug report. Sorry, I just noticed that aph was the one who changed the summary to lack of strictfp support. So I guess he knows what you were talking about in the bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
[Bug java/24454] GCJ does not correctly support strictfp
--- Comment #8 from rmathew at gcc dot gnu dot org 2005-10-21 15:14 --- The bug about incorrect parsing and rounding of floating-point literals is PR java/23432 and that about no support for strictfp is PR java/10632. If this bug report is about either of these, it can be closed as a duplicate of the respective previous bug. If it is about both, it can be left as a "meta bug". If it is about neither of the two, then please provide some details and change the summary appropriately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
[Bug java/22166] 0x80000000/-1 is wrong
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-24 09:44 --- This is most likely the same as PR22084 (see the testcase $GCC_SRC_DIR/libjava/testsuite/libjava.lang/Divide_1.java). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22166
[Bug libgcj/22084] [4.1 Regression] Divide_1 test case hangs
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-24 09:47 --- Today (20050624, IST), it seems to have become worse. Till now I used to see 2 FAILs, now I see 6 FAILs: FAIL: Divide_1 execution - source compiled test FAIL: Divide_1 output - gij test FAIL: Divide_1 execution - bytecode->native test FAIL: Divide_1 -O3 output - source compiled test FAIL: Divide_1 output - gij test FAIL: Divide_1 -O3 output - bytecode->native test S.N.A.F.U. -- What|Removed |Added Last reconfirmed|2005-06-17 13:13:47 |2005-06-24 09:47:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084
[Bug java/22214] Java code with Vector does not compile with GCJ
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-28 10:37 --- Yes, GCJ doesn't support generics yet. -- What|Removed |Added OtherBugsDependingO||22091 nThis|| Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-28 10:37:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22214
[Bug libgcj/22580] [4.1 Regression] 'make -j' doesn't affect source->bytecode compilation
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-07-21 11:00 --- Regards, Stickler Sosumi. -- What|Removed |Added Summary|[4.1 Regression] 'make -j' |[4.1 Regression] 'make -j' |doesn't effect source- |doesn't affect source- |>bytecode compilation |>bytecode compilation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22580
[Bug libgcj/22084] [4.1 Regression] Divide_1 test case hangs
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-07-28 07:45 --- Sorry, but I still see the following failures on i686-pc-linux-gnu: FAIL: Divide_1 execution - source compiled test FAIL: Divide_1 execution - bytecode->native test Interestingly, the "-O3" executions produce the correct (expected) results. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084
[Bug java/23230] Wrong "this" used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-08
09:43 ---
Another testcase:
--- 8< ---
class Snafu
{
public void whoami( )
{
System.out.println( this.getClass( ).getName( ));
}
}
public class PR23230 extends Snafu
{
class Foo extends Snafu
{
Foo( )
{
whoami( );
}
}
void bar( )
{
new Foo( );
}
public static void main( String[] args)
{
new PR23230( ).bar( );
}
}
--- 8< ---
--
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
||patches/2005-
||08/msg00321.html
Keywords||patch
Last reconfirmed|2005-08-04 15:23:34 |2005-08-08 09:43:39
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-11 11:38 --- (In reply to comment #2) > > > I cannot debug it further as I debugging with an optimized compiled. cd $GCC_SRC_DIR/gcc/java touch class.c parse.y cd $GCC_BLD_DIR make BOOT_CFLAGS='-g3 -O0' bubblestrap http://gcc.gnu.org/wiki/DebuggingGCC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug java/22113] Buffer overflow in the lexical analyser while reading FP literals
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-14 15:16 --- These days, this bug manifests itself on mainline regularly as: FAIL: 3.10.2-round-6 in the Jacks testsuite. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-14 15:16:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22113
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-14 15:50 --- Updated patch for Part 2 posted in: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00195.html -- What|Removed |Added URL|http://gcc.gnu.org/ml/java- |http://gcc.gnu.org/ml/java- |patches/2005- |patches/2005- |q2/msg00742.html|q3/msg00195.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-16 18:39 --- Last part of the fix has now been checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug java/18131] [meta-bug] inner class problems in java front-end
-- Bug 18131 depends on bug 19870, which changed state. Bug 19870 Summary: gcj -C doesn't generate accessors for private members across nested class boundaries http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131
[Bug java/22113] Buffer overflow in the lexical analyser while reading FP literals
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-16 18:49 --- Fix checked in. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22113
[Bug java/23432] New: Incorrect parsing and rounding off of large floating-point literals
According to JLS 3.10.2: http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.2 large (in the number of characters, not the value) floating-point literal tokens must be rounded off to the nearest representable value. The current mainline (4.1.0 20050817) does not do this. See the attached testcase. Both Jikes and Sun javac (1.5.0.03) correctly compile this class, while GCJ gives: -- 8< -- ~/src/tmp > $MYGCJ --syntax-only Snafu.java Snafu.java:3: error: Numeric overflow for 'int' literal. double foo = 3.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211706798214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196442881097566593344612847564823378678316527120190914564856692346034861045432664821339360726024914127372458700660631558817488152092096282925409171536436789259036001133053054882046652138414695194151160943305727036575959195309218611738193261179310511854807446237996274956735188575272489122793818301194912983367336244065664308602139494639522473719070217986094370277053921717629317675238467481846766940513200056812714526356082778577134275778960917363717872146844090122495343014654958537105079227968925892354201995611212902196086403441815981362977477130996051870721134998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882; ^ Snafu.java:4: error: Class or interface declaration expected. } ^ 2 errors -- 8< -- See also Jacks testcase 3.10.2-round-6 (and other such tests). Eric Blake says: -- 8< -- >>What is the actual length of the longest of the tokens in question >>allowed by the JLS? > Literal token length is technically unlimited - the longest string possible that still parses as a floating point number without causing overflow or underflow must be parsed as such. However, there IS a fixed maximum length of significant characters at which the decision of which exact 2's complement number the decimal string will round to (or can be determined simply by scanning for the first non-zero digit after that length); this limit is determined by the actual base-10 representation of the 1ulp 2's complement denormal. I wrote the jacks tests in question, which purposefully use a 800+ character mantissa of the halfway point between the smallest two denormals, as the longest string of non-zero characters where rounding can make a difference. I don't remember the exact number of significant characters, but you can reverse engineer that from the jacks test. Remember that you need to strip leading zeros of both the mantissa and exponent before starting to count characters towards the limit; fortunately, Java has no way to stringize a literal so you only need to obtain the exact value rather than preserve the original string. On the other hand, since every possible double can be expressed with a decimal string with a maximum of 24 characters (and even fewer characters with hex-float literals in Java 1.5 syntax), only brain-dead compiler test suites are ever likely to give you a literal with more than 256 characters :) -- 8< -- (Ref.: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00218.html) -- Summary: Incorrect parsing and rounding off of large floating- point literals Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmathew at gcc dot gnu dot org 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=23432
[Bug java/23432] Incorrect parsing and rounding off of large floating-point literals
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-17 06:14 --- Created an attachment (id=9509) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9509&action=view) Testcase that demonstrates the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23432
[Bug java/23431] [4.0/4.1 regression] gcj allows overriding with more restrictive access
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-23
09:50 ---
Changed synopsis and component. Added keyword.
Interestingly, the following is (wrongly) accepted:
- 8< -
interface MyRunnable
{
public void run( );
}
class Snafu implements MyRunnable
{
private void run( ) { }
}
- 8< -
but *not* the following:
- 8< -
abstract class MyRunnable
{
public abstract void run( );
}
class Snafu extends MyRunnable
{
private void run( ) { }
}
- 8< -
--
What|Removed |Added
Component|libgcj |java
Keywords||accepts-invalid
Last reconfirmed|2005-08-22 19:12:07 |2005-08-23 09:50:28
date||
Summary|[4.0/4.1 regression] gcj|[4.0/4.1 regression] gcj
|allows overriding with less |allows overriding with more
|restrictive access |restrictive access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23431
[Bug java/23431] [4.0/4.1 regression] gcj allows overriding with more restrictive access
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-23 18:26 --- I have proposed a patch for this problem: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00266.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/java- ||patches/2005- ||q3/msg00266.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23431
[Bug java/22166] 0x80000000/-1 is wrong in java
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-30 07:33 --- Still exists on mainline. At optimisation levels 1,2 and 3, this bug disappears. Also disappears if "-fuse-divide-subroutine" is used. Seems to have been introduced between June 14th and 15th: http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00864.html http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00932.html -- What|Removed |Added Last reconfirmed|2005-08-05 04:09:29 |2005-08-30 07:33:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22166
[Bug java/22166] 0x80000000/-1 is wrong in java
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-30
09:13 ---
Actually, this looks like a more generic problem, not limited to Java.
Witness:
--- 8< ---
~/src/tmp/PR22166 > cat x.c
#include
int main( void)
{
int i = 0x8000;
int j = -1;
printf( "%u: %d\n", sizeof(int), i/j);
return 0;
}
~/src/tmp/PR22166 > mygcc --version
xgcc (GCC) 4.1.0 20050830 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
~/src/tmp/PR22166 > mygcc x.c
~/src/tmp/PR22166 > ./a.out
Floating point exception
~/src/tmp/PR22166 > mygcc -O1 x.c
~/src/tmp/PR22166 > ./a.out
4: -2147483648
~/src/tmp/PR22166 >
--- 8< ---
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22166
[Bug target/16185] ICE: in spill_failure, at reload1.c:1892, global registers and long long
--- Comment #12 from rmathew at gcc dot gnu dot org 2006-02-24 07:51
---
(In reply to comment #5)
> small testcase:
This particular testcase doesn't fail for me anymore on mainline
as of 2006-02-24. However, QEMU 0.8.0 still doesn't build with
this compiler (you'll have to configure with --disable-gcc-check).
FWIW, I get:
--- 8< ---
/home/ranmath/src/gcc/build/gcc/xgcc -B/home/ranmath/src/gcc/build/gcc/ -Wall
-O
2 -g -fno-strict-aliasing -fomit-frame-pointer -mpreferred-stack-boundary=2
-fal
ign-functions=0 -fno-gcse -fno-reorder-blocks -fno-optimize-sibling-calls -I.
-I
/home/ranmath/tmp/qemu-0.8.0/target-i386 -I/home/ranmath/tmp/qemu-0.8.0
-I/home/
ranmath/tmp/qemu-0.8.0/linux-user
-I/home/ranmath/tmp/qemu-0.8.0/linux-user/i386
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-I/home/ranmath/tmp/qe
mu-0.8.0/fpu -DHAS_AUDIO -I/home/ranmath/tmp/qemu-0.8.0/slirp -c -o op.o
/home/r
anmath/tmp/qemu-0.8.0/target-i386/op.c
/home/ranmath/tmp/qemu-0.8.0/target-i386/ops_sse.h: In function
'op_pshufw_mmx':
/home/ranmath/tmp/qemu-0.8.0/target-i386/ops_sse.h:574: error: unable to find a
register to spill in class 'GENERAL_REGS'
/home/ranmath/tmp/qemu-0.8.0/target-i386/ops_sse.h:574: error: this is the
insn:
(insn:HI 17 16 18 2 /home/ranmath/tmp/qemu-0.8.0/target-i386/ops_sse.h:569 (set
(strict_low_part (subreg:HI (reg/v:DI 63 [ r ]) 0))
(mem/s/j:HI (plus:SI (mult:SI (reg:SI 64)
(const_int 2 [0x2]))
(reg/v/f:SI 59 [ s ])) [0 ._w S2 A16])) 40
{*movstrict
hi_1} (insn_list:REG_DEP_TRUE 49 (insn_list:REG_DEP_TRUE 12
(insn_list:REG_DEP_T
RUE 16 (nil
(expr_list:REG_DEAD (reg:SI 64)
(nil)))
/home/ranmath/tmp/qemu-0.8.0/target-i386/ops_sse.h:574: confused by earlier
erro
rs, bailing out
make[1]: *** [op.o] Error 1
make[1]: Leaving directory `/home/ranmath/tmp/qemu-0.8.0/i386-user'
make: *** [all] Error 1
--- 8< -------
I am at SVN revision 111414.
--
rmathew at gcc dot gnu dot org changed:
What|Removed |Added
CC| |rmathew at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16185
[Bug bootstrap/24382] ORIGINAL_LD_FOR_TARGET has bizarre value
--- Comment #6 from rmathew at gcc dot gnu dot org 2006-03-08 11:40 --- (In reply to comment #5) > Confirmed on gcc mailing-list. Reconfirmed with the GCC 4.1.0 release tarballs for C (core) and C++ (g++). In addition to using "--with-ld", one has to also use a relative path to the "configure" script instead of an absolute path for the bootstrap to work. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-03-08 09:29:10 |2006-03-08 11:40:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382
[Bug java/26617] New: A class from an unnamed package is visible to classes in named packages
GCJ allows classes in named packages to see classes in unnamed packages.
For example:
./Snafu.java
public class Snafu { }
--
./foo/Bar.java
package foo;
// import Snafu;
public class Bar
{
Snafu junk;
}
Note that GCJ accepts the code in "foo/Bar.java" with
or without the line commenting out the import declaration.
Both Jikes 1.22 and Sun's JDK 1.5.0_05 reject this
code.
--
Summary: A class from an unnamed package is visible to classes in
named packages
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmathew at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26617
[Bug java/26720] Can't find method 'access$1(I)'
-- rmathew at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-17 15:28:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26720
[Bug target/26879] LibJava not compile under alpha
--- Comment #1 from rmathew at gcc dot gnu dot org 2006-03-28 09:24 --- This looks like a duplicate of 26878 except for the listed patches and the actual error message. Both have been filed by the same person. Claudio: Can you try with a recent snapshot from the mainline SVN repository? See http://gcc.gnu.org/svn.html If you can't access SVN, you can try with a recent weekly snapshot of the mainline (to be released as version 4.2). See: http://gcc.gnu.org/snapshots.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug target/26879] LibJava not compile under alpha
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-03-29 10:06 --- It would be difficult for those of us without alpha-linux boxes to track this problem down. If you're willing, you can try to track the failure to a certain bit yourself. Let's stick with the GCC 4.2 snapshot as that's the latest and is likely to already contain many useful fixes. Looking at your build log, try to reproduce the failure yourself on the command line. That is, copy-paste the command-line compiling "gnuRuntime.java" and run it with your working directory set to the $BUILD_DIR/$TARGET/libjava folder, where $BUILD_DIR is the folder in which you are building GCC and $TARGET is the target you're building for (alpha-alphaslack-linux). Once you're able to reproduce this failure on the command-line, get a recent version of GDB and get the "debugx" and "debug" scripts from: http://gcc.gnu.org/ml/gcc/2004-03/msg01195.html Now run "debugx jc1 ", where "" was the entire command noted earlier that causes the failure. Within GDB, type "run" and when the segmentation fault occurs, type "list" and then "backtrace". This should give some useful information. More information can be found here: http://gcc.gnu.org/wiki/DebuggingGCC Good luck! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug target/26879] LibJava not compile under alpha
--- Comment #7 from rmathew at gcc dot gnu dot org 2006-03-30 13:07 --- (In reply to comment #6) > > Now run "debugx jc1 ", where "" > > was the entire command noted earlier that causes the failure. > Before i reproduce the error, after i make the command : > > debugx jcl > /gcc-929a0346fb3027265ab1a9f2683e27c6/gcc-4.1-20060324/libjava/classpath/gnu/CORBA/CDR/gnuRuntime.java > > > answer : debugx: command not found Put *both* of 'debugx' and 'debug' in a folder in your PATH and make sure they have execute permission. For example, you can put these in your "$HOME/bin" folder and then add this folder to your PATH variable. It is not strictly necessary, but you might also want to define the environment variable "DEBUG" to point to your debugger of choice, normally, gdb. The command-line you have pasted seems incomplete. As I noted earlier, make sure that you have the entire command-line from the build log and that you can reproduce the error on the command-line before trying to run "debugx jc1" on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug bootstrap/22195] Missing Documentation
--- Comment #3 from rmathew at gcc dot gnu dot org 2006-03-31 03:43 --- FWIW, I am getting the same error with GCC 3.4.6 and I *do have* GNU Texinfo 4.8. I have FSF GCC 3.4.5 sources and I downloaded GCC 3.4.6 diffs for "core" and "g++" - the patches applied successfully, but "make bootstrap" terminates with the same error as reported by the filer. I'm on i686-pc-linux-gnu and the starting compiler is FSF GCC 3.4.5. The command for configuration was: /root/inst/gcc-3.4.6/configure --prefix=/usr/local --disable-debug \ --disable-nls --disable-checking --enable-threads=posix \ --enable-languages=c,c++ --enable-__cxa_atexit --with-system-zlib \ --with-gnu-ld --with-gnu-as --with-arch=pentium3 --with-tune=pentium3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22195
[Bug target/26879] LibJava not compile under alpha
--- Comment #11 from rmathew at gcc dot gnu dot org 2006-03-31 04:29 --- Created an attachment (id=11172) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11172&action=view) Shell script to help narrow the problem in PR26879. Save this file in a folder. Save "debugx" and "debug" from: http://gcc.gnu.org/ml/gcc/2004-03/msg01195.html into the *same* folder. Give execute permissions to all of these scripts: chmod +x rep26879.sh debugx debug Now execute "rep26879.sh", assuming you have *not* wiped out the build folder given in the build log: "/gcc-8eea83c766efc28763a9d30e4baba897/gcc.build.lnx" The script leaves you in GDB. On the GDB prompt, enter "run". When the segmentation fault happens, enter "list" and then enter "backtrace". Copy-paste all of the output into this bug report. If this does not work, I'm afraid we'll have to wait for a hacker with an alpha box to help us out. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug bootstrap/22195] Missing Documentation
--- Comment #5 from rmathew at gcc dot gnu dot org 2006-03-31 05:30 --- (In reply to comment #4) > > I was not intending to modify GCC (as the requirements for modifying it do > list > Texinfo). I was intending to compile it. Out of the box compile on my system > failed, and Ranjit's system. Thus a bug, no? (And even if it still isn't > deemed a bug, the fix is a simple one-liner, which I provided.) When you're downloading an SVN snapshot, which is intended for developers, you do not get much of the automatically generated stuff that's available in releases. For SVN snapshots, you must read the "modifying GCC" portion of the pre-requisites documentation. > Perhaps the term "modify" implies "CVS" -- if so, perhaps that could be > emphasized on the prerequisite page? That is, "If you download GCC from the > repository (regardless of whether you want to modify it or not), you must have > the following ..." Agreed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22195
[Bug target/26879] LibJava not compile under alpha
--- Comment #13 from rmathew at gcc dot gnu dot org 2006-04-01 07:57 --- As you can see from the backtrace, the problem is in "gcc/java/jcf-io.c" at line number 394 where we make a call to scandir(). I'm not an alpha-linux hacker, but I see that there's scandir64 and dirent64 and it could be that our assumptions about scandir/dirent in this code are not correct on alpha-linux. Unfortunately, this means that you'll have to wait for someone more familiar with alpha-linux to resolve this bug or try to resolve this problem yourself given the source code. I'm sorry that I cannot help you any further. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-01 07:57:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug classpath/27028] Iterator.hasNext() throws ConcurrentModificationException
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-04-05 07:05 --- (In reply to comment #2) > The difference between Sun's and Classpath's implementation appears to be that > Classpath will check for Concurrent Modification on both hasNext() and next() > calls, while Sun's implementation only checks next() calls. I would argue that Sun's implementation is correct in this case in the sense that hasNext() doesn't actually modify anything, only next() does. I agree that the user code is buggy, gets a potentially bogus answer with hasNext() and is simply asking for trouble, but the said trouble doesn't happen unless it actually calls next(). You cannot throw an exception on me if I merely intend to screw up - do that only if I actually screw up. My 2p. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
[Bug libgcj/21065] javax.swing.event.EventListenerList.getListenerList() implemented wrong
-- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21065
[Bug java/21233] gij -version returns unquoted version number
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-04-26 09:07 --- On mainline, it has been fixed by: http://gcc.gnu.org/ml/java-patches/2005-q2/msg00121.html Ranjit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21233
[Bug java/19870] gcj -C doesn't generate accessors for private members in inner class
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-05-19 22:57 --- I note that GCJ already seems to have the infrastructure in place to do this and possibly used to work properly for this case. For example, see the build_outer_field_access(), outer_field_access_p(), etc. methods in parse.y. The patch to turn this on seems to have been: 2000-02-03 Alexandre Petit-Bianco <[EMAIL PROTECTED]> * java-tree.h (FIELD_THISN): New macro. * jcf-write.c (append_synthetic_attribute): New function. (generate_classfile): Set "Synthetic" attribute on this$, val$ fields, access$ and $finit$ methods. Fixed indentation. * parse.y (add_inner_class_fields): Set FIELD_THISN for created this$ fields. (build_outer_field_access): Turned on access functions usage and generation when compiling to bytecode. (maybe_use_access_method): Likewise. As with other such things in GCJ, this seems to have bitrotted over time. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-05-23 07:45 --- outer_field_access_p(), build_outer_field_access(), etc. are only for non-static fields (instance variables). Even for some simple testcases, I could not get GCJ to emit correct bytecode for non-static instance variables. Lastly these methods are for access from inside a nested class to a private member in a containing class, not the other way round as given in the testcase for this PR. So a significant surgery is indeed needed to make these cases work with GCJ. If anyone is working on a patch to fix this, I would certainly like to hear from them - I have a partially working patch, but I don't know if I'd be able to finish it given the lack of skills as well as time on my part. -- What|Removed |Added CC| |rmathew at gcc dot gnu dot | |org Last reconfirmed|2005-05-12 16:53:53 |2005-05-23 07:45:49 date|| Summary|gcj -C doesn't generate |gcj -C doesn't generate |accessors for private |accessors for private |members in inner class |members across nested class ||boundaries http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rmathew at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug java/9861] method name mangling ignores return type
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-05-26 06:08 --- Some useful tips can be found here: http://gcc.gnu.org/ml/java-patches/2005-q2/msg00558.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9861
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-05-26 07:31 --- I have now submitted a patch for fixing this bug: http://gcc.gnu.org/ml/java-patches/2005-q2/msg00570.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-05-27
05:39 ---
Note that this PR should not be closed as the checked-in patch was
only for generating accessors for static fields. Methods are still
a problem as is demonstrated by this simple testcase:
public class A
{
public static class B
{
private static void snafu( )
{
System.out.println( "Hello!");
}
}
public static void main( String[] args)
{
B.snafu( );
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug java/22060] javax/swing/text/InternationalFormatter.clone() doesn't compile (GNU Classpath)
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-14 11:43 --- Created an attachment (id=9086) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9086&action=view) Simplified testcase. A simplified testcase for the problem. Note that the problem only seems to happen when the base class is an inner class. Note also that if I omit "static" from line #3 in the testcase, the compiler ICEs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22060
[Bug java/22060] javax/swing/text/InternationalFormatter.clone() doesn't compile (GNU Classpath)
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-14 11:44:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22060
[Bug libgcj/22084] Divide_1 test case hangs
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-17 13:13 --- Confirmed, though I see a FAIL instead of a hang. It has only started appearing this week. It fails like: -1459606597 -2147483648 335645025 FAIL: Divide_1 execution - source compiled test instead of the expected: -2147483648 -2147483648 0 0 [...] Note that the values are totally off. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-17 13:13:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084
[Bug libgcj/22084] [4.1 Regression] Divide_1 test case hangs
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-18
05:14 ---
(In reply to comment #2)
> Subject: Re: Divide_1 test case hangs
>
> > -2147483648
> > -2147483648
> > 0
> > 0
> > [...]
> >
> > Note that the values are totally off.
> >
> This looks somewhat familiar. Could you try testing with
> -fno-tree-vrp?
Doesn't help. In a weird twist, I actually get the correct
result if I use any optimisation level (-O{1,2,3})! (That,
BTW, explains why the corresponding -O3 testcase didn't fail.)
When I compile this testcase manually and run it (at -O0),
I get:
1219954614
-2147483648
1174405120
12019755
0
Aborted
Under the debugger:
- 8< -
(gdb) r
Starting program: /home/rmathew/src/tmp/a.out
[Thread debugging using libthread_db enabled]
[New Thread -1225922896 (LWP 28945)]
[New Thread -1226114128 (LWP 28948)]
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1225922896 (LWP 28945)]
0x08048bc4 in Divide_1.probe_1() ([EMAIL PROTECTED]) at Divide_1.java:11
11int c = a/b;
Current language: auto; currently java
(gdb) l
6
7 void probe_1 ()
8 {
9try {
10int a = Integer.parseInt ("-8000", 16);
11int c = a/b;
12System.out.println (c);
13 } catch (Exception _) {
14System.out.println (_);
15 }
(gdb) c
Continuing.
1488390214
-2147483648
Program received signal SIGFPE, Arithmetic exception.
0x08048dd3 in Divide_1.probe_1() ([EMAIL PROTECTED]) at Divide_1.java:27
27int c = a%b;
(gdb) l
22System.out.println (_);
23 }
24
25 try {
26int a = Integer.parseInt ("-8000", 16);
27int c = a%b;
28System.out.println (c);
29 } catch (Exception _) {
30System.out.println (_);
31 }
(gdb) c
Continuing.
1174405120
Program received signal SIGFPE, Arithmetic exception.
0x08048eed in Divide_1.probe_1() ([EMAIL PROTECTED]) at Divide_1.java:35
35int c = a%b1;
(gdb) l
30System.out.println (_);
31 }
32
33 try {
34int a = Integer.parseInt ("-8000", 16);
35int c = a%b1;
36System.out.println (c);
37 } catch (Exception _) {
38System.out.println (_);
39 }
(gdb) c
Continuing.
12019899
0
Program received signal SIGFPE, Arithmetic exception.
0x0804912a in Divide_1.probe_1() ([EMAIL PROTECTED]) at Divide_1.java:52
52int c = a/b;
(gdb) l
47 }
48
49 try {
50int a = Integer.parseInt ("8000", 16);
51int b = Integer.parseInt ("0", 16);
52int c = a/b;
53System.out.println (c);
54 } catch (Exception _) {
55System.out.println (_);
56 }
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
uw_frame_state_for (context=0xbfffe6b8, fs=0xbfffe5f8) at linux-unwind.h:125
125 if (*(unsigned short *)(pc+0) == 0xb858
(gdb) p pc
No symbol "pc" in current context.
(gdb) p context->ra
$1 = (void *) 0x62f
(gdb) p *context
$2 = {reg = {0xb01c, 0xb018, 0xb014, 0xb4b1, 0x0, 0xb008,
0xb004, 0xb000, 0xb4b5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, cfa = 0xb4b9, ra = 0x62f, lsda = 0x0, bases = {tbase = 0x0,
dbase = 0x804bc18, func = 0x8048b86}, args_size = 0}
(gdb) bt
#0 uw_frame_state_for (context=0xbfffe6b8, fs=0xbfffe5f8)
at linux-unwind.h:125
#1 0xb7fe5632 in _Unwind_Backtrace (
trace=0xb765d920 <_Jv_StackTrace::UnwindTraceFn(_Unwind_Context*, void*)>,
trace_argument=0xbfffef30) at unwind.inc:293
#2 0xb765dac0 in _Jv_StackTrace::GetStackTrace ()
at /extra/src/gcc/gcc-20050618/libjava/stacktrace.cc:159
#3 0xb768e29c in java::lang::VMThrowable::fillInStackTrace ()
at /extra/src/gcc/gcc-20050618/libjava/java/lang/natVMThrowable.cc:33
#4 0xb7871a52 in java.lang.Throwable.fillInStackTrace() (this=0x4f858)
at Throwable.java:498
#5 0xb7867532 in java.lang.Throwable.Throwable(java.lang.String) (
this=0x4f858, message=0x62f) at Throwable.java:159
#6 0xb7869f53 in java.lang.Exception.Exception(java.lang.String) (this=0x62f,
s=0x62f) at Exception.java:77
#7 0xb7869fe3 in java.lang.RuntimeException.RuntimeException(java.lang.String)
(this=0x62f, s=0x62f) at RuntimeException.java:75
#8 0xb786c273 in
java.lang.ArithmeticException.ArithmeticException(java.lang.String) (this=0x62f,
s=0x62f) at ArithmeticException.java:74
#9 0xb7650cde in catch_fpe (_dummy=8)
at /extra/src/gcc/gcc-20050618/libjava/prims.cc:166
#10
#11 0x0804912c in Divide_1.probe_1() (this=0x1e0004af) at Divide_1.java:52
---Type to continue, or q to quit---
#12 0x062f in ?? ()
#13 0x1e0004af in ?
[Bug java/22113] New: Buffer overflow in the lexical analyser while reading FP literals
There is a buffer overflow error in GCJ while reading in large FP literals, as shown by Jacks testcase 3.10.2-round-6 (and others). On my machine, this manifests itself only when "parse.y" or "lex.c" is recompiled at -O0 after a full bootstrap, like so: cd $GCC_SRC_DIR/gcc/java touch parse.y cd $BUILD_DIR make BOOT_CFLAGS='-O0 -g3' bubblestrap Compile the attached testcase before and after this. In my case, it gives the expected "Floating point literal too large error" only in the former case. The array "literal_token" in do_java_lex() in lex.c is 256 characters long, but the subsequent code merrily overwrites long literals past this limit. A silly patch to overcome this particular error is: Index: lex.c === --- lex.c 2005-06-18 17:04:00.0 +0530 +++ lex.c 2005-06-18 17:06:14.0 +0530 @@ -965,7 +965,7 @@ do_java_lex (YYSTYPE *java_lval) int parts[TOTAL_PARTS]; HOST_WIDE_INT high, low; /* End borrowed section. */ - char literal_token [256]; + char literal_token [512]; int literal_index = 0, radix = 10, long_suffix = 0, overflow = 0, bytes; int found_hex_digits = 0, found_non_octal_digits = -1; int i; But of course this won't do. We need to have a better fix for this issue. I'm filing this bug so that we don't lose track of this issue. -- Summary: Buffer overflow in the lexical analyser while reading FP literals Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmathew at gcc dot gnu dot org 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=22113
[Bug java/22113] Buffer overflow in the lexical analyser while reading FP literals
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-18 12:11 --- Created an attachment (id=9107) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9107&action=view) Jacks testcase 3.10.2-round-6 that demonstrates this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22113
[Bug AWT/21978] GCC 4.0 Awt and Swing problem
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-19 01:07 --- I think you're trying to configure and compile GCC in the source folder. Unfortunately, this is not yet supported. Try creating a new folder totally outside of the GCC source tree and then run configure and "make bootstrap" in this folder. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21978
[Bug java/19870] gcj -C doesn't generate accessors for private members across nested class boundaries
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-06-19 03:23 --- A patch for the remaining bit is here: http://gcc.gnu.org/ml/java-patches/2005-q2/msg00742.html -- What|Removed |Added URL|http://gcc.gnu.org/ml/java- |http://gcc.gnu.org/ml/java- |patches/2005- |patches/2005- |q2/msg00570.html|q2/msg00742.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19870
[Bug java/19277] allows array.length++ although it is final
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-01-10 11:02 --- Proposed patch here: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00050.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19277
[Bug java/5537] Error compiling simple bytecode with jsr
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-01-10 11:26 --- Now that the BC-ABI work has been merged, the testcase no longer gives an error when compiled with "-findirect-dispatch". However, it ICEs when compiled without! Relevant info: Program received signal SIGSEGV, Segmentation fault. verify_jvm_instructions (jcf=0xb75f5500, byte_ops=0x87adcb4 "¨", length=13) at /home/ranmath/src/gcc/gcc-20050110/gcc/java/verify.c:712 712 if (TREE_CODE (tmp) != TREE_LIST) (gdb) bt #0 verify_jvm_instructions (jcf=0xb75f5500, byte_ops=0x87adcb4 "¨", length=13) at /home/ranmath/src/gcc/gcc-20050110/gcc/java/verify.c:712 #1 0x0807de9d in expand_byte_code (jcf=0xb75f5500, method=0x87a85f8) at /home/ranmath/src/gcc/gcc-20050110/gcc/java/expr.c:2960 #2 0x0808c774 in parse_class_file () at /home/ranmath/src/gcc/gcc-20050110/gcc/java/jcf-parse.c:919 #3 0x0808ec8a in java_parse_file (set_yydebug=0) at /home/ranmath/src/gcc/gcc-20050110/gcc/java/jcf-parse.c:1284 #4 0x082e03a0 in toplev_main (argc=142247416, argv=0xbffface4) at /home/ranmath/src/gcc/gcc-20050110/gcc/toplev.c:996 #5 0x0038579d in __libc_start_main () from /lib/tls/libc.so.6 #6 0x08049b71 in _start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5537
[Bug java/5537] Error compiling simple bytecode with jsr
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-01-10 11:59 --- In that case, we should either make -findirect-dispatch the default or try to fix this bug. Users will otherwise unnecessarily be bitten by such old verifier bugs. I'm willing to try hunting this particular bug down if -findirect-dispatch can't be made the default just yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5537
