--- Comment #10 from pcarlini at suse dot de 2006-09-02 08:34 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #9 from paolo at gcc dot gnu dot org 2006-09-02 08:31 ---
Subject: Bug 24469
Author: paolo
Date: Sat Sep 2 08:31:45 2006
New Revision: 116660
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116660
Log:
2006-09-02 Paolo Carlini <[EMAIL PROTECTED]>
Richar
--- Comment #8 from pcarlini at suse dot de 2006-08-31 18:08 ---
Now I know how to fix it...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|un
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-03-03 17:53 ---
Created an attachment (id=10964)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10964&action=view)
sources, as patched with p.20060303
Tarball of the patched sources.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-03-03 17:52 ---
Created an attachment (id=10963)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10963&action=view)
make _M_used, _M_free atomic
Hey. This is a patch to make these operations atomic. It's based on top of
another s
--- Comment #5 from pcarlini at suse dot de 2005-11-15 12:31 ---
(In reply to comment #4)
> Unfortunately I cannot perform such test because it would require changing
> stdlibc++ on many machines.
Out of curiosity: why many and not just one (and optionally, of course, along
the existing
--- Comment #4 from l_heldt at poczta dot onet dot pl 2005-11-15 12:26
---
Unfortunately I cannot perform such test because it would require changing
stdlibc++ on many machines.
My solution to this problem is setting GLIBCXX_FORCE_NEW variable before
starting application.
--
http:
--- Comment #3 from pcarlini at suse dot de 2005-11-15 12:02 ---
> 2- Otherwise, a lock in _M_reclaim_block only when __block->_M_thread_id !=
>__thread_id. At the same time has to be changed _M_reserve_block too,
>however, and it's tricky to do that without locking at every sing
--- Comment #2 from pcarlini at suse dot de 2005-10-27 10:16 ---
I can see a few possible strategies:
1- Arches supporting the new __sync_fetch_and_add (at least, i686, x86_64,
powerpc
ia64, s390), could simply use it on the existing __bin._M_used.
2- Otherwise, a lock in _M_reclaim_b
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24469
--- Comment #1 from pcarlini at suse dot de 2005-10-21 09:02 ---
Yes, I think this is a real issue. We already discussed it briefly with Stefan
(the initial contributor of the mt_allocator code):
http://gcc.gnu.org/ml/libstdc++/2004-07/msg00095.html
Thanks for reminding us the open p
11 matches
Mail list logo
