------- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-18 15:00
-------
(In reply to comment #10)
> (In reply to comment #9)
> > But the standard says in [basic.types] that "For any trivially copyable
> > type T,
> > if two pointers to T point to distinct T objects obj1 and obj2, where
> > neither
> > obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7)
> > making
> > up obj1 are copied into obj2,40 obj2 shall subsequently hold the same value
> > as
> > obj1."
>
> Yep. But an assignment is not a byte-copy and exactly the assignment is
> what invokes the undefined behavior (not the subsequent access).
>
> So,
>
> struct X
> {
> char data[ sizeof( float ) ];
> };
>
> int main()
> {
> X x1;
> new( &x1.data ) float( 3.14f );
>
> X x2 = x1;
>
>
> GCC sees this as reading the float object you made live in x1.data via
> an lvalue of type X and thus decides that the float object is unused
> and removes it.
Oh, and
"float" is a trivially copyable type. Copying X results in copying the bytes
of
X::data (because the default copy constructor of a class does a memberwise
copy, and the default copy constructor of an array does an elementwise copy).
Therefore, the underlying bytes of the object of type float, initialized at
x1.data, are copied into x2.data, which then must, if interpreted as a float,
hold the same value as the original object.
is not what the C++ frontend does. It emits the assignment literally:
<<cleanup_point <<< Unknown tree: expr_stmt
(void) (x2 = TARGET_EXPR <D.21180, x1>) >>>
>>;
gimplified to
x2 = x1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
