This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding


On Thu, 4 Feb 2010, Gabriel Dos Reis wrote:

> On Thu, Feb 4, 2010 at 7:56 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> > Hi,
> >>> About this, just wanted to point out that in Pittsburgh this paper will
> >>> be discussed again
> >>>
> >>> ?http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2981.pdf
> >>>
> >>> whereas in Santa Cruz concerns have been raised exactly about those
> >>> placement new of subobjects vs aliasing. In my opinion the proposed
> >>> solution to the long standing issue with std::pair is otherwise very
> >>> nice and I would really encourage you to check it vs aliasing...
> >>>
> >> I missed the Santa Cruz meeting. ?What was the concerns about aliasing?
> >>
> > I don't remember the details, but essentially Doug was afraid that the
> > scheme you can still see at the beginning of the Proposed Wording
> > (remnant of the previous version) could not be completely safe wrt
> > aliasing: nobody in the room could really confirm or deny that and the
> > discussion stalled. Lately, I think I read on the reflector that Pablo
> > has hopes it is safe, actually. Some input would be definitely welcome,
> > I think.
> 
> I would be more than glad to provide input.
> However, I do not see what the aliasing issue could possibly be.
> As far as I can tell, storage is obtained and is used to
> construct each sub-component of the pair in distinct sub-storage.
> I do not see what the  aliasing issue could possibly be.  If you can
> ask Doug to
> clarify his statements, that would help.  Otherwise, I would just declare
> there is no issue :-)

I conclude from the removed text on the bottom of Page 3 that

 1) pair is not generally POD
 2) T1 and T2 in pair<T1,T2> do not have to be POD

now, constructing a pair like (simplified)

  pair<X, Y> *p = ::operator new(sizeof(pair<X,Y>));
  ::new (&p->first) X(...);
  ::new (&p->second) Y(...);

will make

  pair<X, Y> *p2 = ::operator new(sizeof(pair<X,Y>));
  *p2 = *p;

have the same problem as our example with POD unions.
Unless of course pair<X, Y> implements proper
operator overloads to turn the assignment into
basically

  memcpy (&p2, &p, sizeof(pair<X,Y>));

with all the fun that arises and complicates matters if
X and/or Y are not POD and thus not eligible to be
copied via memcpy.

Thus, if pair<X,Y> ensures that copies are done either
with lvalues of type X and Y or via memcpy things
should be fine.

Well, fine with GCC at least.

Richard.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]