Re: [boost] [move] GCC bug and aliasing questions

Subject: Re: [boost] [move] GCC bug and aliasing questions
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-06-20 17:12:09

On Wed, Jun 20, 2012 at 10:54 AM, Tr3wory <tr3w_at_[hidden]> wrote:

> Hi,
>
> Yesterday I started using Boost.Move in my project.
> On gcc I had the same problem like the guys here:
> http://lists.boost.org/Archives/boost/2011/07/184263.php
>
> Namely, I can't define the move constructor nor the assignment
> operators outside my class...
> After some time I managed to create a minimal example (19 lines) and
> sent a bug report to the gcc guys:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53725
>
> So far, so good.
>
> In the minimizing process I found something interesting: the problem
> vanishes if I remove the __may_alias__ attribute from the rv<> class.
> This got me thinking. Do we need this attribute at all?
>
> The problematic expression is this: (It's in macros normally placed
> inside a class, TYPE is the name of this class.)
> operator ::boost::rv<TYPE>&()
> {
>    return *static_cast< ::boost::rv<TYPE>*> (this);
> }
>
> But rv<TYPE> is derived from TYPE so to me it looks like the two type
> is compatible, therefore the code didn't violate the strict aliasing
> rules, so the attribute is not necessary.
> (BTW can we violate the strict aliasing rules trough static_cast if we
> don't do any chained conversion trough void*?)
>
> On the other hand, if it's really breaks the rules then we solved the
> problem for gcc, but we still have undefined behavior on every other
> compiler.
>
> Can we fix this somehow?
>

I don't know, but +1 for bringing up this issue; there was another GCC bug
I filed not long ago involving the __may_alias__ attribute:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53421

I'm leaning toward agreeing with you on the strict aliasing question but
I'm no expert :(

- Jeff