Re: [pooma-dev] Problems with domain iterators

[Richard Guenther]

Richard Guenther wrote:
> All domain iterators contain
>
>   inline const Value_t &operator*() const
>
> which return references to possibly temporary objects.  This is nasty and
> not what iterators are supposed to do.  We get miscompiled code dependend
> on compiler versions and stack layout.  Ugh.  It's easy to avoid the above
> (just return a copy), but what to do with
>
>   // Member selection operator. Allows calling const Loc
>   // member functions. Not too useful, but it is part of
>   // the required input iterator interface.
>
>   inline const Value_t *operator->() const
>
> not the comment - what is "the required input iterator interface"?  Where
> is it defined?  If it is the STL input iterator definition, I cannot find
> any sign of required operator->() there.  Referencing the definition, an
> input iterator _may_ be mutable, and looking into the Trivial Iterator
> definition, it also _may_ be dereferencable, but must not be.
>
> So I guess we should drop operator->() from the domain iterators and
> return copies for operator*() const.
>
> Other ideas?

Ok, the problem seems rather that POOMA domain iterators are not like 
STL iterators at all.  So we shouln't try to mix them like we do in
Utilities/algorithms:delete_backfill where we use std::reverse_iterator
on IntervalIterator.  This ends up returning references to temporary 
objects because of the way STL iterators are ment to be constructed.  In 
contrast to the POOMA domain iterators dereferencing them leads to 
storage separate from the iterator and with possibly different (longer) 
lifetime.  This is not the way it works with the POOMA iterators.

So we need to rip out the use of STL iterators (and possibly algorithms)
or try to very clever rework our iterators (I don't have constructive 
ideas here).

For reference, this mess turned up because of gcc PR 
rtl-optimization/14863 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14863).

So, how was this thought to work?

Richard.