--- 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, wher
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-18 14:58
---
(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 bas
--- Comment #9 from pdimov at gmail dot com 2010-05-17 20:12 ---
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
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-05-17 19:17 ---
The first example I think does as there is no way to "transfer" the dynamic
type via the struct copy. The second one does not as the union still has a
field that is float and it is only unspecified behavior if you a
--- Comment #7 from pdimov at gmail dot com 2010-05-17 19:10 ---
(In reply to comment #6)
> Basically the middle-end sees this the same as
> int i = 1, j;
> float *p = new (&i) float(0.0);
> j = i;
> return *reinterpret_cast(&j);
> and you expect to return 0.0.
The int/float exa
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-17 15:57 ---
Basically the middle-end sees this the same as
int i = 1, j;
float *p = new (&i) float(0.0);
j = i;
return *reinterpret_cast(&j);
and you expect to return 0.0.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-17 15:50 ---
(In reply to comment #4)
> (In reply to comment #3)
> > The boost folks may be able to tell if they at any place copy a
> > function_buffer object via the assignment operator.
>
> It seems so. From Peter Dimov :
>
--- Comment #4 from maxime at altribe dot org 2010-05-17 13:10 ---
(In reply to comment #3)
> The boost folks may be able to tell if they at any place copy a
> function_buffer object via the assignment operator.
It seems so. From Peter Dimov :
> [...] after stepping through the code, i
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-17 09:44 ---
The boost folks may be able to tell if they at any place copy a
function_buffer object via the assignment operator.
I see they also have funny stuff like get_vtable() and are playing with
typeinfos.
--
rguenth a
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-17 09:39 ---
It's not a dup of PR42834 (but it might be the same issue as PR42832 which
was a libstdc++ bug or a frontend bug).
It happens to work on trunk, so it might also be a dup of PR43987 (though
unlikely), rather differen
10 matches
Mail list logo