bstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
ve alignment on
_M_instance
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at gmail
--- Comment #9 from atgraham at gmail dot com 2007-10-03 05:31 ---
The patch from Richard appears to fix the problem. With his patch applied, the
compiler output is correct.
--
atgraham at gmail dot com changed:
What|Removed |Added
--- Comment #7 from atgraham at gmail dot com 2007-08-24 16:34 ---
binutils bug created:
http://sourceware.org/bugzilla/show_bug.cgi?id=4959
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
--- Comment #5 from atgraham at gmail dot com 2007-08-24 16:12 ---
Created an attachment (id=14104)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14104&action=view)
Output of "mipsel-linux-gcc -Os -s tworelocs.c"
gcc output attached.
--
http://gcc
--- Comment #3 from atgraham at gmail dot com 2007-08-24 16:00 ---
Here is a smaller bit of code for reproducing this problem. This doesn't
depend on any C++.
#include "pthread.h"
static __typeof(pthread_mutex_lock) __gthrw_pthread_mutex_lock __attribute_
--- Comment #1 from atgraham at gmail dot com 2007-08-24 00:40 ---
This problem is due to the fact that GTHREAD_USE_WEAK is incorrectly defined
for this architecture.
--
atgraham at gmail dot com changed:
What|Removed |Added
same
symbol
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at gmail dot com
GCC host trip
--- Comment #3 from atgraham at gmail dot com 2006-09-27 04:28 ---
Ack! Sorry--I had indicated the wrong target on that one. The target is
vxworks, not linux. My 4.1.1 powerpc-linux compiler *does* get this
optimization right. So something in the vxworks-specific code is causing
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at gmail dot com
GCC host triplet: i686
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29248
--- Comment #1 from atgraham at gmail dot com 2006-08-22 18:43 ---
Patch was submitted to gcc-patches earlier, which is the same as the patch
already posted to the previous comment.
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00786.html
--
atgraham at gmail dot com changed
dot org
ReportedBy: atgraham at gmail dot com
GCC target triplet: powerpc-vxworks-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28808
--- Comment #14 from atgraham at gmail dot com 2006-08-14 18:16 ---
The following patch to the 4.1.1 release code appears to fix the problem.
Though I have not been able to convince myself that this is the CORRECT
solution to the problem (and am doubtful that it is), testing this fix
--- Comment #13 from atgraham at gmail dot com 2006-08-11 02:42 ---
The problem goes away (at least in this case) at optimization levels -O[s123]
(but remains at -O0) when compiling with -fstack-protector. Of course, that's
not really an acceptable workaround for most people aff
--- Comment #12 from atgraham at gmail dot com 2006-08-09 01:30 ---
(In reply to comment #11)
[...]
> it may be a problem with WRS running initializers or
> initializing the frame tables.
Both of the gcc builds I'm testing with are cross compilers (host
i686-pc-linux-gnu):
--- Comment #8 from atgraham at gmail dot com 2006-08-08 23:21 ---
(In reply to comment #7)
> I don't get any failures with the 4.0-branch for powerpc-linux with sjlj
> exceptions. Here's the executable test case I'm using for a regression hunt:
Janis,
Thank you
--- Comment #4 from atgraham at gmail dot com 2006-08-05 21:11 ---
Actually, it turns out that gcc versions before the 4.1 series all get it wrong
too, at -O0. The bug gets masked when introducing optimization. Here is the
-O0 output from 4.0.3:
g++-4.0.3 -O0 -msoft-float -mcpu=405
--- Comment #3 from atgraham at gmail dot com 2006-08-05 16:58 ---
This may not be related to 19774 as I had originally thought. This failure
case is new as of 4.1.0. GCC version 4.0.3 gets it right:
g++-4.0.3 -Os -msoft-float -mcpu=405 -c bug.cc -fno-inline -Wall -dA
--- Comment #7 from atgraham at gmail dot com 2006-08-02 17:03 ---
Is it possible that #28493 is a symptom of the same problem? Does anyone build
the darwin compiler with SjLj exceptions?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
--- Comment #2 from atgraham at gmail dot com 2006-07-27 02:47 ---
This bug appears to only happen when the compiler is built with SjLj
exceptions. When the compiler is built for dwarf2 exceptions, this test case
(and my original problem area) are both correct:
:
0: 94
--- Comment #1 from atgraham at gmail dot com 2006-07-26 15:42 ---
Actually, the for loop is unnecessary. Here's a shorter version that displays
the same problem:
struct Command {
virtual ~Command() {}
};
void tryfunc() {
Command cmd;
throw 1;
}
--
http://gcc.gn
ned at gcc dot gnu dot org
ReportedBy: atgraham at gmail dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-wrs-vxworks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28493
--- Comment #1 from atgraham at gmail dot com 2006-02-02 05:02 ---
I've also confirmed the following:
The optimization also works on gcc 2.95.2
It does not work on gcc 4.0.2
--
atgraham at gmail dot com changed:
What|Removed |
ime endian-ness check is no longer optimized out.
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at
24 matches
Mail list logo
