On 31/01/19 21:08 -0800, Thomas Rodgers wrote:
Update C++17 parallel algorithms to LLVM/MIT licensed upstream sources
Some lines in bits/c++config.h need to be split before 80 columns
(with a backslash if the split is in the middle of a preprocessor
condition obviously).
There are loads of very long lines in the actual PSTL headers too, but
I think we need to keep them similar to the upstream headers to aid
merging, so can't gratuitously reformat them. I'm assuming that
doesn't apply to <bits/c++config.h> since that's our header and any
changes will need to be manually applied anyway, right?
We'll need to add a copy of the LICENSE.TXT file to our sources, since
it's referred to by the comments at the top of each PSTL file.
Typo in include/Makefile.am: ${pstl_srcdir}/memoy_impl.h
(Which will require regenerating include/Makefile.in).
The __cpp_lib_parallel_algorithm macro needs to be (conditionally)
defined in <version> as well as <algorithm> and <numeric>.
The namespaces par_backend and unseq_backend need to be uglified.
ALL the names in the __pstl::internal namespace need to be uglified:
brick_any_of
pattern_any_of
for_each_n_it_serial
brick_walk1
pattern_walk1
etc.
I see quite a few calls to functions that should probably be qualified
to prevent ADL, but that can be fixed later (and upstream first):
return brick_count(...
return except_handler([&]() { ...
The DejaGnu directives in the pstl tests need to be in this order:
// { dg-options "-std=gnu++17 -ltbb" }
// { dg-do run { target c++17 } }
// { dg-require-effective-target tbb-backend }
Currently the dg-require-effective-target comes before the dg-do
line, so doesn't work. DejaGnu processes the lines in order. When it
sees the dg-do for target c++17 it overrides the effect of any earlier
dg-require-effective-target.
I fixed that locally like so:
find testsuite/20_util/specialized_algorithms/pstl/
testsuite/25_algorithms/pstl/ testsuite/26_numerics/pstl/ -name \*.cc | xargs
sed -i '/dg-require-eff/{h;d};/dg-do/{p;x}'
And now I don't get FAIL results on a system with no TBB installed
(which is great). I also get no FAIL results on a system with TBB
installed (also great).
There are two copies (with slight differences) of each of the
uninitialized_xxx tests:
libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/specialized.algorithms/uninitialized_construct.cc
| 128 +++++++
libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/specialized.algorithms/uninitialized_copy_move.cc
| 143 ++++++++
libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/specialized.algorithms/uninitialized_fill_destroy.cc
| 103 ++++++
libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_construct.cc
| 132 ++++++++
libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc
| 154 +++++++++
libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_fill_destroy.cc
| 104 ++++++
That's all for now, but I'll keep making passes over it, going into
more detail ...
