http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #26 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-12
08:30:17 UTC ---
(In reply to comment #25)
If we make an ABI switch at some point, should we move over to relying just on
atomics and the libatomic fallbacks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
Alan Modra amodra at gmail dot com changed:
What|Removed |Added
Known to fail||4.7.0
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #28 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-12
10:06:38 UTC ---
all those uses in streams and facets are (I believe) from std::locale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC|bkoz at gcc dot gnu.org |bkoz at redhat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #19 from Alan Modra amodra at gmail dot com 2012-04-10 15:13:24
UTC ---
I think I was on the right track when I questioned whether the problem might be
mixing atomics and mutex protected ops, but was looking in the wrong place. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-10
15:36:40 UTC ---
You're quite right, my apologies for telling you that wouldn't happen.
In bits/shared_ptr_base.h we have:
template
inline void
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.1
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
Alan Modra amodra at gmail dot com changed:
What|Removed |Added
Target Milestone|4.7.1 |---
--- Comment #22
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #23 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-11
00:30:46 UTC ---
I hadn't got as far as tracking down when it changed - if you're right that
would be quite nice and we'll be able to fix it properly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||bkoz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #15 from Alan Modra amodra at gmail dot com 2012-04-05 08:06:30
UTC ---
Many hours later one of my 32-bit tests failed, but I'm relieved to say it was
only the pthread_once bug.
#0 0x0fbd839c in raise () from /lib/power7/libc.so.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-05
08:09:53 UTC ---
I think we want a macro saying atomics are available for 'int' (which libstdc++
needs for its own uses) and a separate macro saying atomics are available for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #17 from Alan Modra amodra at gmail dot com 2012-04-05 12:05:01
UTC ---
I spent quite a bit of time today looking at libpthread and can't spot a
problem in pthread_mutex_lock and pthread_mutex_unlock.
I wonder if the problem is that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-05
13:02:53 UTC ---
(In reply to comment #17)
I wonder if the problem is that libstdc++ is using both atomics and
pthread_mutex protected manipulation of the same variable?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-04
08:31:02 UTC ---
Revision: 186100
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #7 from Alan Modra amodra at gmail dot com 2012-04-04 09:57:51
UTC ---
I also see the same 64-bit failure on r186130. A lot harder to reproduce than
the 32-bit one I originally reported (which is still there on r186130). Likely
not a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-04
10:39:07 UTC ---
Doh, I completely failed to notice yours is powerpc not powerpc64 so I wasn't
testing 32-bit, sorry. I'll re-check when I get home this evening.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #9 from Alan Modra amodra at gmail dot com 2012-04-04 11:12:56
UTC ---
Heh. We're even. I didn't notice yours was a 64-bit failure until you told me
your gcc revision number.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #10 from Alan Modra amodra at gmail dot com 2012-04-04 14:20:57
UTC ---
I caught the 64-bit failure in the act. It's dying on the gcc_assert in
unwind-dw2.c:_Unwind_SetSpColumn, with the value read from
dwarf_reg_size_table[1] being
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-04
20:22:57 UTC ---
I can reproduce this with -m32 on gcc110
If I compile with -D_GLIBCXX_ATOMIC_BUILTINS then I no longer get the
double-free, after running in a loop for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #12 from Alan Modra amodra at gmail dot com 2012-04-04 22:27:43
UTC ---
glibc/ntpl/pthread_once.c:
static int once_lock = LLL_LOCK_INITIALIZER;
int
__pthread_once (once_control, init_routine)
pthread_once_t *once_control;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #13 from Alan Modra amodra at gmail dot com 2012-04-04 23:02:34
UTC ---
Huh, so glibc has a powerpc specific pthread_once, and that one has a different
bug. Lack of lwsync before atomic_increment (once_control);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #14 from Alan Modra amodra at gmail dot com 2012-04-05 04:00:07
UTC ---
Created attachment 27094
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27094
config patch
Yes, the 32-bit failure seems to be gone if we use the gcc builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-03
09:19:01 UTC ---
I'll have to wait until I've built trunk on power to debug it, but this should
only be possible if two threads can both decrement an atomic counter to zero,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-03
21:33:19 UTC ---
I haven't managed to reproduce a double-free on gcc110 in the compile farm, but
did get this:
#0 0x0080ef73a5fc in __GI_raise (sig=optimized out) at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-04
00:19:29 UTC ---
I can reliably reproduce that uncaught exception, which should be caught by the
handler on line 134, but not a double-free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #5 from Alan Modra amodra at gmail dot com 2012-04-04 01:11:47
UTC ---
Interesting. gcc revision? I've held back on svn update after hearing that
richi had broken the tree for powerpc. The uncaught exception might be an
eh_frame
29 matches
Mail list logo
