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:

> Hi,
> > Sure - it will get you aligned storage.  Still the question is
> > how you access that storage - the _Any_data way of using
> > *static_cast<_Tp*>(&_M_aligned_storage) wouldn't be any better.
> >
> > shared_ptr_base.h uses placement new (not strictly required for
> > the middle-end) on top of aligned_storage.  If such use ends up
> > being valid depends on that you only access the storage through
> > types that it was initialized with (with either placement new
> > or via a store of that type).  This is where either functional
> > or the C++ frontend gets it wrong right now.
> >   
> So, to summarize, do I understand correctly that the only safe way to
> use such kind of aligned storage facility is storing in it only a single
> type throughout its entire life? Then those casts are ok, what else

Yes if you consider 3.8/4 'A program may end the lifetime of any
object by reusing the storage which the object occupies ...'

So,

  int *p = &aligned;
  *p = 1;
  ... *p;
  float *q = &aligned;
  *q = 0.0;
  ... *q;

is ok - the store via *q ends the lifetime of the int object and
starts lifetime of a float object, but

  int *p = &aligned;
  *p = 1;
  ... *p;
  float *q = &aligned;
  ... *q;

invokes undefined behavior as an object of type int is alive in
the storage of aligned and you access it via an lvalue of type float.

> could get you data in and out? - but you can only write and read a
> single type. That would be a pretty strong requirement: to be honest,
> I'm not sure that all the code both old and new is already fine. Do you
> have evidence is not?

I don't have evidence.  I have evidence that we assign different
alias-sets to pointer-to-function types that appear to me as
compatible (though I didn't dive too deep into the standards to
verify that).

> If we cannot be 100% sure, for 4.5 we can add an attribute, right?

Yes, I think you could do

    template<typename _Tp>
      _Tp&
      _M_access()
      { typedef _Tp my_tp __attribute__((may_alias)); return 
*static_cast<my_tp*>(_M_access()); }

but that's not necesary with my proposed patch to alias.c.

Richard.


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