Standard libraries may (libstdc++ in particular) forbid direct use of
assert()/<cassert> in library code.
Differential Revision: https://reviews.llvm.org/D60249
https://reviews.llvm.org/D74123
The fix affects follow algorithms:
remove_if, unique, rotate, inplace_merge, partial_sort_copy, set_union, set_intersection, set_difference, set_symmetric_difference.
For "is_trivial" types there are no problems with "creating objects/clean-up"
For non-trivial types the algo results are also correct, but possible incorrect copying/moving "operator=" calls "by raw memory" within one of mentioned algo or incorrect destructor calls in the end of algo.
Summary:
Some of the `move_` types were used with leading double-underscores, but
they were declared without `__` prefix.
This patch adds double-underscores to all `move_` types, and their uses.
Reviewers: MikeDvorskiy, ldionne, EricWF, rodgert, #libc
Reviewed By: MikeDvorskiy, ldionne, #libc
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D78040
It fixes an ambiguity issue in case of a user has a custom policy and
calls a version of exclusive_scan with binary operation.
Differential Revision: https://reviews.llvm.org/D62719
When one of sub-ranges has not been move constructed into a raw buffer, we should not call clean up for that sub-range. Instead of store detailed info about raw buffer history, the fix does the cleanup a sub-range after each moving the sub-range back.
https://reviews.llvm.org/D73779
Like we do in libc++, PSTL needs the ability to constrain
ABI-unstable symbols to each translation unit. This is OFF by
default (like for libc++), because most people don't care about
this and there is a cost associated to enabling the option (code
bloat because templates are not deduped across TUs).
I'm using '#pragma clang attribute push' to avoid marking each
declaration with an attribute, which quickly becomes difficult
to maintain.
llvm-svn: 368684
It makes more sense to name configuration options as PSTL_XXX.
Also, I'm naming it PSTL_PARALLEL_BACKEND because we might introduce
the ability to customize the vectorization backend, in which case
PSTL_BACKEND would become ambiguous.
llvm-svn: 368672
Instead of silently falling back to the serial backend, it's better if
we fail loudly when the parallel backend is left unspecified. Since we
have a __pstl_config_site header, a backend should always be specified.
llvm-svn: 368285
This commit adds a __pstl_config_site header that contains the value of
macros specified at CMake configuration time. It works similarly to
libc++'s __config_site header, except we always include it as a separate
file instead of concatenating it to the main configuration header.
It is necessary to thread the includes for that header into libc++'s
lit configuration, otherwise we'd be requiring an installation step
prior to running the test suite.
llvm-svn: 368284
For the few (currently four) headers that make up the PSTL's interface
to other Standard Libraries, provide a stable uglified header file that
can be included by those Standard Libraries.
We can then more easily change the internal organization of the PSTL
without having to change the integration with Standard Libraries.
llvm-svn: 368088
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 367903
Previously the code used "using namespace __pstl;" at block
scope to introduce these names. This could cause conflicts with
names defined by the standard library. So we should fully qualify
them instead.
llvm-svn: 367468
This reverts r366593, which caused unforeseen breakage on the build bots.
I'm reverting until the problems have been figured out and fixed.
llvm-svn: 366603
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
Reviewers: rodgert, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 366593
Also, use a single point of customization to set what namespace __par_backend
"points to", which provides a better separation of concerns.
llvm-svn: 365337
This is a stopgap measure to make it easier to integrate the PSTL into
libc++. In the future, we should have a system similar to what libc++
does, where we specify settings at configuration time and generate a
__config_site header that is part of the PSTL.
llvm-svn: 363958
Mostly unused parameter, unused local typedefs and shadowed declarations.
This massaging it necessary if we want to be able to run the tests under
the libc++ lit configuration.
llvm-svn: 363872
Summary:
A modification of the parallel sorting algorithm, additionally optimized for a partially sorted array.
Reviewers: rodgert
ldionne
Differential Revision: https://reviews.llvm.org/D59925
llvm-svn: 362678
- unused parameter warnings
- don't use single-letter template parameter names, like we do in libc++
- sign-comparison warnings
- unused variables in the tests
- unused local typedefs in the tests
- the use of #include_next
- field reordering in the tests
- unused lambda captures
Note that the rationale for why the static_casts to unsigned are OK is
that last - first must always be non-negative, since [first, last) is
a valid range.
llvm-svn: 362148
Thomas Rodgers