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


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
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?

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

Paolo.


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