https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #56 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:4ec931c5e514ce0731cc72085af817ce0c6f3887
commit r14-11615-g4ec931c5e514ce0731cc72085af817ce0c6f3887
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #57 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:bbca95724c62ad1f860c2544e2b688b25ba79ec2
commit r13-9529-gbbca95724c62ad1f860c2544e2b688b25ba79ec2
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #58 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:31d7e0751e58ce006038fa5100a79da6ec6ddb7e
commit r12-11038-g31d7e0751e58ce006038fa5100a79da6ec6ddb7e
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #55 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:dd35f66287b7cca196a720c9641e463255dceb1c
commit r15-9425-gdd35f66287b7cca196a720c9641e463255dceb1c
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #54 from Jonathan Wakely ---
Furthermore, if two threads call the non-const begin() concurrently on a shared
rep, they both want to make a new clone and release their reference to the old
rep. If they both allocate a new clone and sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #53 from Jonathan Wakely ---
(In reply to tlknv from comment #44)
> Thanks Marc.
> I have posted my patch at
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg02086.html
This is just a bandaid and not sufficient to avoid the problem. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Bug 21334 depends on bug 33394, which changed state.
Bug 33394 Summary: Add test case for Thread race segfault in
std::string::append with -O and -s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33394
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Bug 21334 depends on bug 24882, which changed state.
Bug 24882 Summary: [meta-bug] Non-refcounted, moveable basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #51 from Jonathan Wakely ---
This is no longer an issue when using the new non-reference-counted std::string
implementation in GCC 5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #50 from Tim O'Neil ---
(In reply to Tim O'Neil from comment #49)
> In the hope this will help, I try to stay pretty current:
Oh, this is using the code James posted on 2005-05-02 above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Tim O'Neil changed:
What|Removed |Added
CC||tim at matterfab dot com
--- Comment #49 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #48 from Patrick J. LoPresti ---
Was this ever fixed? I do not see any mention of it in
https://gcc.gnu.org/gcc-4.9/changes.html nor 4.8/changes.html nor
4.7/changes.html nor...
In any event, "suspended" seems like the wrong status f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #47 from Jonathan Wakely 2012-05-31
16:42:27 UTC ---
21.4.1 [string.require] says that the non-const forms of operator[], at, front,
back, begin, rbegin, end and rend may not invalidate references, pointers and
iterators (so must not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #46 from tlknv at yandex dot ru 2012-05-31 16:13:15 UTC ---
Thanks Jonathan.
I didn't know about the new 23.2.2 requirements.
> but then a COW string is non-conforming in other ways too
Which ways? I know that I should read the standard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #45 from Jonathan Wakely 2012-05-31
15:54:05 UTC ---
Thanks for the patch, I'll take a look asap.
Just to answer this older comment ...
(In reply to comment #35)
> Who said that calling begin() on a non const std::string should be t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #44 from tlknv at yandex dot ru 2012-05-31 14:43:14 UTC ---
Thanks Marc.
I have posted my patch at
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg02086.html
This is essentially a couple of line change so I hope I don't need to find and
si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #43 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
tlknv at yandex dot ru changed:
What|Removed |Added
CC||tlknv at yandex dot ru
--- Commen
--- Comment #41 from pinskia at gcc dot gnu dot org 2007-06-14 01:27
---
*** Bug 32261 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
||do
--- Comment #40 from gianni at mariani dot ws 2007-05-09 01:54 ---
Paolo writes:
> ... concur that is better implemented without reference-counting ...
Could I ask you to enumerate the reasons why you come to this conclusion ? I
just want understand better why (royal) we came to this
--- Comment #39 from pcarlini at suse dot de 2007-05-08 19:50 ---
The proper status of this PR is SUSPENDED. Today, mid of 2007, we all more or
less concur that is better implemented without reference-counting,
optimized for short strings, and, of course, exploiting rvalue references.
I
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #38 from james dot kanze at gmail dot com 2007-05-08 16:21
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
On 8 May 2007 05:24:35 -, gianni at mariani dot ws
<[EMAIL PROTECTED]> wrote:
> --- Comment #36 from gianni at mariani dot ws 20
--- Comment #37 from james dot kanze at gmail dot com 2007-05-08 16:11
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
On 7 May 2007 21:08:05 -, gianni at mariani dot ws
<[EMAIL PROTECTED]> wrote:
> --- Comment #35 from gianni at mariani dot ws 20
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2005-10-22 08:24
---
Not SPARC/Solaris specific.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-06-03 23:51
---
Certainly, numbers from actual benchmarks would be useful. In order to make
these
comparisons easier, next weeks I will add to the v7-branch basic_string an
alternate base-class implementation which avoids referen
--- Additional Comments From dank at kegel dot com 2005-06-03 23:37 ---
I'm tempted to start a new PR with summary "std::string slow in multithreaded
programs due to COW" so we can focus on the quality of implementation
issue, and leave aside the question of correctness.
James, could you
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-04 12:46
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> [...]
|> | This bug report came about because of a discussion in a news
|> | group. Basically, I said to watch out for std::string
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-04 12:12 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
"jkanze at cheuvreux dot com" <[EMAIL PROTECTED]> writes:
[...]
| This bug report came about because of a discussion in a new
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-04 09:14
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> >|> Secondly, it is clear that your bug report is hypothetical. The
|> >|> library maintainers do not typically deal in hypothetica
--- Additional Comments From rittle at latour dot waar dot labs dot mot dot
com 2005-05-03 19:08 ---
Subject: Re: Lack of Posix compliant thread safety in
std::basic_string
>|> Secondly, it is clear that your bug report is hypothetical. The
>|> library maintainers do not typic
"jkanze at cheuvreux dot com" <[EMAIL PROTECTED]> writes:
> Regretfully no. For reasons beyond my fathoming, we have to use
> Lotus Notes on a Windows machine for all external email, and
> they've set up the Notes server to add this trailer (which as
> you correctly point out, doesn't make much s
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 15:57
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> > "This message, including any attachments may contain confidential and
|> > privileged material; it is intended only for the person
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03
15:06 ---
(In reply to comment #24)
> "This message, including any attachments may contain confidential and
> privileged material; it is intended only for the person to whom it is
...
Can you stop attaching this mess
--- Additional Comments From pcarlini at suse dot de 2005-05-03 11:14
---
Hi James, and thanks for your explanations. Indeed, maybe better concentrating
on the v7-branch + documentation updates: as I told you already the framework
is already there and I will add very soon a different pol
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 10:59
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> > I'm not sure what sort of help you are looking for. I thought
|> > that I very clearly pointed out the problem, and the point in
--- Additional Comments From pcarlini at suse dot de 2005-05-03 10:39
---
In exceptions, I'm tempted to use something very simple, a fixed-size buffer,
as in STLPort, but that is the typical change affecting the ABI :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Additional Comments From pcarlini at suse dot de 2005-05-03 09:29
---
> I'm not sure what sort of help you are looking for. I thought
> that I very clearly pointed out the problem, and the point in
> the code where it occured.
Ok, my message was not clear. I'm looking for help abou
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 09:09
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> Whereas I'm all for providing alternate memory management
|> policies (we are very close to that in the v7-branch and I
|> promise f
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:56
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> >I am sending this to the g++ bug list on the recommendation of
|> >Gabriel Dos Reis. From what little I've read in the g++
|> >doc
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:37
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> Does the C++ standard mention multithreading and Posix
|> threads? ;)
No, but the g++ installation procedures do. According to the
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:34
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> Isn't this a bug as opposed to "enhancement"? Enhancement
|> suggests that the behaviour is basically correct, but could be
|> impr
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-02 18:45 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| --- Additional Comments From pcarlini at suse dot de 2005-05-02 17
--- Additional Comments From pcarlini at suse dot de 2005-05-02 17:33
---
About the last issue, besided confidential information, there is this nice
public thread that nicely summarizes it:
http://tinyurl.com/9o4oj
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Additional Comments From pcarlini at suse dot de 2005-05-02 17:23
---
> I don't quite understand why you want to see this issue as a memory
> management policy issue, as opposed to a thread safety issue.
Whatever, after all that is the layer at which you actually do the low-level
m
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-02 17:17 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| --- Additional Comments From pcarlini at suse dot de 2005-05-02 17
--- Additional Comments From pcarlini at suse dot de 2005-05-02 17:01
---
> You probably got the mail about users saying that he read on C++
> newsgroups that V3-s implementation of std::string is known to be
> avoided in multi-threaded programs.
Whereas I'm all for providing alternate
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-02 16:40 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
"rittle at latour dot waar dot labs dot mot dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: New: Lack of Posix compliant t
--- Additional Comments From rittle at latour dot waar dot labs dot mot dot
com 2005-05-02 16:02 ---
Subject: Re: New: Lack of Posix compliant thread safety in
std::basic_string
>I am sending this to the g++ bug list on the recommendation of
>Gabriel Dos Reis. From what little
--- Additional Comments From gdr at gcc dot gnu dot org 2005-05-02 14:42
---
(In reply to comment #9)
> Does the C++ standard mention multithreading and Posix threads? ;)
That is a very uninteresting question. You're quite right that the
C++ standard does not mention usability, though.
--- Additional Comments From pcarlini at suse dot de 2005-05-02 14:20
---
Does the C++ standard mention multithreading and Posix threads? ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-02 14:09 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| --- Additional Comments From pcarlini at suse dot de 2005-05-02 13
--- Additional Comments From pcarlini at suse dot de 2005-05-02 13:32
---
*** Bug 10350 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-05-02 13:31
---
Ok, thanks, let's keep open this one, then.
--
What|Removed |Added
Severity|minor
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-02 13:30
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
|> Two quick comments: 1- I'd like to keep open either 10350 or
|> this one, I don't see much value in keeping open both. Ok?
In that
--- Additional Comments From gdr at integrable-solutions dot net
2005-05-02 13:27 ---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Two quick comments: 1- I'd like to keep open either 10350 or this
| one
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-02 13:22
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
Looks like it. The example function at the user level isn't the
same, but the basic problem is.
I'd forgotten I ever sent the first o
--- Additional Comments From pcarlini at suse dot de 2005-05-02 12:02
---
Two quick comments: 1- I'd like to keep open either 10350 or this one, I don't
see much value in keeping open both. Ok? 2- I'm not aware of any real cure for
this kind of problems within a RC implementation. Are yo
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-02
11:54 ---
Is this a duplicate of bug 10350?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
63 matches
Mail list logo
