In previous standards it is undefined for a container and its allocator
to have a different value_type. Libstdc++ has traditionally allowed it
as an extension, automatically rebinding the allocator to the
container's value_type. Since GCC 8.1 that extension has been disabled
for C++11 and later when __STRICT_ANSI__ is defined (i.e. for
-std=c++11, -std=c++14, -std=c++17 and -std=c++2a).
Since the acceptance of P1463R1 into the C++2a draft an incorrect
allocator::value_type now requires a diagnostic. This patch implements
that by enabling the static_assert for -std=gnu++2a as well.
* doc/xml/manual/status_cxx2020.xml: Document P1463R1 status.
* include/bits/forward_list.h [__cplusplus > 201703]: Enable
allocator::value_type assertion for C++2a.
* include/bits/hashtable.h: Likewise.
* include/bits/stl_deque.h: Likewise.
* include/bits/stl_list.h: Likewise.
* include/bits/stl_map.h: Likewise.
* include/bits/stl_multimap.h: Likewise.
* include/bits/stl_multiset.h: Likewise.
* include/bits/stl_set.h: Likewise.
* include/bits/stl_vector.h: Likewise.
* testsuite/23_containers/deque/48101-3_neg.cc: New test.
* testsuite/23_containers/forward_list/48101-3_neg.cc: New test.
* testsuite/23_containers/list/48101-3_neg.cc: New test.
* testsuite/23_containers/map/48101-3_neg.cc: New test.
* testsuite/23_containers/multimap/48101-3_neg.cc: New test.
* testsuite/23_containers/multiset/48101-3_neg.cc: New test.
* testsuite/23_containers/set/48101-3_neg.cc: New test.
* testsuite/23_containers/unordered_map/48101-3_neg.cc: New test.
* testsuite/23_containers/unordered_multimap/48101-3_neg.cc: New test.
* testsuite/23_containers/unordered_multiset/48101-3_neg.cc: New test.
* testsuite/23_containers/unordered_set/48101-3_neg.cc: New test.
* testsuite/23_containers/vector/48101-3_neg.cc: New test.
From-SVN: r271866
The status of P1353R0 was "Partial" because we don't define the
__cpp_lib_three_way_comparison macro, but that's because we don't
support the feature. So the paper can be marked as done.
* doc/xml/manual/status_cxx2020.xml: Add feature-test macro for
P0811R3. Change status of P1353R0.
* doc/html/*: Regenerate.
From-SVN: r271774
* doc/xml/manual/status_cxx2011.xml: Use <variablelist> for
documentation of implementation-defined types for [thread.req.native].
* doc/xml/manual/status_cxx2017.xml: Update documentation of
implementation-defined strings for [variant.bad.access]. Fix typo in
documentation of implementation-defined support for [fs.conform.9945].
* doc/html/*: Regenerate.
From-SVN: r271773
Add support for additional sources of randomness to std::random_device,
to allow using RDSEED for Intel CPUs and rand_s for Windows. When
supported these can be selected using the tokens "rdseed" and "rand_s".
For *-w64-mingw32 targets the "default" token will now use rand_s, and
for other i?86-*-* and x86_64-*-* targets it will try to use "rdseed"
first, then "rdrand", and finally "/dev/urandom".
To simplify the declaration of std::random_device in <bits/random.h> the
constructors now unconditionally call _M_init instead of _M_init_pretr1,
and the function call operator now unconditionally calls _M_getval. The
library code now decides whether _M_init and _M_getval should use a real
source of randomness or the mt19937 engine.
Existing code compiled against old libstdc++ headers will still call
_M_init_pretr1 and _M_getval_pretr1, but those functions now forward to
_M_init and _M_getval if a real source of randomness is available. This
means existing code compiled for mingw-w64 will start to use rand_s just
by linking to a new libstdc++.dll.
* acinclude.m4 (GLIBCXX_CHECK_X86_RDSEED): Define macro to check if
the assembler supports rdseed.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_CHECK_X86_RDSEED.
* config/os/mingw32-w64/os_defines.h (_GLIBCXX_USE_CRT_RAND_S): Define.
* doc/html/*: Regenerate.
* doc/xml/manual/status_cxx2011.xml: Document new tokens.
* include/bits/random.h (random_device::random_device()): Always call
_M_init rather than _M_init_pretr1.
(random_device::random_device(const string&)): Likewise.
(random_device::operator()()): Always call _M_getval().
(random_device::_M_file): Replace first member of union with an
anonymous struct, with _M_file as its first member.
* src/c++11/random.cc [_GLIBCXX_X86_RDRAND] (USE_RDRAND): Define.
[_GLIBCXX_X86_RDSEED] (USE_RDSEED): Define.
(USE_MT19937): Define if none of the above are defined.
(USE_POSIX_FILE_IO): Define.
(_M_strtoul): Remove.
[USE_RDSEED] (__x86_rdseed): Define new function.
[_GLIBCXX_USE_CRT_RAND_S] (__winxp_rand_s): Define new function.
(random_device::_M_init(const string&)): Initialize new union members.
Add support for "rdseed" and "rand_s" tokens. Decide what the
"default" token does according to which USE_* macros are defined.
[USE_POSIX_FILE_IO]: Store a file descriptor.
[USE_MT19937]: Forward to _M_init_pretr1 instead.
(random_device::_M_init_pretr1(const string&)) [USE_MT19937]: Inline
code from _M_strtoul.
[!USE_MT19937]: Call _M_init, transforming the old default token or
numeric tokens to "default".
(random_device::_M_fini()) [USE_POSIX_FILE_IO]: Use close not fclose.
(random_device::_M_getval()): Use new union members to obtain a
random number from the stored function pointer or file descriptor.
[USE_MT19937]: Obtain a value from the mt19937 engine.
(random_device::_M_getval_pretr1()): Call _M_getval().
(random_device::_M_getentropy()) [USE_POSIX_FILE_IO]: Use _M_fd
instead of fileno.
[!USE_MT19937] (mersenne_twister): Do not instantiate when not needed.
* testsuite/26_numerics/random/random_device/85494.cc: New test.
From-SVN: r271740
* doc/xml/manual/evolution.xml: Document LWG DR 2921 change.
* doc/xml/manual/intro.xml: Likewise.
* include/std/future (__create_task_state): Add default arguments
to make providing an allocator optional.
(packaged_task::packaged_task(F&&)): Call __create_task_state directly
instead of delegating to another constructor.
(packaged_task::packaged_task(allocator_arg_t, const A&, ...)): Do not
define allocator-extended constructors for C++17 and later.
* testsuite/30_threads/packaged_task/cons/alloc.cc: Only run test for
C++11 and C++14.
* testsuite/30_threads/packaged_task/cons/alloc2.cc: Likewise.
* testsuite/30_threads/packaged_task/cons/alloc_min.cc: Likewise.
* testsuite/30_threads/packaged_task/uses_allocator.cc: Likewise.
From-SVN: r271582
This type is not a conforming allocator, because it cannot be reliably
rebound to allocate for a different type. The result of the rebind
transformation still uses the same underlying std::tr1::array<T, 1>
array, which may not be correctly aligned or even have elements the
right size for the value_type of the rebound allocator.
It has been deprecated for several years and should now be removed.
* doc/xml/manual/allocator.xml: Remove documentation for
array_allocator.
* doc/xml/manual/evolution.xml: Document array_allocator removal.
* doc/xml/manual/using.xml: Remove header from documentation.
* include/Makefile.am: Remove <ext/array_allocator.h> header.
* include/Makefile.in: Regenerate.
* include/ext/array_allocator.h: Remove.
* include/precompiled/extc++.h: Do not include removed header.
* testsuite/ext/array_allocator/1.cc: Remove.
* testsuite/ext/array_allocator/2.cc: Remove.
* testsuite/ext/array_allocator/26875.cc: Remove.
* testsuite/ext/array_allocator/3.cc: Remove.
* testsuite/ext/array_allocator/check_deallocate_null.cc: Remove.
* testsuite/ext/array_allocator/check_delete.cc: Remove.
* testsuite/ext/array_allocator/check_new.cc: Remove.
* testsuite/ext/array_allocator/variadic_construct.cc: Remove.
* testsuite/ext/headers.cc: Do not include removed header.
From-SVN: r271119
This change ensures that std::common_type<> is a complete type (LWG
2408), and that std::common_type<T>, std::common_type<cv T1, cv T2>, and
std::common_type<T1, T2, R...> will use program-defined specializations
for std::common_type<T1, T2> (LWG 2465).
The implementation of common_type<T1, T2, R...> is changed to use
void_t, and the specializations for duration and time_point are modified
to also use void_t instead of depending on implementation details of
common_type.
PR libstdc++/89102
* doc/xml/manual/intro.xml: Document DR 2408 and 2465 changes.
* include/std/chrono (__duration_common_type_wrapper): Replace with ...
(__duration_common_type): New helper.
(common_type<chrono::duration<R1, P2>, chrono::duration<R2, P2>>): Use
__duration_common_type.
(__timepoint_common_type_wrapper): Replace with ...
(__timepoint_common_type): New helper.
(common_type<chrono::time_point<C, D2>, chrono::time_point<C, D2>>):
Use __time_point_common_type.
* include/std/type_traits (common_type<>): Define, as per LWG 2408.
(__common_type_impl): If either argument is transformed by decay,
use the common_type of the decayed types.
(__common_type_impl<_Tp, _Up, _Tp, _Up>): If the types are already
decayed, use __do_common_type_impl to get the common_type.
(common_type<_Tp>): Use common_type<_Tp, _Tp>.
(__do_member_type_wrapper, __member_type_wrapper)
(__expanded_common_type_wrapper): Remove.
(__common_type_pack, __common_type_fold): New helpers.
(common_type<_Tp, _Up, _Vp...>): Use new helpers instead of
__member_type_wrapper and __expanded_common_type_wrapper.
* testsuite/20_util/common_type/requirements/explicit_instantiation.cc:
Test zero-length template argument list.
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Test single argument cases and argument types that should decay.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Adjust expected error.
* testsuite/20_util/duration/literals/range_neg.cc: Use zero for
dg-error lineno.
* testsuite/20_util/duration/requirements/typedefs_neg1.cc: Likewise.
* testsuite/20_util/duration/requirements/typedefs_neg2.cc: Likewise.
* testsuite/20_util/duration/requirements/typedefs_neg3.cc: Likewise.
From-SVN: r270987
PR libstdc++/90239
* doc/xml/manual/status_cxx2020.xml: Amend P0591R4 status.
* include/std/scoped_allocator [__cplusplus > 201703L]
(scoped_allocator_adaptor::construct): Define in terms of
uses_allocator_construction_args, as per P0591R4.
* testsuite/20_util/scoped_allocator/construct_pair_c++2a.cc: New test.
* testsuite/util/testsuite_allocator.h: Remove name of unused
parameter.
From-SVN: r270588
* doc/xml/faq.xml: Add information about emergency EH pool.
* doc/xml/manual/debug.xml: Update list of memory debugging tools.
Move outdated information on mt_allocator to a separate section.
* doc/xml/manual/evolution.xml: Clarify that GLIBCXX_FORCE_NEW
doesn't affect the default allocator.
From-SVN: r270264
The Doxygen docs do not have stable URLs, so linking to specific pages
doesn't work well.
* doc/xml/manual/backwards_compatibility.xml: Remove link to
Doxygen-generated pages with unstable URL.
* doc/xml/manual/concurrency_extensions.xml: Likewise.
* doc/xml/manual/extensions.xml: Likewise.
* doc/xml/manual/parallel_mode.xml: Likewise.
* doc/xml/manual/support.xml: Likewise.
From-SVN: r269881
* doc/xml/manual/allocator.xml: Link to table documenting evolution
of extension allocators.
* doc/xml/manual/evolution.xml: Use angle brackets for header names.
Document new headers in 7.2, 8.1 and 9.1 releases.
* doc/xml/manual/using.xml: Adjust link target for new_allocator.
* doc/html/*: Regenerate.
From-SVN: r269794
Because uses-allocator construction is invariably done with a const
lvalue the __uses_alloc helper should use a const lvalue for the
is_constructible checks. Otherwise, it can detect that the type can be
constructed from an rvalue, and then an error happens when a const
lvalue is passed to the constructor instead.
Prior to LWG DR 2586 scoped_allocator_adaptor incorrectly used an rvalue
type in the is_constructible check and then used a non-const lvalue for
the actual construction. The other components using uses-allocator
construction (tuple and polymorphic_allocator) have always done so with
a const lvalue allocator, although the use of __use_alloc in our
implementation meant they behaved the same as scoped_allocator_adaptor
and incorrectly used rvalues for the is_constructible checks.
In C++20 the P0591R4 changes mean that all uses-allocator construction
is defined in terms of the new uses_allocator_construction_args
functions, which always use a const lvalue allocator.
The changes in this patch ensure that the __use_alloc helper correctly
matches the requirements in the standard, consistently using a const
lvalue allocator for the is_constructible checks and the actual
constructor arguments.
* doc/xml/manual/intro.xml: Document LWG 2586 status.
* include/bits/uses_allocator.h (__uses_alloc): Use const lvalue
allocator type in is_constructible checks.
* testsuite/20_util/scoped_allocator/69293_neg.cc: Adjust dg-error.
* testsuite/20_util/scoped_allocator/dr2586.cc: New test.
* testsuite/20_util/tuple/cons/allocators.cc: Add test using
problematic type from LWG 2586 discussion.
* testsuite/20_util/uses_allocator/69293_neg.cc: Adjust dg-error.
* testsuite/20_util/uses_allocator/cons_neg.cc: Likewise.
From-SVN: r268882
This change is safe to make now (in stage 4), because the constructors
are currently incorrect and unusable (unless the supplied container
already contains a heap, in which case the new make_heap calls are
redundant but harmless).
* doc/xml/manual/intro.xml: Document LWG 2537 status.
* include/bits/stl_queue.h
(priority_queue(const Compare&, const Container&, const Alloc&))
(priority_queue(const Compare&, Container&&, const Alloc&)): Call
make_heap.
* testsuite/23_containers/priority_queue/dr2537.cc: New test.
From-SVN: r268878
Although there is no good use for stack<int, deque<double>> or similar
types with a mismatched value_type, it's possible somebody is doing that
and getting away with it currently. This patch only enforces the new
requirement for C++17 and later. During stage 1 we should consider
enforcing it for C++11 and C++14.
* doc/xml/manual/intro.xml: Document LWG 2566 status.
* include/bits/stl_queue.h (queue, priority_queue): Add static
assertions to enforce LWG 2566 requirement on value_type.
* include/bits/stl_stack.h (stack): Likewise.
From-SVN: r268877
This DR was already resolved for GCC 7.1 by the implementation of DR
2192, but we didn't have an explicit test for the behaviour that 2735
guarantees.
* doc/xml/manual/intro.xml: Document LWG 2735 status.
* include/bits/std_abs.h: Add comment about LWG 2735.
* testsuite/26_numerics/headers/cstdlib/dr2735.cc: New test.
From-SVN: r268867
* doc/xml/manual/intro.xml: Include new section.
* doc/xml/manual/status_cxx2017.xml: Document more
implementation-defined properties of the library.
* doc/xml/manual/status_cxx2020.xml: Document C++2a status.
* doc/html/*: Regenerate.
From-SVN: r267867
* doc/xml/manual/spine.xml: Update copyright years.
* doc/xml/manual/status_cxx2017.xml: Adjust note about -lstdc++fs.
* doc/xml/manual/using.xml: Remove requirement to link with -lstdc++fs
for C++17 filesystem library.
* doc/html/*: Regenerate.
From-SVN: r267648
Add fix for "path::lexically_relative is confused by trailing slashes".
* doc/xml/manual/intro.xml: Document LWG 3096 change.
* src/filesystem/std-path.cc (path::lexically_relative(const path&)):
Treat a final empty element equivalently to a final dot element.
* testsuite/27_io/filesystem/path/generation/relative.cc: Add checks
for the examples in the DR.
From-SVN: r266566
This resolves a longstanding issue where the lock policy for shared_ptr
reference counting depends on compilation options when the header is
included, so that different -march options can cause ABI changes. For
example, objects compiled with -march=armv7 will use atomics to
synchronize reference counts, and objects compiled with -march=armv5t
will use a mutex. That means the shared_ptr control block will have a
different layout in different objects, causing ODR violations and
undefined behaviour. This was the root cause of PR libstdc++/42734 as
well as PR libstdc++/67843.
The solution is to decide on the lock policy at build time, when
libstdc++ is configured. The configure script checks for the
availability of the necessary atomic built-ins for the target and fixes
that choice permanently. Different -march flags used to compile user
code will not cause changes to the lock policy. This results in an ABI
change for certain compilations, but only where there was already an ABI
incompatibility between the libstdc++.so library and objects built with
an incompatible -march option. In general, this means a more stable ABI
that isn't silently altered when -march flags make addition atomic ops
available.
To force a target to use "atomic" or "mutex" the new configure option
--with-libstdcxx-lock-policy can be used.
In order to turn ODR violations into linker errors, the uses of
shared_ptr in filesystem directory iterators have been replaced
with __shared_ptr, and explicit instantiations are declared. This
ensures that object files using those types cannot link to libstdc++
libs unless they use the same lock policy.
PR libstdc++/67843
* acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Add new macro
that defines _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_ENABLE_LOCK_POLICY.
* doc/xml/manual/configure.xml: Document new configure option.
* include/bits/fs_dir.h (directory_iterator): Use __shared_ptr
instead of shared_ptr.
(recursive_directory_iterator): Likewise.
(__shared_ptr<_Dir>): Add explicit instantiation declaration.
(__shared_ptr<recursive_directory_iterator::_Dir_stack>): Likewise.
* include/bits/shared_ptr_base.h (__allocate_shared, __make_shared):
Add default template argument for _Lock_policy template parameter.
* include/ext/concurrence.h (__default_lock_policy): Check macro
_GLIBCXX_HAVE_ATOMIC_LOCK_POLICY instead of checking if the current
target supports the builtins for compare-and-swap.
* src/filesystem/std-dir.cc (__shared_ptr<_Dir>): Add explicit
instantiation definition.
(__shared_ptr<recursive_directory_iterator::_Dir_stack>): Likewise.
(directory_iterator, recursive_directory_iterator): Use __make_shared
instead of make_shared.
From-SVN: r266533
