: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
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 dot com
http
--- 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 #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__
((__weakref__
--- 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=14104action=view)
Output of mipsel-linux-gcc -Os -s tworelocs.c
gcc output attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- 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
: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at gmail dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mipsel-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
--- 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
: regression
AssignedTo: 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 #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
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 #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
--- 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 affected
--- 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 for looking
--- 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):
$ powerpc
--- 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 #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 #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
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at gmail dot com
GCC host triplet: i686-pc-linux-gnu
GCC target
--- 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.gnu.org
--- 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:
tryfunc
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 gmail dot
--- 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 |Added
24 matches
Mail list logo
