[boost] [move] GCC bug and aliasing questions

Subject: [boost] [move] GCC bug and aliasing questions
From: Tr3wory (tr3w_at_[hidden])
Date: 2012-06-20 13:54:20

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?

Cheers,
tr3w