http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
--- Comment #16 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-07-08
11:01:06 UTC ---
I believe I'm making good progress in analyzing, thus fixing, the issue with
inplace_merge: what I see clearly now is that - as noticed in Comment 9 for the
first time - __move_merge, for the purpose of __merge_adaptive, can be safely
changed to simply end with:
return _GLIBCXX_MOVE3(__first1, __last1, __result);
and the self-move assignment issue is solved. The reason being that when the
main while loop is exited with __first2 != __last2, __first2 always points to
the same position pointed by __result: indeed, in the case of inplace_merge the
overall source and destination ranges coincide and nothing else is possible.
However, __move_merge is also used by __merge_sort_loop, where different
assumptions hold. I don't know at the moment if we can do something better than
just specializing __move_merge for __merge_adaptive per the above.
Also, remains to be analyzed the *_backward case.
Chris, any help is welcome.
