It's v7-> mainline merge time!

[Paolo Carlini <pcarlini at suse dot de>]

Hi everyone,

since mainline is again in Stage 1, naturally, and as we did for 4.1, we 
want to start as soon as possible on merges v7-> mainline of "safe", 
non-library-ABI breaking stuff. A lot of interesting stuff, indeed! My 
current plan would be proceeding as follows:

-1- Simplifications to the algorithms (i.e., plain versions delegating 
to the versions taking a binary predicate). I would leave out any 
algorithm also involved in the simulated move semantics work (only 
unique, I think).

-2- Simulated move semantics, basically as-is in the branch. The entire 
merging work can be split in the infrastructural bits (e.g., moveable.h, 
slt_construct.h, stl_uninitialized.h, testsuite), algorithms, trivial 
containers, vector and deque, testcases  as we go. I'm pretty sure the 
work is safe from the binary-compatibility point of view (or can be made 
so with minor tweaks): in the most complex case, vector and deque, in a 
nutshell, functions like, e.g., _M_insert_aux, _M_fill_insert, 
_M_range_insert, will use __move and become faster when moveable types 
are detected.

-3- As soon as Jason are Benjamin are done with the namespace 
association vs debug-mode vs swap issues (see libstdc++/24660 and older 
refs therein), we can finally enable a few move semantics tests in debug 
mode too.

-4- Finally, Option 3 in DR 431 for all the containers. This stuff is 
not in v7 yet, but I'm going to add it soon, in parallel with the merge 
work. I think it's badly needed in mainline too, because with move 
semantics we are going to use swap much more and we want it in very good 
shape. In fact, to my best knowledge, it's *the only* facility in the 
containers not ready for stateful allocators, i.e., we are just swapping 
the pointers (people in love with the word -broken- would likely say our 
container swaps are broken for stateful allocators). The only problem I 
can see, besides the fact that, strictly speaking, DR 431 is still Open, 
is that we are going to require swappability for the allocators used 
together with v3. Maybe Howard wants to add something about this in 
particular, I'm certainly ok with that. In any case, I would leave this 
part of the work at the end (say, 2 months from now), and in case we 
could even (not that I'm in favor, personally) implement Option 2. In 
fact, the *strict* requirement is having *any* consistent, stateful 
allocators aware, container swap.

At the moment, I don't have much more to say. If I don't ear objections, 
after the _M_get_Tp_allocator by ref thing, I will start as per the 
schedule, extracting patches, testing on a couple of targets, posting, 
as usual...

Thanks for the attention!
Paolo.