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

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi again,

and thanks for spending some time discussing these things, I appreciate
that.
> 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.
>   
Excellent. I think I finally understand these issues much better.
Therefore, it seems to me, it's a bit weaker than I feared, that is: you
do *not* have to use the buffer with a single type throughout its
lifetime, you can use it with any number of types, but such uses cannot
*overlap*. You write a new type, forget about the old one, and can
safely go ahead. You understand, that makes a *huge* difference for our
applications, because in that case we can safely have one such "any"
data member, use it to store different kinds of data, and provided we do
not overlap such uses, we are fine.
>> 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).
>   
Ok...
>> 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.
>   
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. I guess we have a few days to take the final decision...

Paolo.