* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
@ 2004-07-18 3:42 ` pinskia at gcc dot gnu dot org
2004-07-18 12:39 ` steve dot horn at gs dot com
` (25 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-18 3:42 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-07-18 03:42 -------
HUH? Why would do such a thing in the first place, C++ is not designed to go across shared memory at
all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
2004-07-18 3:42 ` [Bug libstdc++/16612] " pinskia at gcc dot gnu dot org
@ 2004-07-18 12:39 ` steve dot horn at gs dot com
2004-07-18 14:25 ` pinskia at gcc dot gnu dot org
` (24 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: steve dot horn at gs dot com @ 2004-07-18 12:39 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steve dot horn at gs dot com 2004-07-18 12:39 -------
(In reply to comment #1)
> HUH? Why would do such a thing in the first place, C++ is not designed to go
across shared memory at
> all.
It's fairly common to use allocators to put STL collections in shared memory.
Here are some references that mention exactly that:
http://gcc.gnu.org/ml/libstdc++/2003-01/msg00099.html
http://www.spcspringboard.com/Catalog/effectivestl.htm
http://www.codeproject.com/cpp/allocator.asp
For the most part, I've found that libstdc++ handles doing this very well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
2004-07-18 3:42 ` [Bug libstdc++/16612] " pinskia at gcc dot gnu dot org
2004-07-18 12:39 ` steve dot horn at gs dot com
@ 2004-07-18 14:25 ` pinskia at gcc dot gnu dot org
2004-07-19 13:59 ` bangerth at dealii dot org
` (23 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-18 14:25 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-07-18 14:25 -------
What about giving an example and maybe trying 3.3.4 or 3.4.1 since 3.2.x is a non updated version?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (2 preceding siblings ...)
2004-07-18 14:25 ` pinskia at gcc dot gnu dot org
@ 2004-07-19 13:59 ` bangerth at dealii dot org
2004-07-19 23:20 ` bkoz at gcc dot gnu dot org
` (22 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: bangerth at dealii dot org @ 2004-07-19 13:59 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-07-19 13:59 -------
The claim is valid. Let's let the libstdc++ maintainers comment, as I'm
sure there are standards and/or ABI implications in storing a single empty
string representation.
Andrew, please try to be less dismissive for bug reports where you don't
understand what's going on. C++'s allocator scheme is created _exactly_ for
the case the submitter wants to use it for.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (3 preceding siblings ...)
2004-07-19 13:59 ` bangerth at dealii dot org
@ 2004-07-19 23:20 ` bkoz at gcc dot gnu dot org
2004-07-21 6:53 ` bkoz at gcc dot gnu dot org
` (21 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2004-07-19 23:20 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bkoz at gcc dot gnu dot org 2004-07-19 23:20 -------
Investigating...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (4 preceding siblings ...)
2004-07-19 23:20 ` bkoz at gcc dot gnu dot org
@ 2004-07-21 6:53 ` bkoz at gcc dot gnu dot org
2004-07-21 12:55 ` steve dot horn at gs dot com
` (20 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2004-07-21 6:53 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bkoz at gcc dot gnu dot org 2004-07-21 06:53 -------
An example, or at least the custom allocator for shared memory, would be useful.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (5 preceding siblings ...)
2004-07-21 6:53 ` bkoz at gcc dot gnu dot org
@ 2004-07-21 12:55 ` steve dot horn at gs dot com
2004-07-21 14:02 ` bangerth at dealii dot org
` (19 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: steve dot horn at gs dot com @ 2004-07-21 12:55 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steve dot horn at gs dot com 2004-07-21 12:55 -------
Created an attachment (id=6793)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6793&action=view)
example of problem
Tested on:
gcc 3.4.1 on Mac OS X and
gcc 3.2.3 on RedHat Enterprice Linux 3 AS (update 1)
The makefile builds 'test-bigger', 'test', and cleanShm.
cleanShm deletes the shared memory segment created by the other programs.
'test' and 'test-bigger' are created from the same source files.
The only different between 'test-bigger' and 'test' is that 'test-bigger'
declares a static array of integers before any includes in order to force
basic_string's _S_empty_rep_storage to move to a different location.
Execute 'test-bigger' before 'test' to observe the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (6 preceding siblings ...)
2004-07-21 12:55 ` steve dot horn at gs dot com
@ 2004-07-21 14:02 ` bangerth at dealii dot org
2004-07-21 19:35 ` pinskia at gcc dot gnu dot org
` (18 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: bangerth at dealii dot org @ 2004-07-21 14:02 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-07-21 14:02 -------
Not knowing much about the code in question, but here is where I see
the problem: in basic_string.h, we have a representation of the empty
string:
struct _Rep : _Rep_base
{
/*...*/
// The following storage is init'd to 0 by the linker, resulting
// (carefully) in an empty string with one reference.
static size_type _S_empty_rep_storage[];
This member variable is indeed zero initialized in the linker, see
basic_string.tcc:
// Linker sets _S_empty_rep_storage to all 0s (one reference, empty string)
// at static init time (before static ctors are run).
template<typename _CharT, typename _Traits, typename _Alloc>
typename basic_string<_CharT, _Traits, _Alloc>::size_type
basic_string<_CharT, _Traits, _Alloc>::_Rep::_S_empty_rep_storage[
(sizeof(_Rep_base) + sizeof(_CharT) + sizeof(size_type) - 1) /
sizeof(size_type)];
Note that allocation of this memory is done by the linker in the address
space of each program that uses strings, not by an allocator class. Thus,
if two programs use shared memory to communicate with each other, their
_S_empty_rep_storage objects may lie at different addresses. Whether that
is a problem I don't know, but it seems unsafe indeed.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (7 preceding siblings ...)
2004-07-21 14:02 ` bangerth at dealii dot org
@ 2004-07-21 19:35 ` pinskia at gcc dot gnu dot org
2004-07-22 1:31 ` steve dot horn at gs dot com
` (17 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-21 19:35 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-07-21 19:35 -------
It works for me with both Apple's 3.3 and the FSF mainline on powerpc-apple-darwin so ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (8 preceding siblings ...)
2004-07-21 19:35 ` pinskia at gcc dot gnu dot org
@ 2004-07-22 1:31 ` steve dot horn at gs dot com
2004-07-22 4:35 ` bkoz at gcc dot gnu dot org
` (16 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: steve dot horn at gs dot com @ 2004-07-22 1:31 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From steve dot horn at gs dot com 2004-07-22 01:31 -------
It crashes on me. Below is what I see in gdb for the 'test' executable.
Note that for the empty string created in 'test-bigger' (e.g. header->string3) _M_p is
<Address 0x40642c out of bounds>
For the empty string declared in 'test', _M_p is 0x642c ""
The non-empty strings populated in 'test-bigger' are all in 'test's address space.
Calling mmap(addr=0x6400000, size=65536, mprod=3, mflags=1, fd=6, offset=0);
mmap succeeded!
Got the requested address.
First string: [hello world]
Second string: [foo bar]
Breakpoint 3, main (argc=1, argv=0xbffffb44) at test.C:53
53 std::cout << "Third string: [" << *header->string3 << "]" << std::endl;
(gdb) p emptyString
$4 = {
static npos = <optimized out>,
_M_dataplus = {
<ShmAllocator<char>> = {<No data fields>},
members of basic_string<char,std::char_traits<char>,ShmAllocator<char> >::_Alloc_hider:
_M_p = 0x642c ""
}
}
(gdb) p header->string3
$5 = (ShmString *) 0x640002c
(gdb) p *header->string3
$6 = {
static npos = <optimized out>,
_M_dataplus = {
<ShmAllocator<char>> = {<No data fields>},
members of basic_string<char,std::char_traits<char>,ShmAllocator<char> >::_Alloc_hider:
_M_p = 0x40642c <Address 0x40642c out of bounds>
}
}
(gdb) p *header->string2
$7 = {
static npos = <optimized out>,
_M_dataplus = {
<ShmAllocator<char>> = {<No data fields>},
members of basic_string<char,std::char_traits<char>,ShmAllocator<char> >::_Alloc_hider:
_M_p = 0x6400064 "foo bar"
}
}
(gdb) n
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0000361c in std::basic_string<char, std::char_traits<char>, ShmAllocator<char> >::size() const
(this=0x640002c) at /Users/horns/gcc-3.4.1/lib/gcc/powerpc-apple-darwin7.4.0/3.4.1/../../../../
include/c++/3.4.1/bits/basic_string.h:532
532 size() const { return _M_rep()->_M_length; }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (9 preceding siblings ...)
2004-07-22 1:31 ` steve dot horn at gs dot com
@ 2004-07-22 4:35 ` bkoz at gcc dot gnu dot org
2004-07-22 5:28 ` bkoz at gcc dot gnu dot org
` (15 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2004-07-22 4:35 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bkoz at gcc dot gnu dot org 2004-07-22 04:35 -------
I can reproduce this on x86/linux (FC2) with both gcc-3.3.3 and gcc-3.4.2. I
wonder how to fix this gracefully.
A shared memory allocator of some kind should probably be added as an extension,
regardless.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (10 preceding siblings ...)
2004-07-22 4:35 ` bkoz at gcc dot gnu dot org
@ 2004-07-22 5:28 ` bkoz at gcc dot gnu dot org
2004-07-22 7:25 ` bkoz at gcc dot gnu dot org
` (14 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2004-07-22 5:28 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bkoz at gcc dot gnu dot org 2004-07-22 05:28 -------
Created an attachment (id=6798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6798&action=view)
same test, for vector
this switches containers to vector, which works without failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (11 preceding siblings ...)
2004-07-22 5:28 ` bkoz at gcc dot gnu dot org
@ 2004-07-22 7:25 ` bkoz at gcc dot gnu dot org
2004-08-02 11:48 ` pcarlini at suse dot de
` (13 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2004-07-22 7:25 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bkoz at gcc dot gnu dot org 2004-07-22 07:25 -------
Created an attachment (id=6799)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6799&action=view)
preliminary removal of _S_empty_rep_storage
This is a hacked patch, just to have an allocator-allocated memory for the
empty string. Using this version of string, the testcase that used to fail will
pass for me.
This is probably not the right way to do this, so I'll wait for Paolo to look
at this when he gets back.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (12 preceding siblings ...)
2004-07-22 7:25 ` bkoz at gcc dot gnu dot org
@ 2004-08-02 11:48 ` pcarlini at suse dot de
2004-08-04 4:56 ` ncm-nospam at cantrip dot org
` (12 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: pcarlini at suse dot de @ 2004-08-02 11:48 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2004-08-02 11:48 -------
Thanks Benjamin, I'm looking into it now.
--
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2004-08-02 11:48:47
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (13 preceding siblings ...)
2004-08-02 11:48 ` pcarlini at suse dot de
@ 2004-08-04 4:56 ` ncm-nospam at cantrip dot org
2004-09-08 14:43 ` bkoz at gcc dot gnu dot org
` (11 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: ncm-nospam at cantrip dot org @ 2004-08-04 4:56 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ncm-nospam at cantrip dot org 2004-08-04 04:56 -------
I am sympathetic to this usage, and would like to accommodate it.
At the same time, it would be tragic if such accomodation demolished
the performance of the regular string. A lot rides on that fixed
address -- particularly in 3.4 and later, which actually checks for
it specifically, and avoids incrementing or decrementing the refcount
at that address. Anything that makes _S_empty_rep() slower slows
down the default string constructor, and a lot of user code.
Note too that it is very common to use strings during programmed
"static" initialization, so it has to be initialized by the linker,
and not at some random point during that process. (There is no
control over the order in which such initializations run, in general,
although some targets' linkers support special hacks.)
Now that nothing modifies the empty-string rep object, it would almost
be possible to use NULL as the address. The fly in the ointment is
the recent extension (grrr!) requiring that s.operator[](s.length())
actually yield a zero. (There's no requirement for c_str's result to
match anything else (it might yield "(charT*)this"!), and data() could
yield zero + N safely because it can't be dereferenced.) Of course
any sort of conditional check in operator[] could be a performance
disaster, and length() and many other operations would need a
conditional check too. Still, it might well be a win, overall.
What else might we do? We certainly ought to be able to
partial-specialize on the default allocator to continue using the
purely static initialization. But what about user allocators,
including shared-memory allocators? Using shared memory doesn't, by
itself, mean you really want string operations to be slow. More
importantly, the shared memory region might not be ready to use at
program startup time, or when the library is being loaded, so any
kind of programmed static initialization (init order problems aside)
is out.
That leaves something akin to Benjamin's approach -- although
inlining all that probably would be a mistake. It seems to me the
comparison to zero need not involve a memory barrier -- once it's
nonzero, it will never change again. It appears that each process
that maps the shared storage would leak its own empty string into it.
A memory region shared among lots of transient processes would fill
up quickly. Copying some other process's empty string will involve
a real atomic increment, because the address won't match its own --
which also means the originating process really can't safely clean up.
In principle, we could document that we allocate some distinguished
type, so that if the user controls the allocator (or can
partial-specialize for that case) and give all processes the same
address, then only one instance leaks. (Of course that address would
have to be stored in the shared-memory region, too, but that would be
the allocator's business.)
A more robust alternative might be to export a block of zeroes from
libsupc++ specifically for this purpose; it could be shared among
all string types (or at least among all basic_string<char,T,A> and
basic_string<wchar_t,T,A>). Too, it should speed up regular string
operations when libstdc++ is dynamic-linked, because it would avoid
one stage of relocation (I think). I assume here that libsupc++'s
static storage would always appear at a fixed address. Maybe I'm
wrong. (Maybe there's already a block of zeroes there that we can
share!)
That's all I can think of at this hour, but there ought to be other
practical alternatives, too. Let's not be hasty.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |ncm at cantrip dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (14 preceding siblings ...)
2004-08-04 4:56 ` ncm-nospam at cantrip dot org
@ 2004-09-08 14:43 ` bkoz at gcc dot gnu dot org
2004-09-28 8:59 ` cvs-commit at gcc dot gnu dot org
` (10 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2004-09-08 14:43 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bkoz at gcc dot gnu dot org 2004-09-08 14:42 -------
Paolo, can you reassign this to me? Thanks!
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (15 preceding siblings ...)
2004-09-08 14:43 ` bkoz at gcc dot gnu dot org
@ 2004-09-28 8:59 ` cvs-commit at gcc dot gnu dot org
2004-09-28 9:28 ` [Bug libstdc++/16612] [3.4 only] " pcarlini at suse dot de
` (9 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2004-09-28 8:59 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-09-28 08:58 -------
Subject: Bug 16612
CVSROOT: /cvs/gcc
Module name: gcc
Changes by: paolo@gcc.gnu.org 2004-09-28 08:58:36
Modified files:
libstdc++-v3 : ChangeLog README acconfig.h acinclude.m4
config.h.in configure configure.ac
libstdc++-v3/docs/html: configopts.html
libstdc++-v3/include/bits: basic_string.h basic_string.tcc
Added files:
libstdc++-v3/testsuite/21_strings/basic_string/element_access/char:
empty.cc
libstdc++-v3/testsuite/21_strings/basic_string/element_access/wchar_t:
empty.cc
libstdc++-v3/testsuite/21_strings/basic_string/operations/char:
1.cc
libstdc++-v3/testsuite/21_strings/basic_string/operations/wchar_t:
1.cc
Log message:
2004-09-28 Paolo Carlini <pcarlini@suse.de>
PR libstdc++/16612
* include/bits/basic_string.h (_M_dispose, _M_refcopy,
basic_string()): When _GLIBCXX_FULLY_DYNAMIC_STRING is defined,
don't deal with _S_empty_rep.
* include/bits/basic_string.tcc (_S_construct, _M_destroy,
_M_leak_hard, _M_mutate): Likewise.
* acinclude.m4 (GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING): New.
* acconfig.h: Add corresponding undef.
* configure.ac: Use GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING.
* docs/html/configopts.html: Document --enable-fully-dynamic-string.
* configure: Regenerate.
* config.h.in: Likewise.
2004-09-28 Benjamin Kosnik <bkoz@redhat.com>
Paolo Carlini <pcarlini@suse.de>
* testsuite/21_strings/basic_string/operations/char/1.cc: New.
* testsuite/21_strings/basic_string/operations/wchar_t/1.cc: New.
* testsuite/21_strings/basic_string/element_access/char/empty.cc: New.
* testsuite/21_strings/basic_string/element_access/wchar_t/empty.cc:
New.
2004-09-28 Paolo Carlini <pcarlini@suse.de>
* README: Remove obsolete entry about include/c_shadow.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2672&r2=1.2673
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/README.diff?cvsroot=gcc&r1=1.16&r2=1.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acconfig.h.diff?cvsroot=gcc&r1=1.42&r2=1.43
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acinclude.m4.diff?cvsroot=gcc&r1=1.296&r2=1.297
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config.h.in.diff?cvsroot=gcc&r1=1.83&r2=1.84
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.diff?cvsroot=gcc&r1=1.406&r2=1.407
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.ac.diff?cvsroot=gcc&r1=1.25&r2=1.26
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/docs/html/configopts.html.diff?cvsroot=gcc&r1=1.37&r2=1.38
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_string.h.diff?cvsroot=gcc&r1=1.62&r2=1.63
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_string.tcc.diff?cvsroot=gcc&r1=1.71&r2=1.72
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/basic_string/element_access/char/empty.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/basic_string/element_access/wchar_t/empty.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/basic_string/operations/char/1.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/basic_string/operations/wchar_t/1.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (16 preceding siblings ...)
2004-09-28 8:59 ` cvs-commit at gcc dot gnu dot org
@ 2004-09-28 9:28 ` pcarlini at suse dot de
2004-10-07 3:57 ` bkoz at gcc dot gnu dot org
` (8 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: pcarlini at suse dot de @ 2004-09-28 9:28 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Summary|empty basic_strings can't |[3.4 only] empty
|live in shared memory |basic_strings can't live in
| |shared memory
Target Milestone|--- |3.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (17 preceding siblings ...)
2004-09-28 9:28 ` [Bug libstdc++/16612] [3.4 only] " pcarlini at suse dot de
@ 2004-10-07 3:57 ` bkoz at gcc dot gnu dot org
2004-10-28 21:53 ` cvs-commit at gcc dot gnu dot org
` (7 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2004-10-07 3:57 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bkoz at gcc dot gnu dot org 2004-10-07 03:57 -------
I give this back to Paolo, since he's got the patch.
-benjamin
--
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|bkoz at gcc dot gnu dot org |pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (18 preceding siblings ...)
2004-10-07 3:57 ` bkoz at gcc dot gnu dot org
@ 2004-10-28 21:53 ` cvs-commit at gcc dot gnu dot org
2004-10-28 21:55 ` pcarlini at suse dot de
` (6 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2004-10-28 21:53 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-28 21:53 -------
Subject: Bug 16612
CVSROOT: /cvs/gcc
Module name: gcc
Branch: gcc-3_4-branch
Changes by: paolo@gcc.gnu.org 2004-10-28 21:52:42
Modified files:
libstdc++-v3 : ChangeLog configure configure.ac acinclude.m4
aclocal.m4 acconfig.h README config.h.in
libstdc++-v3/include/bits: basic_string.h basic_string.tcc
libstdc++-v3/docs/html: configopts.html
Log message:
2004-10-28 Paolo Carlini <pcarlini@suse.de>
* include/bits/basic_string.tcc (_M_mutate): Do not reallocate
unnecessarily when _M_rep() == &_S_empty_rep() and __new_size
== capacity() (== 0): is ok to just leave everything unchanged.
2004-10-28 Paolo Carlini <pcarlini@suse.de>
PR libstdc++/16612
* include/bits/basic_string.h (_M_dispose, _M_refcopy,
basic_string()): When _GLIBCXX_FULLY_DYNAMIC_STRING is defined,
don't deal with _S_empty_rep.
* include/bits/basic_string.tcc (_S_construct, _M_destroy,
_M_leak_hard, _M_mutate): Likewise.
* acinclude.m4 (GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING): New.
* acconfig.h: Add corresponding undef.
* configure.ac: Use GLIBCXX_ENABLE_FULLY_DYNAMIC_STRING.
* docs/html/configopts.html: Document --enable-fully-dynamic-string.
* aclocal.m4: Regenerate.
* configure: Likewise.
* config.h.in: Likewise.
2004-10-28 Paolo Carlini <pcarlini@suse.de>
* README: Remove obsolete entry about include/c_shadow.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.2224.2.191&r2=1.2224.2.192
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.373.4.20&r2=1.373.4.21
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.ac.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.14.4.5&r2=1.14.4.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acinclude.m4.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.280.4.6&r2=1.280.4.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/aclocal.m4.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.296.4.6&r2=1.296.4.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acconfig.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.39.4.2&r2=1.39.4.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/README.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.16&r2=1.16.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config.h.in.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.79.4.3&r2=1.79.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_string.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.41.4.5&r2=1.41.4.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_string.tcc.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.46.4.7&r2=1.46.4.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/docs/html/configopts.html.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.33.4.3&r2=1.33.4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (19 preceding siblings ...)
2004-10-28 21:53 ` cvs-commit at gcc dot gnu dot org
@ 2004-10-28 21:55 ` pcarlini at suse dot de
2005-01-05 9:49 ` cvs-commit at gcc dot gnu dot org
` (5 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: pcarlini at suse dot de @ 2004-10-28 21:55 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2004-10-28 21:55 -------
Fixed for 3.4.3.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (20 preceding siblings ...)
2004-10-28 21:55 ` pcarlini at suse dot de
@ 2005-01-05 9:49 ` cvs-commit at gcc dot gnu dot org
2005-01-20 23:01 ` pcarlini at suse dot de
` (4 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2005-01-05 9:49 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-05 09:49 -------
Subject: Bug 16612
CVSROOT: /cvs/gcc
Module name: gcc
Branch: gcc-3_2-rhl8-branch
Changes by: jakub@gcc.gnu.org 2005-01-05 09:49:05
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/include/bits: basic_string.h basic_string.tcc
Log message:
2004-10-28 Paolo Carlini <pcarlini@suse.de>
PR libstdc++/16612
* include/bits/basic_string.h (basic_string()): When
_GLIBCXX_FULLY_DYNAMIC_STRING is defined, don't deal with _S_empty_rep.
* include/bits/basic_string.tcc (_S_construct): Likewise.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_2-rhl8-branch&r1=1.1057.2.159.2.10.2.29&r2=1.1057.2.159.2.10.2.30
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_string.h.diff?cvsroot=gcc&only_with_tag=gcc-3_2-rhl8-branch&r1=1.19.2.5&r2=1.19.2.5.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_string.tcc.diff?cvsroot=gcc&only_with_tag=gcc-3_2-rhl8-branch&r1=1.20.2.5.4.1&r2=1.20.2.5.4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (21 preceding siblings ...)
2005-01-05 9:49 ` cvs-commit at gcc dot gnu dot org
@ 2005-01-20 23:01 ` pcarlini at suse dot de
2005-01-20 23:02 ` pcarlini at suse dot de
` (3 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: pcarlini at suse dot de @ 2005-01-20 23:01 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2005-01-20 23:01 -------
Reopening...
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (22 preceding siblings ...)
2005-01-20 23:01 ` pcarlini at suse dot de
@ 2005-01-20 23:02 ` pcarlini at suse dot de
2005-01-21 0:47 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
26 siblings, 0 replies; 36+ messages in thread
From: pcarlini at suse dot de @ 2005-01-20 23:02 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2005-01-20 23:02 -------
... as "enhancement".
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Status|REOPENED |ASSIGNED
Last reconfirmed|2004-08-02 11:48:47 |2005-01-20 23:02:02
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (23 preceding siblings ...)
2005-01-20 23:02 ` pcarlini at suse dot de
@ 2005-01-21 0:47 ` pinskia at gcc dot gnu dot org
2005-01-21 9:50 ` pcarlini at suse dot de
2005-09-05 15:29 ` pinskia at gcc dot gnu dot org
26 siblings, 0 replies; 36+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-21 0:47 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.4.3 |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (24 preceding siblings ...)
2005-01-21 0:47 ` pinskia at gcc dot gnu dot org
@ 2005-01-21 9:50 ` pcarlini at suse dot de
2005-09-05 15:29 ` pinskia at gcc dot gnu dot org
26 siblings, 0 replies; 36+ messages in thread
From: pcarlini at suse dot de @ 2005-01-21 9:50 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.4.4 |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread
* [Bug libstdc++/16612] [3.4 only] empty basic_strings can't live in shared memory
2004-07-18 3:37 [Bug libstdc++/16612] New: empty basic_strings can't live in shared memory steve dot horn at gs dot com
` (25 preceding siblings ...)
2005-01-21 9:50 ` pcarlini at suse dot de
@ 2005-09-05 15:29 ` pinskia at gcc dot gnu dot org
26 siblings, 0 replies; 36+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-09-05 15:29 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.1.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
^ permalink raw reply [flat|nested] 36+ messages in thread