This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Oct 2006 08:22:21 -0000
- Subject: [Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
- References: <bug-29286-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #23 from rguenth at gcc dot gnu dot org 2006-10-09 08:22 -------
One point to remember is that C does not allow re-using of storage with a
different type (which is what PR29272 is about and why that testcase is
invalid).
The storage type is either the declared one or the one assigned by virtue of
the
first assignment (or memcpy). So,
int i;
float f;
memcpy(&f, &i, sizeof(f));
is valid, it doesn't change fs dynamic type but assigns it the bit-pattern
of i.
What the C++ standard seems to imply is that the storage type of a bunch of
memory (or an object with automatic storage) changes on "assignment". So,
indeed for C++ re-ordering writes is not allowed, and escaping pointers
must be assumed to change dynamic type.
So for C++ and 4.2 the best solution looks like to disable type based aliasing
completely. For C I'm not sure the behavior the standard mandates is very
appealing - at least changing dynamic type via the use of memcpy should be
allowed as a GCC extension (like we allow type-punning via the union trick).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286