http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48559
Summary: parallel-mode vs C++0x
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com
A number of parallel algorithms assumes CopyConstructible and/or
CopyAssignable, whereas in the new standard only MoveConstructible and/or
MoveAssignable are required (eminent case, std::sort). Indeed, at the moment we
have to run the following in normal-mode:
random_shuffle/moveable.cc:24:#undef _GLIBCXX_PARALLEL
nth_element/moveable.cc:27:#undef _GLIBCXX_PARALLEL
partial_sort/check_compare_by_value.cc:26:#undef _GLIBCXX_PARALLEL
partial_sort/moveable.cc:27:#undef _GLIBCXX_PARALLEL
partition/moveable.cc:27:#undef _GLIBCXX_PARALLEL
stable_sort/moveable2.cc:26:#undef _GLIBCXX_PARALLEL
stable_sort/check_compare_by_value.cc:26:#undef _GLIBCXX_PARALLEL
stable_sort/moveable.cc:26:#undef _GLIBCXX_PARALLEL
sort/check_compare_by_value.cc:26:#undef _GLIBCXX_PARALLEL
sort/moveable.cc:27:#undef _GLIBCXX_PARALLEL
for_each/1.cc:24:#undef _GLIBCXX_PARALLEL
(see also next_permutation/moveable.cc and prev_permutation/moveable.cc about
std::lexicographical_compare)
We have to fix this.
An option would be conditionalizing the parallel versions on
std::is_copy_constructible and/or std::is_copy_assignable being true. But those
traits are not available yet. We could conservatively use for now the trivial
version, which maybe is too conservative, however.
Much more elegant would be tweaking the algorithms themselves to not use
copies, just moves, as the serial versions do. I have no idea whether this is
feasible, for at least *some* of the algorithms...
