[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-18 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-18 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-17 Thread pdimov at gmail dot com
--- 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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-17 Thread pinskia at gcc dot gnu dot org
--- 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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-17 Thread pdimov at gmail dot com
--- 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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-17 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-17 Thread rguenth at gcc dot gnu dot org
--- 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 : >

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-17 Thread maxime at altribe dot org
--- 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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-17 Thread rguenth at gcc dot gnu dot org
--- 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

[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

2010-05-17 Thread rguenth at gcc dot gnu dot org
--- 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