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

["rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.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 :
> 
> > [...] after stepping through the code, it turns out that function_buffer is
> > indeed assigned directly, due to the fact that __has_trivial_copy and
> > __has_trivial_destructor report true for the stored function object.

Which means that it is either a C++ frontend bug not protecting this
aggregate assignment properly or a bug in Boost as the functor type stored
to function_buffer is not a member of the union.  The functor types
are for example seen in

            const functor_type* in_functor =
              reinterpret_cast<const functor_type*>(&in_buffer.data);
            new ((void*)&out_buffer.data) functor_type(*in_functor);

but functor_type (a template param) is not a member of said union.

People were arguing that the char member in the union should make this
valid, but nothing in the C++ frontend communicates that to the
alias analysis stage.  People also were arguing only a character
array member would qualify, possibly covering the whole union in size.

A workaround for boost can be constructed following the fix for PR42832.
Due to an unrelated bug using memcpy for the assingment won't work.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2010-05-17 09:39:31         |2010-05-17 15:50:41
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164