Re: Strict aliasing plus placement new / explicit destructor call

[Justin Lebar <justin dot lebar at gmail dot com>]

> It's hard to say without knowing exactly which version of the compiler is being used.

Of course.  I'm using GCC 4.4.3-4ubuntu5.

> Even [if there are warnings], the code tends to
> work as expected if the object is uninitialized and every access to the
> object use the same incorrect type, as seems to be the case here.

Indeed.  But although my primary concern is, of course, that the
program runs correctly, I'm also concerned about eliminating these
warnings altogether, preferably on all versions of GCC that Mozilla
supports.  I want to turn on -Werror=strict-aliasing -- otherwise, I'm
afraid that people will introduce aliasing errors which tickle GCC
into generating incorrect code without even noticing.

I'm surprised that everyone here is in agreement that the code I
posted obeys the strict aliasing rules.  My understanding -- and
perhaps this is totally wrong -- is that the "may alias" relation
isn't transitive.  That is, although char* may alias anything, T* may
not alias char*.  Perhaps this explains the error I'm getting.

For now, I've just modified the construct() call to save the pointer
returned by placement new.  (Which is, of course, the same pointer it
was passed!  At least, it is in the real code, where we make sure that
the storage is aligned.)  It seems a bit silly to me to do this,
though.  If there's a cleaner way to modify the code to quiet up the
warnings, I'd be curious to hear it.

-Justin

On Wed, Jul 28, 2010 at 2:27 AM, Ian Lance Taylor <iant@google.com> wrote:
> Andrew Haley <aph@redhat.com> writes:
>
>> On 07/28/2010 06:57 AM, Ian Lance Taylor wrote:
>>> Justin Lebar <justin.lebar@gmail.com> writes:
>>>
>>>> I'm trying to enable -fstrict-aliasing when building Firefox. ?One
>>>> class in particular is proving difficult to make work properly. ?We
>>>> use this class for lazily allocating objects on the stack.
>>>>
>>>> Code is included at the end of this e-mail. ?When I compile with -O2
>>>> -Wall, I get
>>>>
>>>> ? ?main.cpp:20: warning: dereferencing pointer ‘this.0’ does break
>>>> strict-aliasing rules
>>>>
>>>> It seems that this warning is due to the cast in ~Lazy(). ?Note that I
>>>> can't rewrite Lazy<T>'s storage as a union because T may have a
>>>> constructor -- the whole purpose of the Lazy class is to let me
>>>> stack-allocate T without immediately calling its constructor.
>>>>
>>>> Also, changing
>>>>
>>>> ? ? ? T* obj = reinterpret_cast<T*>(bytes);
>>>>
>>>> to
>>>>
>>>> ? ? ? T* __attribute__((may_alias)) obj = reinterpret_cast<T*>(bytes);
>>>>
>>>> doesn't eliminate the warning.
>>>>
>>>> I'm out of ideas. ?Is there a way to accomplish what I'm trying to do
>>>> here without disabling strict aliasing? ?I'd hate to give up now.
>>>
>>> Your code looks OK to me by the C++ aliasing rules--at least it would
>>> look OK if your program actually called construct. ?In this case I think
>>> the warning is incorrect. ?Current mainline does not seem to give that
>>> warning.
>>
>> Yes, the code looks OK to me too. ?My worry is that incorrect alias
>> analysis may result in incorrect code being generated. ?But perhaps
>> there's nothing to worry about because the warning is independent of
>> the alias analysis used by the compiler.
>
> That's a good point. ?It's hard to say without knowing exactly which
> version of the compiler is being used. ?For some versions of the
> compiler, some of the aliasing warnings are based on the same
> information that the alias analysis uses. ?Even then, the code tends to
> work as expected if the object is uninitialized and every access to the
> object use the same incorrect type, as seems to be the case here. ?That
> is, the compiler does not typically discard accesses to memory which use
> the wrong type; the problems arise when the same memory is accessed via
> two different types, as the compiler does not attempt to keep those
> accesses in order.
>
> Ian
>