[Bug target/36861] [4.5/4.6 Regression] boost's compressed avl confuses GCC

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #39 from rguenther at suse dot de <rguenther at suse dot de> 2011-01-19 09:54:19 UTC ---
On Tue, 18 Jan 2011, igaztanaga at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
> 
> --- Comment #38 from Ion GaztaÃaga <igaztanaga at gmail dot com> 2011-01-18 19:15:22 UTC ---
> Thanks Richard for the detailed report. The fact is that the next standard is
> trying to support relative pointers for container implementations (much like
> Boost.Interprocess does), to be able to place containers in shared memory. In
> those cases the relative pointers stores the difference between "this" and the
> pointee, which is what boost::interprocess::offset_ptr does.

But then the pointer arithmetic will not cause the pointer to move
from one object to another - the object will be simply the shared memory
segment (which isn't statically allocated either) - that's perfectly
valid in C and C++ right now.

> It is certainly outside the standard right now and the standard won't include
> such "relative pointer" class, but it will require to container implementations
> to support them as allocator::pointer types. It would be important to find a
> way to use smart pointers, maybe with some existing annotation/attribute to
> avoid optimizing away that relative addressing, so that there is always away to
> compute the pointee address based on "this" + this->m_offset. It is also
> important to support smart pointers created on the stack pointing to global
> objects (temporaries, function arguments, etc.)
> 
> I know this is outside the bug, but it will be certainly a common question when
> using GCC and next standard containers. Thanks

The point with the case in question is that a pointer to a global
object is computed relative to the address _of an automatic variable_.
I hope no standard will ever allow that ;)  It might be a simple
oversight (and thus bug) in Boost AVL though.

If the object were a global one then you wouldn't trigger the particular
bug (though still GCC would conclude that the pointer is pointing to
that global object, which, when in statically allocated storage, can
still lead to "miscompilations").

Richard.