This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Strenghten assumption about dynamic type changes (placement new)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Jason Merrill <jason at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 22 Jul 2014 15:54:35 +0200
- Subject: Re: Strenghten assumption about dynamic type changes (placement new)
- Authentication-results: sourceware.org; auth=none
- References: <20140702201805 dot GB15987 at kam dot mff dot cuni dot cz> <53B49446 dot 7090402 at redhat dot com> <20140708135023 dot GC27691 at kam dot mff dot cuni dot cz> <53C87213 dot 1050604 at redhat dot com> <20140718100335 dot GA7671 at kam dot mff dot cuni dot cz> <53CA76FF dot 8080101 at redhat dot com> <20140719154408 dot GA8665 at kam dot mff dot cuni dot cz> <CAFiYyc0hDA+9G+wBVkf8Gif8vsDdpvyf4r3X8P=7G-P=QaWwqQ at mail dot gmail dot com>
>
> As discussen during the Cauldron keeping some builtin doesn't help because
> you are not forced to access the newly created object via the pointer returned
> by the placement new. That is,
>
> template <T>
> struct Storage {
> char x[sizeof(T)];
> Storage() { new (x) T; }
> T& get() { return reinterpret_cast <T&> (x); }
> };
This indeed looks like sensible use of placement new...
>
> is valid (and used in this way in Boost - with a type different from 'char'
> to force bigger alignment).
This testcase with char replaced to long or other POD type is still fine for my analysis.
I would like to assume that once a polymorphic type is built at a given location, it can
not be changed to other, that is:
template <T>
struct Storage {
Q x;
Storage() { new (x) T; }
T& get() { return reinterpret_cast <T&> (x); }
};
Where both T and Q are polymorphic types. I think essentially aliasing rules
disallows this (for Q and T being different types at least, not sure if one
inherits other) because Q gets constructed and thus accessed. But it is sliperly
indeed, as whole concept of placement new.
I believe easiest way to go forward is to extend polymorphic_call_context to
also hold speculative information about outer type. In the cases I can detect
a dynamic type but can not prove it did not changed, I still can use the
speculative path. This is not perfect, but will improve code quality.
I am still hoping we can get sensible rules for placement new :)
Honza