This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix libstdc++/C++ fallout from RTL alias export


On Wed, 20 Jan 2010, Paolo Carlini wrote:

> On 01/20/2010 05:42 PM, Paolo Carlini wrote:
> > Good that we have a plan B. So, let's keep obviously in touch, if you
> > come to the conclusion that such change penalizes too much the
> > optimization of common cases in user code or we, library people, cannot
> > guarantee that we are using such buffers in the right way, we can still
> > add the attribute.
> >   
> The above should be and AND of course, not an OR ;)

Like

  D.12950_92 = (struct _Simple_type_wrapper *) 
&D.12951.D.8815._M_functor._M_pod_data[0];
  *D.12950_92 = D.12949;
  __old_functor = D.12951.D.8815._M_functor;

where it stores a struct _Simple_type_wrapper into _M_pod_data and
then reads from it via a union _Any_data type.

Generated from tr1::function::swap.  Looks innocent but in reality
isn't:

      void swap(function& __x)
      {
        _Any_data __old_functor = _M_functor;
        _M_functor = __x._M_functor;

because you are effectively doing

  int a, b;
  *(float *)&a = 0.0;
  b = a;

and expect the read from a to conflict with the earlier store.
BUT - the type of the lvalue 'a' is int and you are not allowed
to access an object with effective dynamic type float via it.

In the struct case it gets of course less obvious.  In functional you
do

 struct Data {
   char mem[...];
 } a, b;

 *(T *)&a.mem[0] = ...;
 b = a;

but with the same argument this fails.  An aggregate copy
is _not_ like memcpy as far as type based aliasing goes!

So a fixed swap() would be using memcpy.  Or a fixed _Any_data
would return ref-all pointers.

Fun.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]