Improve safe iterator move semantic

[François Dumont]

On 10/08/2018 13:26, Ville Voutilainen wrote:
> On 10 August 2018 at 13:47, Jonathan Wakely <jwakely@redhat.com> wrote:
>> Doing a test like this with TSan should be the absolute minimum
>> required for any change to the mutex locking policy.
> Agreed. Concurrency code is something that our test suite is not
> well-equipped to test (because
> it doesn't support TSan and such yet), so it would seem prudent to
> stress-test such patches
> via testsuite-external means.

Yes, sorry about that, I am over confident in the testsuite indeed.

And I also totally forgot this use case of 2 threads playing with 
iterators on the same container. So I didn't even try to find out if any 
test could be good to simulate it.

Now, considering this episode, I am incline to just delete safe iterator 
move semantic. I might propose a patch to do so later.

>
>> I'm not aware of people complaining about the performance of debug
>> mode anyway. Everybody I speak to is happy to accept a performance hit
>> in order to get checking.
Good to know, I just hope you will accept one more patch regarding 
another performance hint of debug mode when using deque::iterator.
> Yep; while it's nice to have performance improvements in debug mode,
> there are probably more
> important and significant ways to improve it..
>
>> I think https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843 would be
>> more helpful to our users, as it would allow some Debug Mode checks to
>> be enabled in programs that can't currently use it (because
>> recompiling the entire program is not possible).
> ..like this one, which would be a major usability improvement.
>
I'll consider this one, but I fear not for gcc 9.0.

François