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.
