[Bug target/105932] Small structures returned incorrectly in i386 Microsoft ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105932 Anthony Green changed: What|Removed |Added CC||green at redhat dot com --- Comment #3 from Anthony Green --- I can confirm this bug. I've been tearing my hair out all day over a series of libffi test case failures on 32-bit x86. Small structures aren't returned properly for the MS ABI.
[Bug libffi/101208] libffi.call/nested_struct12.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101208 Anthony Green changed: What|Removed |Added CC||green at redhat dot com --- Comment #2 from Anthony Green --- It's passing in upstream libffi... https://rl.gl/doc-text?id=RLGL-N0ZQWLP1 ...so check for any fixes that weren't migrated to gcc.
[Bug testsuite/92941] New: Test failure when no C++ compiler built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92941
Bug ID: 92941
Summary: Test failure when no C++ compiler built
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: green at redhat dot com
Target Milestone: ---
If you run the testsuite on a C-only build of the toolchain, you'll
get a FAIL for this test:
compiler driver -Q --help=warnings option(s): "-Wabsolute-value[
\t]+\[available in C, ObjC\]" present in output
It comes from here...
check_for_options c++ "-Q --help=warnings" {
-Wabsolute-value[ \t]+\[available in C, ObjC\]
} "" ""
But the testsuite should ignore c++ related tests if we haven't configured and
built g++.
[Bug middle-end/92930] New: GCC incorrectly optimizes away __builtin_apply() calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92930
Bug ID: 92930
Summary: GCC incorrectly optimizes away __builtin_apply() calls
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: green at redhat dot com
Target Milestone: ---
Compile the following with -O2 and it optimizes away the call to bar()/foo().
This is incorrect, as foo() may have side-effects.
void foo(int a, int b, int c, int d, int e, int f, int g);
static void bar(int a, ...)
{
__builtin_apply(foo, __builtin_apply_args(), 20);
}
int main(void)
{
bar(1024, 1025, 1026, 1027, 1028, 1029, 1030);
return 0;
}
[Bug target/92694] New: Can't build powerpc-eabi cross compiler: : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92694 Bug ID: 92694 Summary: Can't build powerpc-eabi cross compiler: : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: green at redhat dot com Target Milestone: --- I'm trying to build a powerpc-eabi cross compiler from git sources, and am getting the following: /home/green/BUG/build-gcc1/./gcc/xgcc -B/home/green/BUG/build-gcc1/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/home/green/git/gcc/gcc/testsuite/selftests : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’ compilation terminated. : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’ compilation terminated. make[2]: *** [/home/green/git/gcc/gcc/c/Make-lang.in:124: s-selftest-c] Error 1
[Bug target/85667] (x86_64) ms_abi rules aren't followed when returning short structs with float values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85667 Anthony Green changed: What|Removed |Added Target||x86_64-pc-linux-gnu Priority|P3 |P2
[Bug target/85667] New: (x86_64) ms_abi rules aren't followed when returning short structs with float values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85667
Bug ID: 85667
Summary: (x86_64) ms_abi rules aren't followed when returning
short structs with float values
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: green at redhat dot com
Target Milestone: ---
Structs 8 bytes or shorter with floating point values should return in eax.
GCC 8.0.1 (at least) doesn't follow those rules. It is using the sysv ABI
rules instead.
See this code, for example:
typedef struct
{
float x;
} Float;
Float __attribute__((ms_abi)) fn1()
{
Float v;
v.x = 3.145;
return v;
}
Float fn2 ()
{
Float v;
v.x = 3.145;
return v;
}
GCC's output for fn1 and fn2 are similar:
fn1:
movss .LC0(%rip), %xmm0
ret
fn2:
movss .LC0(%rip), %xmm0
ret
Clang does this correctly, however, and fn1 looks like this:
fn1:
movl$1078544302, %eax
retq
fn2:
movss .LCPI1_0(%rip), %xmm0
retq
[Bug libffi/34311] libffi.call/nested_struct5.c execution tests fail under darwin9 on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34311 --- Comment #3 from Anthony Green --- (In reply to Iain Sandoe from comment #2) > However, there is no guarantee in the Darwin m32 ABI that the stacked > version of the structs will be appropriately aligned. So, either the > testcase is wrong code - or the process for passing structures in the > closure needs to be refined (significant re-write, since the structs are > currently passed in-place). Iain - could you please explain this a little more? Which are the stacked structs that aren't aligned, and where do they come from? Thanks! AG
[Bug libffi/50051] MIPS libffi does not compile for mips64octeon-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50051 --- Comment #5 from Anthony Green 2011-12-07 21:48:29 UTC --- (In reply to comment #4) > (In reply to comment #3) > > Thanks Andrew. Does this force the generation of FP instructions, which are > > then emulated through OS traps? > > Yes and the traps are always enabled in newish kernels. I'm OK with this change. Andrew - could you please commit it to GCC and I'll pull it into the libffi sidestream project? Thanks! AG
[Bug libffi/50051] MIPS libffi does not compile for mips64octeon-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50051 Anthony Green changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-07 CC||green at redhat dot com Ever Confirmed|0 |1 --- Comment #3 from Anthony Green 2011-12-07 11:00:05 UTC --- (In reply to comment #2) > Simple fix which works for me: > Index: src/mips/n32.S > === > --- src/mips/n32.S(revision 177681) > +++ src/mips/n32.S(working copy) > @@ -43,6 +43,7 @@ > #ifdef __GNUC__ > .abicalls > #endif > +.set mips4 > .text > .align2 > .globlffi_call_N32 Thanks Andrew. Does this force the generation of FP instructions, which are then emulated through OS traps? AG
[Bug libgomp/46592] New: -ftree-parallelize-loops attempts to link pthreads on non-posix systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46592 Summary: -ftree-parallelize-loops attempts to link pthreads on non-posix systems Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: gr...@redhat.com *-elf toolchains are failing the -ftree-parallelize-loops test pr46111 because using that option unconditionally attempts to link pthreads. I suppose I could define GOMP_SELF_SPECS to "" for my target, but why isn't pthreads only linked in with libgomp is linked?
[Bug libffi/35484] libffi doesn't support AIX 64bit
--- Comment #2 from green at redhat dot com 2008-03-06 19:40 --- Thanks for this patch. If you haven't already done so, please submit it to [EMAIL PROTECTED] Be sure to include proper ChangeLog entries. Thanks! AG -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
[Bug libffi/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches
--- Comment #7 from green at redhat dot com 2007-08-10 09:18 --- I believe the patch for this was checked in a long time ago. -- green at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782
[Bug java/15474] libgcj jar file should always be in classpath at runtime
--- Comment #9 from green at redhat dot com 2006-07-14 18:35 --- I ran into another instance of needing this in the jakarta-commons-io testsuite. It's been two years since the performance arguement against this change was made. A lot of code has changed since then. Is it still a valid argument (vs correct and expected behaviour)? -- green at redhat dot com changed: What|Removed |Added CC||green at redhat dot com Last reconfirmed|2005-02-23 01:37:18 |2006-07-14 18:35:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15474
[Bug tree-optimization/19505] [4.0/4.1/4.2 Regression] java bytecode to native ICE in remove_unreachable_regions
--- Comment #22 from green at redhat dot com 2006-07-08 20:26 --- For the azureus test case, grab: http://people.redhat.com/~green/FE/devel/azureus-2.4.0.3-0.20060702cvs_2.src.rpm Edit the spec file to remove RPM_OPT_FLAGS="-O0" from this line: RPM_OPT_FLAGS="-O0" aot-compile-rpm This SRPM only builds in FC rawhide with the following packages or newer installed: http://people.redhat.com/fitzsim/bouncycastle-1.33-1.src.rpm http://people.redhat.com/fitzsim/java-1.4.2-gcj-compat-1.4.2.0-40jpp_88rh.src.rpm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug tree-optimization/19505] [4.0/4.1/4.2 Regression] java bytecode to native ICE in remove_unreachable_regions
--- Comment #21 from green at redhat dot com 2006-07-08 19:24 --- I've hit this bug while rebuilding azureus for FC6 (bytecode produced by ecj). I hope we can get a fix in the FC6 gcc 4.1.1 fork. I'll try compiling without optimization for now. -- green at redhat dot com changed: What|Removed |Added CC| |green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug libgcj/27271] i/o error (java.util.zip.ZipException: Deflated stream ends early.)
--- Comment #3 from green at redhat dot com 2006-06-02 16:09 --- This bug may also be what's causing rssowl to suddenly fail in FC5. Both Eclipse (swt) and gcc were updated in FC5 recently, and one of those triggered the failure. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193880 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27271
[Bug libgcj/27170] Deadlock in garbage collector
--- Comment #5 from green at redhat dot com 2006-04-17 14:44 --- I've uploaded a patch that I've applied to the FC5 gcc RPM. I can't reproduce the problem with this patch. -- green at redhat dot com changed: What|Removed |Added CC| |green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug libgcj/27170] Deadlock in garbage collector
--- Comment #4 from green at redhat dot com 2006-04-17 14:43 --- Created an attachment (id=11283) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11283&action=view) Sample patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug libgcj/27170] Deadlock in garbage collector
--- Comment #3 from green at redhat dot com 2006-04-14 21:01 --- (In reply to comment #2) > Based on the thread 13 stack trace, it looks to me like we're calling dlopen > directly, when we should somehow be arranging to call GC_dlopen. GC_dlopen is > included in the GC to avoid this sort of deadlock. Thanks Hans. I'll try making this change to see what happens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug libgcj/27171] New: UTF8 PrintWriter goes haywire
Feeding specific binary data to a UTF8 PrintWriter causes it to go haywire and write out a steady stream of nonsense (0, I think). The was tracked down in Azureus by Jon Burgess. He created a simple test case to reproduce the problem. The test case is attached to this Fedora bug... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187698 -- Summary: UTF8 PrintWriter goes haywire Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27171
[Bug libgcj/27170] Deadlock in garbage collector
--- Comment #1 from green at redhat dot com 2006-04-14 18:58 --- Created an attachment (id=11273) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11273&action=view) stack traces from gdb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug libgcj/27170] New: Deadlock in garbage collector
I believe I've identified a deadlock that is periodically reproducible
with Eclipse running on FC5. I'll attach the stack trace to this bug
report. See threads 4 and 13.
1. Thread 4 aquires the GC lock and starts a GC
2. Thread 13 dlopens a .so, acquiring a glibc maintained lock
3. Thread 13 tries to acquire the GC lock while registering classes
4. Thread 4 tries to acquire the glibc lock in dl_iterate_phdr
...and we're deadlocked.
--
Summary: Deadlock in garbage collector
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
[Bug libgcj/23682] gnu.java.nio.SelectorImpl.select(long) throws ArrayIndexOutOfBoundsException
--- Comment #3 from green at redhat dot com 2006-04-03 13:02 ---
Azureus users on FC5 see this as well (gcj 4.1.0). Here's a slightly
different stack trace.
[12:31:21.648] {stderr} DEBUG::Mon Apr 03 12:31:21 GMT
2006::com.aelitis.azureus.core.networkmanager.VirtualChannelSelector::select::-1:
[12:31:21.649] {stderr} Caught exception on selector.select() op: 3
[12:31:21.650] {stderr}
ReadController::readSelectorLoop::-1,ReadController::access$0::-1,ReadController$1::runSupport::-1,AEThread::run::-1
[12:31:21.718] {stderr} java.lang.ArrayIndexOutOfBoundsException: 3
[12:31:21.719] {stderr}at gnu.java.nio.SelectorImpl.getFDsAsArray
(libgcj.so.7)
[12:31:21.720] {stderr}at gnu.java.nio.SelectorImpl.select (libgcj.so.7)
[12:31:21.720] {stderr}at
com.aelitis.azureus.core.networkmanager.impl.VirtualChannelSelectorImpl.select
(Azureus2.jar.so)
[12:31:21.721] {stderr}at
com.aelitis.azureus.core.networkmanager.VirtualChannelSelector.select
(Azureus2.jar.so)
[12:31:21.721] {stderr}at
com.aelitis.azureus.core.networkmanager.impl.ReadController.readSelectorLoop
(Azureus2.jar.so)
[12:31:21.722] {stderr}at
com.aelitis.azureus.core.networkmanager.impl.ReadController.access$0
(Azureus2.jar.so)
[12:31:21.722] {stderr}at
com.aelitis.azureus.core.networkmanager.impl.ReadController$1.runSupport
(Azureus2.jar.so)
[12:31:21.723] {stderr}at org.gudy.azureus2.core3.util.AEThread.run
(Azureus2.jar.so)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23682
[Bug libgcj/26506] Native build of Azureus 2.4.0.0 throws ArrayIndexOutOfBounds running under gcj 4.1.0
--- Comment #2 from green at redhat dot com 2006-03-01 08:08 --- (In reply to comment #1) > Anthony (added to CC) has been packaging Azureus for FC-Extras. He might > recognize this failure. Yes, I do. I think this is a bug in GNU Classpath's NIO code. I haven't done anything about it yet, since I think the relevant chunks need major surgery. However, my azureus build on FC seems to run OK despite this problem. AG -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26506
[Bug libgcj/26202] New: Regex bug "++"
$ cat ar.java
import java.util.regex.*;
public class ar
{
public static void main (String args[])
{
Pattern p = Pattern.compile ("[0-9.]++\\%");
}
}
$ gcj -C ar.java
$ gij ar
$ gij ar
Exception in thread "main" java.util.regex.PatternSyntaxException: At position
8 in regular expression pattern:
attempted to repeat a token that is already repeated
[0-9.]++\%
^
at java.util.regex.Pattern.Pattern(java.lang.String, int)
(/usr/lib/libgcj.so.6.0.0)
at java.util.regex.Pattern.compile(java.lang.String, int)
(/usr/lib/libgcj.so.6.0.0)
at java.util.regex.Pattern.compile(java.lang.String)
(/usr/lib/libgcj.so.6.0.0)
at ar.main(java.lang.String[]) (Unknown Source)
at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
--
Summary: Regex bug "++"
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26202
[Bug libgcj/26177] Exception when compiling valid regex pattern
--- Comment #3 from green at redhat dot com 2006-02-08 17:32 --- It's good to know this is fixed in GNU Classpath, but I filed this against libgcj for a reason. Reopening the bug. -- green at redhat dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|classpath |libgcj Product|classpath |gcc Resolution|FIXED | Target Milestone|0.21|--- Version|unspecified |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26177
[Bug libgcj/26177] New: Exception when compiling valid regex pattern
The azureus developers identified a regex failure that is causing trouble...
$ cat /tmp/ar.java
import java.util.regex.*;
public class ar
{
public static void main (String args[])
{
Pattern p = Pattern.compile ("(?i)yoda");
}
}
$ gcj -C ar.java
$ gij ar
Exception in thread "main" java.util.regex.PatternSyntaxException: At position
1 in regular expression pattern:
quantifier (?*+{}) without preceding token
(?i)yoda
^
at java.util.regex.Pattern.Pattern(java.lang.String, int)
(/usr/lib/libgcj.so.6.0.0)
at java.util.regex.Pattern.compile(java.lang.String, int)
(/usr/lib/libgcj.so.6.0.0)
at java.util.regex.Pattern.compile(java.lang.String)
(/usr/lib/libgcj.so.6.0.0)
at ar.main(java.lang.String[]) (Unknown Source)
at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
(Yes, I ran this again 4.0, but the same thing happens in 4.1).
--
Summary: Exception when compiling valid regex pattern
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26177
[Bug java/26007] New: initialized final static data should go in .rodata, not .data
For the following code...
public class b
{
public static final int FOOBAR = 555;
}
..I would expect to see FOOBAR in .rodata. However gcj currently places this
in .data.
If you poke through the .jar.so files we have in Fedora Core you'll see big
chunks of .data that should actually .rodata.
--
Summary: initialized final static data should go in .rodata, not
.data
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26007
[Bug libgcj/25398] .jar files held open twice at runtime
--- Comment #1 from green at redhat dot com 2006-01-17 03:59 --- I discovered why we open all jar files twice. It happens in gnu/java/net/protocol/jar/Connection.java. While searching jar files, we call gnu.java.net.protocol.jar.Connection.getJarFile(). The first thing this does is call gnu.java.net.protocol.jar.Connection.connect(). This, in turn, calls jarFileURLConnection.connect(). jarFileURLConnection is a gnu.java.net.protocol.file.Connection (if we have a file URL). This opens the file. Then gnu.java.net.protocol.jar.Connection.getJarFile() continues. This special-cases local files, and we end up calling new JarFile([filename]). This opens the jar file for the second time. And that's how we end up with two open file descriptors for every jar file we process. We should probably figure out a way to avoid doing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25398
[Bug libgcj/25655] New: Implement signal chaining
We should implement something like Sun's signal chaining library for use with libgcj. This may be required when working with native libraries installing their own signal handlers... http://java.sun.com/j2se/1.4.2/docs/guide/vm/signal-chaining.html -- Summary: Implement signal chaining Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25655
[Bug libgcj/25398] New: .jar files held open twice at runtime
When I examine gij processes running gcj-dbtool managed code on Linux with lsof, I see that we have two active file descriptors for every jar file. And strace confirms that we open each jar file twice (and keep them open). I don't know why this is happening, but it seems wrong. -- Summary: .jar files held open twice at runtime Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25398
[Bug libgcj/25250] New: Turn off lib-foo-bar class loading mechanism by default
The gcj-dbtool managed class loading mechanism for native code has mostly replaced the old lib-foo-bar "magic name" mechanism. The magic name mechanism has a serious performance impact on application startup (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174929) , so we should turn it off. Apparently we still use it to load the AWT peer code. We should find some other way to load the peers so we can disable the magic name mechanism by default. -- Summary: Turn off lib-foo-bar class loading mechanism by default Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25250
[Bug c/20318] RFE: add attribute to specify that a function never returns NULL
--- Comment #7 from green at redhat dot com 2005-11-11 23:29 --- This feature would also be useful for java, as we can eliminate certain inlined null pointer checks when we know that a method can't return null. See http://gcc.gnu.org/ml/java/2005-11/msg00124.html -- green at redhat dot com changed: What|Removed |Added CC||green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #15 from green at redhat dot com 2005-11-08 12:54 --- (In reply to comment #14) > > Then you'll realize that you don't need to bother setting up > > the ffi_cif - all you need is the exception argument. > I doubt that this is right. The ffi_prep_closure() needs to know which > arguments are given to it. Ah - you're right, of course. But in this case it seems like we can simply define it as zero argument function, returning void. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #12 from green at redhat dot com 2005-11-07 15:06 --- (In reply to comment #11) > You're not describing this clearly. :-) > > We need to point the execution vector at a piece of code that throws an > exception with the appropriate args. Now, how should we do that? The closure mechanism was specifically designed for when you want to call interpreted code. We don't want to do this here; we just want to throw an exception with the right argument (stored in the closure object). The current patch uses the closure mechanism to call the trampoline, which in turn uses the ffi_call mechanism to call the exception throwing function. But we don't need to use ffi_call here, we can just call the exception throwing function directly. Then you'll realize that these functions don't need to be separate at all. Then you'll realize that you don't need to bother setting up the ffi_cif - all you need is the exception argument. Does this help explain? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #10 from green at redhat dot com 2005-11-07 14:47 --- This patch seems overly complicated to me. I don't think we need the trampoline function and the ffi_call. Since we're just planning on throwing an exception, it seems like you should just be able to pass the class name in as a closure argument (cast as a ffi_cif?) and throw the exception directly, dispensing entirely with the ffi_cif and all the other interpreter->native call support. Let me know if I'm not describing this clearly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug libffi/12782] ffi.h #defines ffi_type_[us]long wrong on 32bit arches
--- Comment #6 from green at redhat dot com 2005-11-06 18:41 --- Created an attachment (id=10159) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10159&action=view) A patch I think the attached patch will fix. -- green at redhat dot com changed: What|Removed |Added Attachment #5005 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12782
[Bug libffi/21229] LibFFI can't handle Longs
--- Comment #7 from green at redhat dot com 2005-11-06 17:51 --- I'm unable to reproduce this with GCC 4.0.1 (x86 Linux). Could you please try a more recent compiler? If you are able to reproduce, could you please submit your example in the form of a test case for the libffi testsuite? -- green at redhat dot com changed: What|Removed |Added CC||green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21229
[Bug classpath/20198] java.security.CodeSource.getLocation output is different than expected
--- Additional Comments From green at redhat dot com 2005-09-16 23:10
---
(In reply to comment #1)
> Created an attachment (id=9352)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9352&action=view)
> Proposed patch
>
> This patch makes your test program emit an absolute path.
>
> I'm not sure it's 100% correct. For instance, perhaps we should canonicalize
> the path in addition to makeing it absolute. Also, perhaps this should happen
> in URLClassLoader instead of the system loader. Hopefully a discussion will
> happen on this thread:
>
> http://gcc.gnu.org/ml/java-patches/2005-q3/msg00144.html
>
I just checked in a patch for a related fix. The test case look like this:
public class bug
{
public static void main (String args[]) throws Exception
{
String urlString =
bug.class.getClassLoader().getResource("bug.class").toExternalForm ();
System.out.println (urlString);
}
}
Before patch:
$ gij bug
file:./bug.class
After patch:
$ gij bug
file:/home/green/FSF/HEAD/bug.class
Unfortunately it doesn't fix this bug (although the original patch attached to
this bug _does_).
I'll figure out what else is needed for this bug.
AG
--
What|Removed |Added
----------------
AssignedTo|unassigned at gcc dot gnu |green at redhat dot com
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2005-07-26 22:10:59 |2005-09-16 23:10:50
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20198
[Bug libgcj/23182] instanceof sometimes fails if compiled with -findirect-dispatch
--- Additional Comments From green at redhat dot com 2005-09-09 00:34 --- (In reply to comment #7) > I found the cause of this bug. A line of code was incorrectly removed from > pop_type_0() when the new verifier was added, a fairly long time ago. This > patch should fix it. I ported this patch to the latest FC rawhide gcc RPM and rebuilt. I'm happy to report that it solved another instance of this bug that I discovered today in kawa-1.8beta. Thanks Andrew! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23182
[Bug java/23549] New: gij swallows args after -ea
gij.cc says:
else if (! strcmp (arg, "-enableassertions") || ! strcmp (arg, "-ea"))
{
if (i >= argc - 1)
goto no_arg;
// FIXME: hook up assertion support
++i;
continue;
}
I think the ++i shouldn't be there.
since -ea doesn't take an arg, does it?
Try, for instance, "gij -ea -classpath Bar.jar Foo"
the -ea processing is swallowing the -classpath arg and gij
complains about not being able to load the class Bar.jar.
--
Summary: gij swallows args after -ea
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23549
[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info
--- Additional Comments From green at redhat dot com 2005-08-08 15:14 --- (In reply to comment #9) > Anthony, do you think this bug should be fixed? Yes, I think so. > What is the status of your gdb > patch? It hasn't been applied. I never followed up on the comments from the gdb maintainers. I can do that if it looks like gcj or jvgenmain will be fixed. AG -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1427
[Bug libgcj/20198] java.security.CodeSource.getLocation output is different than expected
--- Additional Comments From green at redhat dot com 2005-07-24 19:49 --- Created an attachment (id=9352) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9352&action=view) Proposed patch This patch makes your test program emit an absolute path. I'm not sure it's 100% correct. For instance, perhaps we should canonicalize the path in addition to makeing it absolute. Also, perhaps this should happen in URLClassLoader instead of the system loader. Hopefully a discussion will happen on this thread: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00144.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20198
[Bug libgcj/21747] New: JAWT_X11DrawingSurfaceInfo missing depth field
The native code in the lwjgl distribution refers to an int "depth" field in
JAWT_X11DrawingSurfaceInfo. We don't have that in our version.
This code won't build without it.
--
Summary: JAWT_X11DrawingSurfaceInfo missing depth field
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21747
[Bug libgcj/21741] New: Need configure option to set java.library.path
We need a configure option to set java.library.path.
Right now libgcjawt.so in installed in ${prefix}/lib.
In FC4 we use java-gcj-compat to create a libjawt.so symlink in
/usr/lib/jvm/jre/lib/i386 (via alternatives).Programs running
System.loadLibrary("jawt") should find this without users having to set
LD_LIBRARY_PATH or -Djava.library.path. One answer is to let packagers set the
default java.library.path at configure time.
--
Summary: Need configure option to set java.library.path
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741
[Bug java/21540] switch stmt problem
--- Additional Comments From green at redhat dot com 2005-05-12 20:03 --- Created an attachment (id=8880) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8880&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug java/21540] New: switch stmt problem
Compiling the attached results in:
[EMAIL PROTECTED] tmp]$ gcj -C bug.java
bug.java: In class 'bug':
bug.java: In method 'bug.fn(int)':
bug.java:9: error: Constant expression required.
case ((int) xxx >>> 32):
^
1 error
--
Summary: switch stmt problem
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug bootstrap/21403] Canadian cross build fails.
--- Additional Comments From green at redhat dot com 2005-05-07 22:33 --- Patch applied to HEAD and 4.0 branch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21403
[Bug bootstrap/21403] Canadian cross build fails.
--- Additional Comments From green at redhat dot com 2005-05-07 03:52 --- I've posted a patch. http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00555.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |green at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21403
[Bug libgcj/21058] [4.1 Regression] libgcj can't find class
--- Additional Comments From green at redhat dot com 2005-05-06 03:21 --- *** Bug 20693 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21058
[Bug libgcj/20693] [4.1 Regression] javax-imageio.lo failed to build
--- Additional Comments From green at redhat dot com 2005-05-06 03:21 --- *** This bug has been marked as a duplicate of 21058 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20693
[Bug bootstrap/21403] New: Canadian cross build fails.
A canadian cross of the compiler failed as it tried to link fix-header.
It's using a mix of build and host object files to build this. The Makefile
reads:
# This is nominally a 'build' program, but it's run only when host==build,
# so we can (indeed, must) use $(LIBDEPS) and $(LIBS).
I, however, don't have host==build, and it still tries to do this.
>From what I can tell, there doesn't appear to be proper host==build checks in
place. Simply setting use_fixproto in config.gcc is enough to try to build
fix-header.
--
Summary: Canadian cross build fails.
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i386-mingw32
GCC target triplet: i386-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21403
[Bug libgcj/21058] libgcj can't find class
--- Additional Comments From green at redhat dot com 2005-04-26 20:47 --- (In reply to comment #1) > Wasn't this fixed on the 4.0 branch by sorting the files > passed to the BC compilations? Yes, that's right. > If so, on the trunk we should probably instead look at the libtool fix. Yes, that's what we discussed before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21058
[Bug libffi/21229] LibFFI can't handle Longs
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |green at redhat dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21229
[Bug bootstrap/21216] Spontaneous cc1 rebuild during parallel make causes build failure.
--- Additional Comments From green at redhat dot com 2005-04-25 14:06 --- Created an attachment (id=8736) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8736&action=view) Relevant part of build log. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21216
[Bug bootstrap/21216] New: Spontaneous cc1 rebuild during parallel make causes build failure.
I've built a half-dozen GCC 4.0.0 based compilers in parallel (make -j2) on
Linux without a hitch. But I received the following error building an sh-elf
toolchain. make is deciding to rebuild cc1 after cross building much of libgcc
already, and then, when it tries to use this new cc1 (perhaps before it is fully
written?)...
/usr/src/redhat/BUILD/gcc-4.0.0/obj-sh-elf/gcc/xgcc
-B/usr/src/redhat/BUILD/gcc-4.0.0/obj-sh-elf/gcc/ -nostdinc
-B/usr/src/redhat/BUILD/gcc-4.0.0/obj-sh-elf/sh-elf/newlib/ -isystem
/usr/src/redhat/BUILD/gcc-4.0.0/obj-sh-elf/sh-elf/newlib/targ-include -isystem
/usr/src/redhat/BUILD/gcc-4.0.0/newlib/libc/include -B/usr/sh-elf/bin/
-B/usr/sh-elf/lib/ -isystem /usr/sh-elf/include -isystem /usr/sh-elf/sys-include
-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -g
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc
-I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -DL_ashrdi3
-c ../../gcc/libgcc2.c -o libgcc/./_ashrdi3.o
gcc -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DIN_GCC
-DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition-DHAVE_CONFIG_H -o cc1 \
c-parse.o c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o
c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o
c-objc-common.o c-dump.o c-pch.o c-gimplify.o tree-mudflap.o c-pretty-print.o
main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a
../libiberty/libiberty.a
/usr/src/redhat/BUILD/gcc-4.0.0/obj-sh-elf/gcc/xgcc
-B/usr/src/redhat/BUILD/gcc-4.0.0/obj-sh-elf/gcc/ -nostdinc
-B/usr/src/redhat/BUILD/gcc-4.0.0/obj-sh-elf/sh-elf/newlib/ -isystem
/usr/src/redhat/BUILD/gcc-4.0.0/obj-sh-elf/sh-elf/newlib/targ-include -isystem
/usr/src/redhat/BUILD/gcc-4.0.0/newlib/libc/include -B/usr/sh-elf/bin/
-B/usr/sh-elf/lib/ -isystem /usr/sh-elf/include -isystem /usr/sh-elf/sys-include
-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -g
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc
-I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -DL_cmpdi2
-c ../../gcc/libgcc2.c -o libgcc/./_cmpdi2.o
xgcc: installation problem, cannot exec 'cc1': No such file or directory
make[2]: *** [libgcc/./_cmpdi2.o] Error 1
Rerunning make gets it going again.
I'll attach more of the relevant log file to this issue.
--
Summary: Spontaneous cc1 rebuild during parallel make causes
build failure.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21216
[Bug c/21201] New: ICE: in reload_cse_simplify_operands, at postreload.c:391
I get the following ICE when building newlib with an m68hc11-elf cross compiler.
/usr/src/redhat/BUILD/gcc-4.0.0/obj-m68hc11-elf/gcc/xgcc
-B/usr/src/redhat/BUILD/gcc-4.0.0/obj-m68hc11-elf/gcc/ -nostdinc
-B/usr/src/redh\at/BUILD/gcc-4.0.0/obj-m68hc11-elf/m68hc11-elf/mshort/newlib/
-isystem
/usr/src/redhat/BUILD/gcc-4.0.0/obj-m68hc11-elf/m68hc11-elf/mshort/newlib/targ-include
-isystem /usr/src/redhat/BUILD/gcc-4.0.0/newlib/libc/include
-B/usr/m68hc11-elf/bin/ -B/usr/m68hc11-elf/lib/ -isystem
/usr/m68hc11-elf/include -isystem /usr/m68hc11-elf/sys-include -mshort
-DPACKAGE=\"newlib\" -DVERSION=\"1.13.0\" -I.
-I../../../../..\/../newlib/libc/stdio -DPREFER_SIZE_OVER_SPEED -Os -mrelax
-DNO_EXEC -DABORT_PROVIDED -DSMALL_MEMORY -DMISSING_SYSCALL_NAMES -fno-builtin
-O2 -g -O2 -mshort -c ../../../../../../newlib/libc/stdio/vfscanf.c
../../../../../../newlib/libc/stdio/vfprintf.c: In function '_vfprintf_r':
../../../../../../newlib/libc/stdio/vfprintf.c:1221: error: insn does not
satisfy its constraints:
(insn 4215 146 4213 14 ../../../../../../newlib/libc/stdio/vfprintf.c:555
(parallel [
(set (reg:DF 14 *_.d1)
(mem/s/u:DF (symbol_ref:HI ("C.1.2987") ) [74 C.1+0 S8 A8]))
(clobber (scratch:HI))
]) 18 {movdf_internal} (nil)
(nil))
../../../../../../newlib/libc/stdio/vfprintf.c:1221: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE: in reload_cse_simplify_operands, at
postreload.c:391
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68hc11-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21201
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From green at redhat dot com 2005-04-20 05:06 --- I think I see the problem here. The call in Test.java... t.test(false, "FALSE"); ...gets compiled into: mov%eax,0x8(%esp) ; movb $0x0,0x4(%esp) ; false boolean value mov%edx,(%esp); call *%ecx Notice that we're only storing a byte into the word here at 0x4(%esp). The "raw" libffi interface assumes that the call stack from the native code is exactly what we'd see on the bytecode stack. This obviously isn't the case, since, IIRC, booleans are represented as full words on the stack. And, indeed, when we get the value of the boolean argument we're doing a LOADI from memory copied from the 0x4(%esp). Three quarters of that word are complete garbage, so the value of our LOADI is unknown (and, for those of us seeing failures, non-zero). Possible fixes include: - promoting booleans to words for function calls - "fixing up" boolean args for raw calls - don't use the raw call mechanis I like the first option, but will it cause problems with CNI code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true
--- Additional Comments From green at redhat dot com 2005-04-20 00:50 --- valgrind indicates that this uninitialized memory read is cause the bad behaviour: green ==12019== Conditional jump or move depends on uninitialised value(s) green ==12019==at 0x1BEEB99C: _Jv_InterpMethod::run(void*, ffi_raw*) (interpret.cc:2113) green ==12019==by 0x1BEEFF5A: _Jv_InterpMethod::run_normal(ffi_cif*, void*, ffi_raw*, void*) (interpret.cc:277) green ==12019==by 0x1C2F51B9: ffi_closure_raw_SYSV (ffi.c:416) green ==12019==by 0x80489EE: Test::main(JArray*) (in /home/green/pr21115/a.out) interpet.cc:2113 is the ifeq opcode. So it seems that either libffi is buggy, or we're using it incorrectly. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |green at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-20 00:50:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21115
[Bug libgcj/20693] javax-imageio.lo failed to build
--- Additional Comments From green at redhat dot com 2005-04-17 00:42 --- I'm seeing this same problem. GCC4 won't build reliably without this fix. -- What|Removed |Added CC| |green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20693
[Bug libgcj/21058] New: libgcj can't find class
Given the following test program:
cut here ---
import java.awt.*;
import javax.imageio.*;
public class ShowJPEGReader
{
public static void main (String args[])
{
System.out.println (Toolkit.getDefaultToolkit ());
System.out.println (ImageIO.getImageReadersByFormatName("JPEG").next());
}
}
cut here ---
Running it results in:
$ gij ShowJPEGReader
[EMAIL PROTECTED]
Exception in thread "main" java.lang.NoClassDefFoundError: while resolving
class: javax.imageio.ImageIO
at java.lang.VMClassLoader.transformException(java.lang.Class,
java.lang.Throwable) (/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at java.lang.Class.initializeClass()
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at ShowJPEGReader.main(java.lang.String[]) (Unknown Source)
at gnu.java.lang.MainThread.call_main()
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
Caused by: java.lang.ClassNotFoundException:
javax.imageio.ImageIO$ReaderMIMETypeFilter not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(java.lang.String)
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String, boolean)
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String)
(/home/green/FSF/4.0/i/lib/libgcj.so.6.0.0)
...5 more
But javax.imageio.ImageIO$ReaderMIMETypeFilter is here:
$ nm -D ~/FSF/i/lib/libgcj.so.6.0.0 | c++filt | grep ReaderMIMETypeFilter
00deb9e0 D javax::imageio::ImageIO$ReaderMIMETypeFilter::class$
008fcc50 T
javax::imageio::ImageIO$ReaderMIMETypeFilter::filter(java::lang::Object*)
008fcc10 T
javax::imageio::ImageIO$ReaderMIMETypeFilter::ImageIO$ReaderMIMETypeFilter(java::lang::String*)
00deba80 D vtable for javax::imageio::ImageIO$ReaderMIMETypeFilter
--
Summary: libgcj can't find class
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: aph at redhat dot com,gcc-bugs at gcc dot gnu dot
org,java-prs at gcc dot gnu dot org,tromey at redhat dot
com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21058
[Bug c++/20831] ICE: SEGV with -fmudflap
--- Additional Comments From green at redhat dot com 2005-04-08 13:46 --- Created an attachment (id=8565) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8565&action=view) Preprocessed source for test case (trimmed down) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20831
[Bug c++/20831] New: ICE: SEGV with -fmudflap
$ g++ -O2 -fmudflap -c link.ii ../../../gcc/libjava/link.cc: In static member function static void _Jv_Linker::make_vtable(java::lang::Class*): ../../../gcc/libjava/link.cc:63: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/ccbQ1GYh.out file, please attach this to your bugreport. I will attach the offending .ii file. -- Summary: ICE: SEGV with -fmudflap Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com CC: fche at redhat dot com,gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20831
[Bug libgcj/20782] jawt assertion failure
--- Additional Comments From green at redhat dot com 2005-04-06 03:49 --- I'm getting the following with a sample JOGL application: ** ERROR **: file ../../../libjava/jni/gtk-peer/gtk_jawt.c: line 77 (classpath_jawt_get_default_display): assertion failed: (GTK_WIDGET_REALIZED (widget)) This, obviously, requires JOGL. The sample app is found in the "Chapter 7" download from here: http://www.genedavissoftware.com/books/jogl/appendix_d.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fitzsim at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20782
[Bug libgcj/20782] jawt assertion failure
--- Additional Comments From green at redhat dot com 2005-04-06 03:47 --- ** ERROR **: file ../../../libjava/jni/gtk-peer/gtk_jawt.c: line 77 (classpath_jawt_get_default_display): assertion failed: (GTK_WIDGET_REALIZED (widget)) -- What|Removed |Added Summary|jawt assertion failure: |jawt assertion failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20782
[Bug libgcj/20782] New: jawt assertion failure:
-- Summary: jawt assertion failure: Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20782
[Bug tree-optimization/20773] ICE: SEGV building jar file
--- Additional Comments From green at redhat dot com 2005-04-06 02:17 --- (In reply to comment #3) > Hmm, do you know what compiler the class files were created with? The Eclipse bytecode compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug java/20773] ICE: SEGV building jar file
--- Additional Comments From green at redhat dot com 2005-04-05 19:59 --- Created an attachment (id=8539) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8539&action=view) Problem jar file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug java/20773] New: ICE: SEGV building jar file
I'm seeing the following:
# gcj -O2 -shared -findirect-dispatch -Wl,-Bsymbolic -fPIC -o libtritonus.jar.so
tritonus.jar
org/tritonus/util/TCircularBuffer.java: In class
'org.tritonus.util.TCircularBuffer':
org/tritonus/util/TCircularBuffer.java: In method
'org.tritonus.util.TCircularBuffer.read(byte[],int,int)':
org/tritonus/util/TCircularBuffer.java:0: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla> for instructions.
This works at -O0 and fails at -O1 and above.
I will attach the jar file to this case. It comes from tritonus-0.3.0 which is
Free Software.
--
Summary: ICE: SEGV building jar file
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug libgcj/20727] double free or corruption
--- Additional Comments From green at redhat dot com 2005-04-03 08:28 --- Fix committed to 4.0 branch and HEAD. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20727
[Bug libgcj/20727] double free or corruption
--- Additional Comments From green at redhat dot com 2005-04-03 08:28 --- Fix checked into 4.0 branch and HEAD. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |green at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-03 08:28:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20727
[Bug libgcj/20727] New: double free or corruption
When I run a sample jogl application with gcj, I get the following at the end Program received signal SIGABRT, Aborted. [Switching to Thread -1210319952 (LWP 18094)] 0x008e27a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) where #0 0x008e27a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00922955 in raise () from /lib/tls/libc.so.6 #2 0x00924319 in abort () from /lib/tls/libc.so.6 #3 0x00955f9a in __libc_message () from /lib/tls/libc.so.6 #4 0x0095c528 in _int_free () from /lib/tls/libc.so.6 #5 0x0095cafa in free () from /lib/tls/libc.so.6 #6 0x0271de29 in java::nio::VMDirectByteBuffer::free () from /usr/lib/libgcj.so.6 #7 0x028306df in java::nio::DirectByteBufferImpl::finalize () from /usr/lib/libgcj.so.6 #8 0x02713db5 in _Jv_FinalizeObject () from /usr/lib/libgcj.so.6 #9 0x02a49df5 in _Jv_AllocRawObj () from /usr/lib/libgcj.so.6 #10 0x02a51c9a in GC_invoke_finalizers () from /usr/lib/libgcj.so.6 #11 0x02a49e53 in _Jv_RunFinalizers () from /usr/lib/libgcj.so.6 #12 0x0270906c in gnu::gcj::runtime::FinalizerThread::run () from /usr/lib/libgcj.so.6 #13 0x027196a5 in _Jv_ThreadRun () from /usr/lib/libgcj.so.6 #14 0x02a4b696 in _Jv_ThreadUnRegister () from /usr/lib/libgcj.so.6 #15 0x02a5c270 in GC_start_routine () from /usr/lib/libgcj.so.6 #16 0x00b423ae in start_thread () from /lib/tls/libpthread.so.0 #17 0x009c1b6e in clone () from /lib/tls/libc.so.6 (gdb) I don't have a simple test case yet. I will provide one once we have a jogl that builds reliably. Just thought I'd file this in the meanwhile... -- Summary: double free or corruption Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20727
[Bug java/20522] New: ICE in update_aliases, at java/decl.c:163
Found while building rhino's js.jar. Grab js.jar from http://spindazzle.org/js.jar (sources from JPackage.org). Try $ gcj -O1 -shared -o js.jar.so js.jar I get an ICE in update_aliases, at java/decl.c:163 -- Summary: ICE in update_aliases, at java/decl.c:163 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com CC: aph at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20522
[Bug libgcj/20435] New: regex pattern compiling bug
The following test code (derived from the blojsom wiki code) exposes a bug in
our regex compiler
import java.util.regex.Pattern;
public class pat
{
private static final String YMD_PERMALINK_REGEX =
"/(\\d\\d\\d\\d)/(\\d{1,2}+)/(\\d{1,2}+)/(.+)";
private static final Pattern YMD_PERMALINK_PATTERN =
Pattern.compile(YMD_PERMALINK_REGEX, Pattern.UNICODE_CASE);
public static void main (String[] args)
{
System.out.println ("ok");
}
}
This should print "ok", but instead we get:
$ gij pat
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0)
at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader)
(/usr/lib/libgcj.so.6.0.0)
at java.lang.Class.forName(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
Caused by: java.util.regex.PatternSyntaxException: At position 8 in regular
expression pattern:
attempted to repeat a token that is already repeated
/(\d\d\d\d)/(\d{1,2}+)/(\d{1,2}+)/(.+)
^
at java.util.regex.Pattern.Pattern(java.lang.String, int)
(/usr/lib/libgcj.so.6.0.0)
at java.util.regex.Pattern.compile(java.lang.String, int)
(/usr/lib/libgcj.so.6.0.0)
at pat.() (Unknown Source)
at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0)
...3 more
--
Summary: regex pattern compiling bug
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20435
[Bug libgcj/18116] JNI uses dot instead of slash as the package separator
--- Additional Comments From green at redhat dot com 2005-02-14 15:04 --- Fix and testcase committed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18116
[Bug libgcj/18116] JNI uses dot instead of slash as the package separator
--- Additional Comments From green at redhat dot com 2005-02-14 15:03 --- Fixed. I checked in a slightly different patch for the dot-slash problem, having not seen yours until later. This new patch stores the signatures in "dot" format instead of implementing a special compare routine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |green at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-21 07:21:38 |2005-02-14 15:03:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18116
[Bug java/19742] New: gcjh shouldn't mangle names in JNI output.
A java class has this:
public static final int delete = 555;
gcjh will correctly mangle the name delete (to delete$) for CNI header output.
However, it also does this when generating JNI output (with gcjh -jni). We get
output link this, and it is wrong:
#undef foo_delete$
#define foo_delete$ 555L
This should be just "foo_delete". This is preventing the subversion JNI code
from building.
--
Summary: gcjh shouldn't mangle names in JNI output.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19742
[Bug libgcj/18220] Test case libjava.lang/Process_3 does not end if "sed" not available
--- Additional Comments From green at redhat dot com 2004-10-29 18:24 --- I'm testing in a minimal chrooted environment. This is a simple way to test a new glibc/libgcj.etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18220
[Bug libgcj/18220] Test case libjava.lang/Process_3 does not end if "sed" not available
--- Additional Comments From green at redhat dot com 2004-10-29 18:10 --- It seems that all the Process_* test cases depend on having a small number of simple executables on the target (false, sed, echo). It would nice if the testsuite could provide similar programs instead of assuming they exist on the target (none of these existed on my minimal linux target). Rather than perform complicated dejagnu hackery, it might be easier to attach the required programs as resources to the test programs themselves, and then have the test case write them on the target filesystem before execution. Any strong objections to this idea? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18220
[Bug java/18220] New: Test case libjava.lang/Process_3 does not end if "sed" not available
libjava.lang/Process_3.java should be changed to do something other than hang
forever if "sed" is not available on the target test platform.
--
Summary: Test case libjava.lang/Process_3 does not end if "sed"
not available
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18220
