[Patch] libstdc++/19495

[Paolo Carlini]

Hi.

Since there is renewed interest in this long standing issue, I decided
to look again into it, hoping for a decently clean solution in v6 too.
Indeed, availing myself of Nathan's advice (see audit trail) I have been
able to prepare a simple fix for basic_string: basically, instead of
allocating memory via an allocator rebind to char, we use one rebind to
_Atomic_word (*). This should be always sufficient, taking into account
that the _Rep begins with *2* size_t fields, then an _Atomic_word field.

In my opinion, the only bits in principle slightly controversial are
those related to ext/array_allocator/2.cc itself, which I don't think we
can really keep as-is, barring major reworks of array_allocator too. The
problem is, the latter cannot really deal with rebinds: its templated
copy constructor instead of doing nothing (as happens with all the other
allocators) zeroes _M_array. This is arguably correct, because for
alignment reasons at least, we cannot really make meaningful use of the
underlying array-type memory for a type different from the original one.
Then, however, basic_string cannot use allocator rebind + allocator copy
constructor (see _Rep::_S_create) and obtain memory from
array_allocator: I cannot see anything wrong with this scheme on the
basic_string side. Also consider, that, because of this exact issue,
ext/array_allocator/2.cc would currently fail if char_type were changed
from char to wchar_t or whatelse != char: the troubles with
array_allocator's templated copy constructor are only latent.

I have tested the below on x86/x86_64/ia64-linux and will wait at least
until tomorrow for comments.

Paolo.

(*) In a nutshell this PR is about the strict alignment requirements on
some targets for memory involved in atomic operations.

//////////////////
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CL_19495
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20050515/b14db08e/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_19495
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20050515/b14db08e/attachment-0001.ksh>