This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Mark Mitchell <mark at codesourcery dot com>, Richard Guenther <rguenther at suse dot de>, Richard Guenther <richard dot guenther at gmail dot com>, Paolo Bonzini <bonzini at gnu dot org>, gcc-patches at gcc dot gnu dot org, Diego Novillo <dnovillo at google dot com>
- Date: Tue, 2 Feb 2010 08:42:06 -0600
- Subject: Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding
- References: <alpine.LNX.firstname.lastname@example.org> <4B5ABF96.email@example.com> <firstname.lastname@example.org> <4B5AF989.email@example.com> <firstname.lastname@example.org> <4B5C8C89.email@example.com> <alpine.LNX.firstname.lastname@example.org> <4B5CE256.email@example.com> <firstname.lastname@example.org> <email@example.com>
On Tue, Feb 2, 2010 at 7:58 AM, Florian Weimer <firstname.lastname@example.org> wrote:
> * Gabriel Dos Reis:
>> On Sun, Jan 24, 2010 at 6:14 PM, Mark Mitchell <email@example.com> wrote:
>>> In that case, I don't think that "following the standard" is a useful
>>> thing to try to do. ?"Fix the standard" might be useful, of course.
>>> But, as an implementor, I think we should do something sensible. ?I'm
>>> very bothered by the idea that:
>>> ?int i;
>>> ?int *p = &i;
>>> ?// something
>>> ?*p = 3;
>>> might be invalid. ?That seems very wrong.
>> I cannot find any text that says that if 'p' still points
>> to the storage of 'i', then the above is invalid.
> "something" could involve a placement new, then you're reusing the
> storage and the code turns invalid.
"something" could use placement new to construct a new int object, therefore
ending the lifetime of the previous object; yes. But, I believe you need at
the minimum to invoke some implementation-defined aspects/guarantees to
construct a float at 'p', and pretend that now 'i' is just a storage for float.
> I think C++ is simply not amenable to type-based alias analysis. 8-)
that would be against its spirit :-)