https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105932
Anthony Green changed:
What|Removed |Added
CC||green at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101208
Anthony Green changed:
What|Removed |Added
CC||green at redhat dot com
--- Comment #2
: 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]+\[avai
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
’
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85667
Anthony Green changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34311
--- Comment #3 from Anthony Green green at redhat dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50051
Anthony Green green at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50051
--- Comment #5 from Anthony Green green at redhat dot com 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=11283action=view)
Sample patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
--- 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
: 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
--- 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=11273action=view)
stack traces from gdb.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27170
at gcc dot gnu dot org
ReportedBy: green at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27171
--- 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
--- 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
--- 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
: 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
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: green at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26177
--- 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
at gcc dot gnu dot org
ReportedBy: green at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26007
--- 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
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
.
--
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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=10159action=view)
A patch
I think the attached patch will fix.
--
green at redhat dot com changed:
What|Removed
--- 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=9352action=view)
Proposed patch
This patch makes your test program emit an absolute path.
I'm
--- 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
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
--- 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
--- 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=9352action=view)
Proposed patch
This patch makes your test program emit an absolute path.
I'm not sure it's 100% correct
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
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
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
--- 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=8880action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
--- 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
--- 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
: 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
--- 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
--- 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
--- 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
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
--- 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=8736action=view)
Relevant part of build log.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21216
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |green at redhat dot com
|dot org |
Status|NEW
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
--- 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
--- 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
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
--- 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
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
--- 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=8565action=view)
Preprocessed source for test case (trimmed down)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20831
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
--- 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=8539action=view)
Problem jar file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
--- 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
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
--- 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
--- 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
--- 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
--- 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
: 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
: 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
: 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
--- 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
--- Additional Comments From green at redhat dot com 2005-02-14 15:04
---
Fix and testcase committed.
--
What|Removed |Added
Status|ASSIGNED
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
: 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
--- 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
--- 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
81 matches
Mail list logo
