On Sun, 30 Jan 2022 at 16:54, Hans-Peter Nilsson wrote:
>
> (I had to add separation between your reply and mine in the
> quoted parts; you may be aware.)
>
> > From: Jonathan Wakely
> > Date: Sun, 30 Jan 2022 09:32:08 +0100
> > On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++,
> > ma
Pushed to wwwdocs.
commit d334ee4964c7e186336396b44129197f618100f7
Author: Jonathan Wakely
Date: Tue Feb 1 12:37:38 2022 +
Fix grammar in C++ header dependency notes
diff --git a/htdocs/gcc-11/porting_to.html b/htdocs/gcc-11/porting_to.html
index 4d27c163..1d15570e 100644
--- a/htdocs
Pushed to wwwdocs.
commit 7193a0fb5d1b164fa676beb35df13cc603a6cf67
Author: Jonathan Wakely
Date: Tue Feb 1 12:38:59 2022 +
Add C++ "porting to" notes
diff --git a/htdocs/gcc-12/porting_to.html b/htdocs/gcc-12/porting_to.html
index 42179c11..86d99723 100644
--- a/htdocs/gcc-12/porting_
Pushed to wwwdocs.
commit 9f6040a13e7c552a8c1c65352b702dc5d71b369e
Author: Jonathan Wakely
Date: Tue Feb 1 12:40:46 2022 +
Document C++20 and C++23 library additions
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index c6baee75..2719b9d5 100644
--- a/htdocs/gcc-1
Pushed to wwwdocs.
commit 5f199e1197b67b4304a3be54579c2141c39bff30
Author: Jonathan Wakely
Date: Tue Feb 1 12:54:42 2022 +
Fix grammar for computed goto notes
diff --git a/htdocs/gcc-12/porting_to.html b/htdocs/gcc-12/porting_to.html
index 86d99723..7f4a2936 100644
--- a/htdocs/gcc-12/
Pushed to wwwdocs.
commit 996afe17497b8c06f00c763bcf7fe2b971bb0f05
Author: Jonathan Wakely
Date: Tue Feb 1 12:56:07 2022 +
Uncomment header for Fortran issues
diff --git a/htdocs/gcc-12/porting_to.html b/htdocs/gcc-12/porting_to.html
index 7f4a2936..470703c7 100644
--- a/htdocs/gcc-12
On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
wrote:
>
> Passing an uninitialized object to a function that takes its argument
> by const reference is diagnosed by -Wmaybe-uninitialized because most
> such functions read the argument. The exceptions are functions that
> don't access the
Tested powerpc64le-linux, pushed to trunk.
Currently we just print "checking for underlying I/O to use... stdio"
unconditionally, whether configured to use stdio_pure or stdio_posix. We
should make it clear that the user's configure option chose the right
thing.
libstdc++-v3/ChangeLog:
Tested powerpc64le-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* include/bits/fs_fwd.h (filesystem::perms): Fix comment.
---
libstdc++-v3/include/bits/fs_fwd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/fs_fwd.h
b/libstdc++-v3/incl
Tested powerpc64le-linux, pushed to trunk.
The standard requires directory iterators to become equal to the end
iterator value if they report an error. Some members functions of
filesystem::recursive_directory_iterator fail to do that.
libstdc++-v3/ChangeLog:
* src/c++17/fs_dir.cc (recu
Tested powerpc64le-linux, pushed to trunk.
The PR 97731 test was added to verify a fix to the Filesystem TS code,
but we should also have the same test to avoid similar regressions in
the C++17 std::filesystem code.
Also add tests for directory_options::follow_directory_symlink
libstdc++-v3/Cha
On Tue, 1 Feb 2022 at 22:00, Jonathan Wakely via Libstdc++
wrote:
>
> The standard requires directory iterators to become equal to the end
> iterator value if they report an error. Some members functions of
> filesystem::recursive_directory_iterator fail to do that.
>
> libstdc++-v3/ChangeLog:
>
>
On Wed, 2 Feb 2022 at 00:13, Martin Sebor wrote:
>
> On 2/1/22 12:48, Jonathan Wakely wrote:
> > On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
> > wrote:
> >>
> >> Passing an uninitialized object to a function that takes its argument
> >> by const reference is diagnosed by -Wmaybe-unini
On Wed, 2 Feb 2022 at 00:23, Martin Sebor wrote:
>
> On 2/1/22 17:15, Jonathan Wakely wrote:
> > On Wed, 2 Feb 2022 at 00:13, Martin Sebor wrote:
> >>
> >> On 2/1/22 12:48, Jonathan Wakely wrote:
> >>> On Tue, 1 Feb 2022 at 18:54, Martin Sebor via Libstdc++
> >>> wrote:
>
> Passing an
Tested x86_64-linux and by building x86_64-w64-mingw, pushed to trunk.
The C++98-style concept check for output iterators causes a link
failure on mingw-w64, because the __val() member function isn't defined.
Change it to use a function pointer instead. That pointer is never set
to anything meani
Tested x86_64-linux, pushed to trunk.
These tests instantiate std::multiset and std::set with a type that has
no operator< so they should use a custom comparison function.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/multiset/operators/cmp_c++20.cc: Use
custom comparison fu
On Tue, 1 Feb 2022 at 22:00, Jonathan Wakely via Libstdc++
wrote:
>
> Tested powerpc64le-linux, pushed to trunk.
>
>
> The standard requires directory iterators to become equal to the end
> iterator value if they report an error. Some members functions of
> filesystem::recursive_directory_iterator
>+ inline void
>+ atomic_flag_wait_explicit(const atomic_flag* __a, bool __old,
>+ std::memory_order __m) noexcept
No need for the std:: qualification, and check the indentation.
> libstdc++-v3/ChangeLog:
>
>PR103934
This needs to include the component: PR libstdc++/103934
On 03/02/22 12:08 +0100, David Seifert wrote:
* `-Werror` can cause issues when a more recent version of GCC compiles
an older version:
- https://bugs.gentoo.org/229059
- https://bugs.gentoo.org/475350
- https://bugs.gentoo.org/667104
Honouring --disable-werror everywhere seems reasonable t
Tested powerpc64le-linux, pushed to trunk.
We should use the SUGGEST macro for std::uncaught_exception()
deprecation warnings.
libstdc++-v3/ChangeLog:
* include/bits/allocator.h: Qualify std::allocator_traits in
deprecated warnings.
* libsupc++/exception (uncaught_except
Committed as obvious.
gcc/ChangeLog:
* doc/cpp.texi (Variadic Macros): Replace C++2a with C++20.
---
gcc/doc/cpp.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index d4290fefb41..90b2767e39a 100644
--- a/gcc/doc/cpp.t
Tested powerpc64le-linux and powerpc-aix, pushed to trunk.
This fixes the remaining filesystem::remove_all race condition by using
POSIX openat to recurse into sub-directories and using POSIX unlinkat to
remove files. This avoids the remaining race where the directory being
removed is replaced wi
Tested powerpc64le-linux, pushed to trunk.
LWG 3014 removed these incorrect noexcept specifications from the C++17
std::filesystem operations. They are also incorrect on the experimental
TS versions and should be removed from them too.
libstdc++-v3/ChangeLog:
* include/experimental/bits
Tested powerpc64le-linux (and smoke tested with clang), pushed to trunk.
There is code that only expects to be compiled with clang++ and uses its
, which works because Clang supports the _Atomic specifier
in C++. The addition of to libstdc++ broke this code, as
now it finds the C++ header inste
Tested x86_64-linux (and built on x86_64-w64-mingw), pushed to trunk.
The std::filesystem code needs to use posix::DIR not ::DIR, as that is
an alias for _WDIR on Windows.
libstdc++-v3/ChangeLog:
* src/filesystem/dir-common.h (_Dir_base::openat): Change return
type to use portab
On Fri, 4 Feb 2022 at 23:55, Jonathan Wakely wrote:
> +// Used to implement filesystem::remove_all.
> +fs::recursive_directory_iterator&
> +fs::recursive_directory_iterator::__erase(error_code* ecptr)
> +{
> + error_code ec;
> + if (!_M_dirs)
> +{
> + ec = std::make_error_code(errc::inva
On Mon, 7 Feb 2022 at 20:12, Dimitar Dimitrov wrote:
> On PRU target with newlib, we have the following combination in config.h:
> /* #undef HAVE_DIRENT_H */
> #define HAVE_FCNTL_H 1
> #define HAVE_UNLINKAT 1
>
> In newlib, targets which do not define dirent.h, get a build error when
> incl
On Mon, 7 Feb 2022 at 21:01, Jonathan Wakely wrote:
>
>
> On Mon, 7 Feb 2022 at 20:12, Dimitar Dimitrov wrote:
>
>> On PRU target with newlib, we have the following combination in config.h:
>> /* #undef HAVE_DIRENT_H */
>> #define HAVE_FCNTL_H 1
>> #define HAVE_UNLINKAT 1
>>
>> In newlib,
On Sat, 5 Feb 2022 at 01:08, Jonathan Wakely wrote:
>
> On Fri, 4 Feb 2022 at 23:55, Jonathan Wakely wrote:
> > +// Used to implement filesystem::remove_all.
> > +fs::recursive_directory_iterator&
> > +fs::recursive_directory_iterator::__erase(error_code* ecptr)
> > +{
> > + error_code ec;
> > +
Tested x86_64-linux and x86_64-w64-mingw, pushed to trunk.
The Filesystem TS isn't really supported for Windows, but the FAIL for
this test is just because it doesn't match what happens on Windows.
libstdc++-v3/ChangeLog:
* testsuite/experimental/filesystem/operations/create_directories
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Add comment about
checking for CAS on correct word size.
---
libstdc++-v3/acinclude.m4 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libstdc++-v3/acinclude.m4 b/lib
Tested powerpc64le-linux, pushed to trunk.
This replaces the _Dir constructor that takes ownership of an existing
DIR* resource with one that takes a _Dir_base rvalue instead. This means
a raw DIR* is never passed around, but is always owned by a _Dir_base
object.
libstdc++-v3/ChangeLog:
On Tue, 8 Feb 2022 at 21:02, Dimitar Dimitrov wrote:
> On Mon, Feb 07, 2022 at 09:05:45PM +, Jonathan Wakely wrote:
> > On Mon, 7 Feb 2022 at 21:01, Jonathan Wakely
> wrote:
> >
> > >
> > >
> > > On Mon, 7 Feb 2022 at 20:12, Dimitar Dimitrov
> wrote:
> > >
> > >> On PRU target with newlib,
On Wed, 9 Feb 2022 at 00:57, Thomas Rodgers via Libstdc++
wrote:
>
> This issue was observed as a deadloack in
> 29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is
> "laundered" (e.g. type T* does not suffice as a waitable address for the
> platform's native waiting primitive), the
On Wed, 9 Feb 2022 at 14:40, Jason Merrill wrote:
>
> The C++ committee just updated the values of these macros to reflect some
> late C++20 papers that we implement but others don't yet; see PR103891.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
Nice! I'll test the corresponding libstdc++ p
On Wed, 9 Feb 2022 at 15:24, Jakub Jelinek wrote:
>
> On Wed, Feb 09, 2022 at 09:40:49AM -0500, Jason Merrill via Gcc-patches wrote:
> > The C++ committee just updated the values of these macros to reflect some
> > late C++20 papers that we implement but others don't yet; see PR103891.
> >
> > Tes
On Wed, 9 Feb 2022 at 15:45, Jakub Jelinek wrote:
>
> On Wed, Feb 09, 2022 at 03:38:32PM +, Jonathan Wakely wrote:
> > On Wed, 9 Feb 2022 at 15:24, Jakub Jelinek wrote:
> > >
> > > On Wed, Feb 09, 2022 at 09:40:49AM -0500, Jason Merrill via Gcc-patches
> > > wrote:
> > > > The C++ committee
On Wed, 9 Feb 2022 at 17:10, Thomas Rodgers wrote:
>
> Updated patch. I reverted the memory order change (and will submit that as
> another patch) and fixed some spelling and grammar errors.
OK for trunk and gcc-11, thanks.
On Wed, 9 Feb 2022 at 17:35, Thomas Rodgers via Libstdc++
wrote:
>
> This patch changes the memory order used in the spin wait code to match
> that of libc++.
OK for trunk (and gcc-11 if needed).
On Tue, 8 Feb 2022 at 21:18, Jonathan Wakely wrote:
>
>
> On Tue, 8 Feb 2022 at 21:02, Dimitar Dimitrov wrote:
>
>> On Mon, Feb 07, 2022 at 09:05:45PM +, Jonathan Wakely wrote:
>> > On Mon, 7 Feb 2022 at 21:01, Jonathan Wakely
>> wrote:
>> >
>> > >
>> > >
>> > > On Mon, 7 Feb 2022 at 20:12,
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This function (and the explicit memory over version) are present in both
C++ and C , so should be in C++ too.
There is a library issue incoming for this, but the resolution is
obvious.
libstdc++-v3/ChangeLog:
* include/c_compatibilit
On Thu, 10 Feb 2022 at 17:29, Patrick Palka via Libstdc++
wrote:
>
> On Thu, 10 Feb 2022, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for the 11 branch?
> > The backport to the 10 branch hasn't been started yet, I figured it'd
> > be good to first get the 11 backpor
On Thu, 10 Feb 2022 at 17:01, Patrick Palka via Libstdc++
wrote:
>
> r12-1606 bumped the value of __cpp_lib_ranges defined in ,
> but this macro is also defined in , so it needs to
> be updated there as well.
>
> PR libstdc++/103904
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ra
On Thu, 10 Feb 2022 at 16:58, Patrick Palka via Libstdc++
wrote:
>
> The primary template for _CachedPosition is a dummy implementation for
> non-forward ranges, the iterators for which generally can't be cached.
> Because this implementation doesn't actually cache anything, _M_has_value
> is defi
On Fri, 11 Feb 2022, 17:11 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> On Fri, 11 Feb 2022, Patrick Palka wrote:
>
> > In the P2325R3 backport r11-9555 the relaxation of the constraints on
> > the partial specialization of __box (which is semantically equivalent to
> > the prima
On Fri, 11 Feb 2022 at 17:40, Thomas Rodgers via Libstdc++
wrote:
>
>
> PR102994 "atomics: std::atomic::wait is not marked const" raises the
> issue that the current libstdc++ implementation marks the notify members
> const, the implementation strategy used by libstdc++, as well as libc++
> and t
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/monotonic_buffer_resource/allocate.cc:
Ignore -Walloc-larger-than warning.
* testsuite/20_util/unsynchronized_pool_resource/allocate.cc:
Likewise.
* testsuite/29_ato
Tested x86_64-linux, pushed to trunk.
-- >8 --
The std::get_temporary_buffer function is deprecated since C++17, but
the test was expecting a warning for C++14 as well.
libstdc++-v3/ChangeLog:
* testsuite/20_util/temporary_buffer.cc: Fix dg-warning target
selector.
---
libstdc+
On Sun, 13 Feb 2022, 21:21 Hans-Peter Nilsson, wrote:
> On Fri, 11 Feb 2022, Jonathan Wakely via Gcc-patches wrote:
> > diff --git
> a/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
> b/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/alloca
Tested x86_64-linux and powerpc64le-linux with both ieee/ibm ABIs.
Pushed to trunk. This should be backported to gcc-11 too.
-- >8 --
The preprocessor check for _GLIBCXX_USE_FLOAT128 is the wrong condition,
because when the compiler is built with --with-long-double-format=ieee
configure determin
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/unsynchronized_pool_resource/allocate.cc:
Fix typo.
---
.../testsuite/20_util/unsynchronized_pool_resource/allocate.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a
Tested x86_64-linux (and clang-12.0.1), pushed to trunk.
-- >8 --
With the new value of __cpp_concepts required by P2493, we can test
whether the compiler supports conditionally trivial special members.
This allows us to remove the workaround that disables fully-constexpr
std::variant for Clang.
Tested powerpc64le-linux with both IEEE/IBM ABIs. Pushed to trunk.
-- >8 --
The std::__convert_from_v helper that formats double and long double
values into a char buffer was not being duplicated for the two long
double ABIs. This resulted in an ODR violation inside the library, where
some caller
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/104542
* include/bits/uses_allocator_args.h (make_obj_using_allocator)
(uninitialized_construct_using_allocator): Add constexpr.
* testsuite/20_util/uses_allocator/make_obj.cc
Tested powerpc64le-linux, OK for trunk?
-- >8 --
C++ allows unnamed parameters, which means we don't need to call them
'dummy' and mark them with the unused attribute.
gcc/c-family/ChangeLog:
* c-pragma.cc (handle_pragma_pack): Remove parameter name.
(handle_pragma_weak): Likewi
Tested x86_64-linux, pushed to trunk. The StdErrorCodePrinter that
crashes GDB is on gcc-11 too so this should be backported there.
-- >8 --
This attempts to implement a partial workaround for the GDB bug
https://sourceware.org/bugzilla/show_bug.cgi?id=28856 which causes GDB
to crash when printin
Tested powerpc64le-linux, pushed to trunk.
-- >8--
The SGI STL and pre-1998 drafts of the C++ standard had a default
argument for vector::insert(iterator, const bool&) which was
remove by N1051. The default argument is still present in libstdc++ for
some reason. There are no tests verifying it as
On Mon, 21 Feb 2022 at 18:00, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Gentle reminder, it is important to have this for gcc 12.
>
Well, it's been broken since 4.8, so another year wouldn't be the end of
the world ;-)
I did start reviewing it, but I was trying to find a si
On Mon, 21 Feb 2022 at 19:39, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
OK, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_base.h (__detail::__is_initializer_list):
> Define.
>
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This fixes a problem for Clang, which is going to return a non-void
pointer from __builtin_source_location(). The current definition of
std::source_location::current() converts that to void* and then has to
cast it back again in the body (which
Tested powerpc64le-linux, and briefly checkd on armv7hl-linux-gnueabi,
pushed to trunk.
The r179236 fix for std::type_info::operator== should also have been
applied to std::type_info::before. Otherwise two distinct types can
compare equivalent due to using a string comparison, when they should do
Tested powerpc64le-linux, pushed to trunk.
Clang diagnoses that the new constexpr std::string constructors are not
usable in constant expressions, because they start to write to members
of the union without setting an active member.
This adds a new helper function which returns the address of th
Tested powerpc64le-linux, pushed to trunk.
Several std::basic_string constructors dispatch to one of the
two-argument overloads of _M_construct, which then dispatches again to
_M_construct_aux to detect whether the arguments are iterators or not.
That then dispatches to one of _M_construct(size_t
Tested powerpc64le-linux, pushed to trunk.
Using placement-new isn't valid in constant expressions, so this
replaces it with std::construct_at (via the std::_Construct function
that is usable before C++20).
libstdc++-v3/ChangeLog:
* include/experimental/internet (address): Use std::_Con
Tested x86_64-linux and powerpc64le-linux, pushed to trunk.
This replaces most uses of AC_CACHE_VAL with AC_CACHE_CHECK, which means
we don't need separate AC_MSG_CHECKING and AC_MSG_RESULT macros.
There are a few trivial bugs fixed as a side effect, where an
AC_MSG_RESULT was printed out even i
On Wed, 17 Nov 2021 at 21:28, Iain Sandoe via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> this refers to the libstdc++ changes (mostly a regeneration from the
> libtool
> change) but a small addition to Makefile.am to add @loader_path as a
> default for libstdc++ to find its dependent libs.
>
Th
Tested powerpc64le-linux (and with Clang), pushed to trunk. This should
be backported to gcc-11 and gcc-10 too.
The constexpr branch in __gnu_cxx::char_traits::move compares the string
arguments to see if they overlap, but relational comparisons between
unrelated pointers are not core constant ex
On Thu, 18 Nov 2021 at 22:05, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Hi
>
> Here is a proposal to limit performance impact of _GLIBCXX_DEBUG
> mode on __erase_nodes_if.
>
> As you can see I am adding erase overloads on the Debug container
> to accept base iterato
On Fri, 19 Nov 2021 at 16:04, Iain Sandoe via Libstdc++
wrote:
>
> Depending on the permutation of CPU, OS version and shared/non-
> shared library inclusion, we get can get warnings from the external
> tools (ld64, dsymutil) which are not actually libstdc++ issues but
> relate to the external too
Tested powerpc64le-linux (and clang on x86_64-linux), pushed to trunk.
Clang gives errors for constexpr std::string because the memory returned
by std::allocator::allocate does not contain any objects yet, and
attempting to set them using char_traits::assign or char_traits::copy
fails with:
assi
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/103332
PR libstdc++/102958
* testsuite/21_strings/basic_string/capacity/char/1.cc: Add
-Wno-stringop-overflow.
* testsuite/21_strings/basic_string/operators/char/1.cc:
Likew
Tested powerpc64le-linux (and x86_64-linux clang), pushed to trunk.
All writes into the allocated buffer need to be via traits_type::assign
to begin lifetimes.
libstdc++-v3/ChangeLog:
PR libstdc++/103295
* include/bits/basic_string.tcc (_M_construct): Use the
traits assi
Tested x86_64-linux, pushed to trunk.
This replaces a __gthread_active_p() check with __is_single_threaded()
so that std::locale initialization doesn't use __gthread_once if it
happens before the first thread is created.
This means that _S_initialize_once() might now be called twice instead
of o
Tested x86_64-linux, pushed to trunk.
This ensures all constructors are checked.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_istringstream/cons/char/1.cc: Check all
constructors.
* testsuite/27_io/basic_istringstream/cons/wchar_t/1.cc:
Likewise.
* tes
Tested x86_64-linux, pushed to trunk.
The check for C++14 was using the wrong date.
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX14_DEPRECATED): Fix condition
checking for C++14.
---
libstdc++-v3/include/bits/c++config | 4 ++--
1 file changed, 2 insertions(+), 2
Tested powerpc64le-linux, pushed to trunk. Backports needed too.
includes , and since C++17 that
includes . If std::allocator is defined in terms of
__gnu_cxx::bitmap_allocator then you get a circular reference and
bootstrap fails when compiling src/c++17/*.cc.
libstdc++-v3/ChangeLog:
Tested x86_64-linux, pushed to trunk.
This allows tests to be skipped if the std::allocator implementation is
not __gnu_cxx::new_allocator.
The 20_util/allocator/overaligned.cc test requires either C++17 or
new_allocator, otherwise we can't guarantee to return overaligned
memory.
libstdc++-v3/
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/103086
* testsuite/libstdc++-prettyprinters/cxx11.cc: Check unique_ptr
with non-empty pointer and non-empty deleter.
---
.../testsuite/libstdc++-prettyprinters/cxx11.cc | 11 +++
1 f
Tested powerpc64le-linux, pushed to trunk.
An effective target like foo-bar-baz will match a target selector of
*-*-* and cause problems in the testsuite. Several libstdc++ et keywords
are of the form foo-bar, which could still be a problem for *-*
selectors.
Replace hyphens with underscores in
Tested powerpc64le-linux, pushed to trunk.
The type printers are not substituting std::string for
std::basic_string in debug mode, mark some tests as xfail.
libstdc++-v3/ChangeLog:
* testsuite/libstdc++-prettyprinters/80276.cc: Add xfail for
debug mode.
* testsuite/libst
I plan to commit this Real Soon. Please yell if you need these
alternative std::allocator back-ends to stay (and explain how you're
using them when they've been broken for years, and start sending test
results to the gcc-testresults mailing list, and ideally offer to
maintain them).
Tested powerp
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/101608
* include/bits/ranges_algobase.h (__fill_n_fn): Check for
constant evaluation before using memset.
* testsuite/25_algorithms/fill_n/constrained.cc: Check
byte-sized values as
On Wed, 24 Nov 2021 at 01:27, Thomas Rodgers wrote:
>
> const qualification was also missing in the free functions for
> wait/wait_explicit/notify_one/notify_all. Revised patch attached.
Please tweak the whitespace in the new test:
> +test1(const std::atomic &a, char*p)
The '&' should be on the
Tested x86_64-linux, pushed to trunk.
This implements the resolution I'm proposing for LWG 3545, to avoid hard
errors when using std::to_address for types that make pointer_traits
ill-formed.
Consistent with std::iterator_traits, instantiating std::pointer_traits
for a non-pointer type will be
Tested x86_64-linux, pushed to trunk.
There was a c++11_only dg-error in this testcase, for a "body of
constexpr function is not a return statement" diagnostic that was bogus,
but happened because the return statement was ill-formed. A change to
G++ earlier this month means that diagnostic is no
I've bored of having to do preprocessor checks before using
is_constant_evaluated, so I've come up with this approach. Anybody got a
better idea, or objections to this?
An alternative to __is_constant_evaluated would be to define a function
called __builtin_is_constant_evaluated when it isn't supp
Tested x86_64-linux, pushed to trunk.
Some of the checks in 20_util/pointer_traits/lwg3545.cc really belong in
20_util/to_address/lwg3545 instead.
This also fixes the ordering of the dg-options and dg-do directives.
libstdc++-v3/ChangeLog:
* testsuite/20_util/pointer_traits/lwg3545.cc:
On Fri, 26 Nov 2021 at 12:39, Jakub Jelinek wrote:
>
> On Fri, Nov 26, 2021 at 12:29:25PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > + // Internal version of std::is_constant_evaluated() for C++11.
> > + // This can be used without checking if the compiler suppo
Tested powerpc64le-linux, pushed to gcc-10.
When included from it's possible for
to be included without its prerequisites having
been included first. For gcc-11 this was fixed as part of r11-7604, this
fixes it for gcc-10 too.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h: Inc
Tested powerpc64le-linux, pushed to gcc-10.
The __gnu_debug::array type isn't three-way comparable in constant
expressions. The __gnu-debug::array type has been removed in gcc-11
anyway, so just skip the test rather than fixing it.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/array
Tested powerpc64le-linux, pushed to gcc-10.
When I backported r11-2760 as r10-8644 I simplified it and didn't add
the new _GLIBCXX11_DEPRECATED macro. That means that the macro used on
the old iostream members does nothing for C++98 mode, and so the test
fails. This adjusts the test to only expec
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/unordered_map/modifiers/move_assign.cc:
Change dg-do compile to run.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/lwg2499.cc:
Likewise.
---
.../23_containers/u
Tested x86_64-linux, pushed to trunk.
An 'xfail' selector means the test is expected to fail at runtime, so is
ignored for a compile-only test. The way to mark a compile-only test as
failing is with dg-error (which these already do).
libstdc++-v3/ChangeLog:
*
testsuite/21_strings/basic
Tested x86_64-linux, pushed to trunk.
This is what the docs say is required.
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/atomic_float/1.cc: Reorder directives.
---
libstdc++-v3/testsuite/29_atomics/atomic_float/1.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Tested x86_64-linux, pushed to trunk.
The FE bug was fixed, so we don't need this workaround now.
libstdc++-v3/ChangeLog:
PR libstdc++/96592
* include/std/tuple (tuple::is_constructible): Remove.
---
libstdc++-v3/include/std/tuple | 4
1 file changed, 4 deletions(-)
diff
Tested x86_64-linux, pushed to trunk.
When implementing constexpr std::vector I added a check for constant
evaluation in vector::_S_use_relocate(), so that we would not try to relocate
trivial objects by using memmove. But I put it in the constexpr function
that decides whether to relocate or not
Tested x86_64-linux, pushed to trunk.
This test was written to verify that the LWG 3265 changes work. But
those changes were superseded by LWG 3435, and the test is now incorrect
according to the current draft. The assignment operator is now
constrained to also require convertibility, which makes
On Fri, 26 Nov 2021 at 12:43, Jonathan Wakely wrote:
>
> On Fri, 26 Nov 2021 at 12:39, Jakub Jelinek wrote:
> >
> > On Fri, Nov 26, 2021 at 12:29:25PM +0000, Jonathan Wakely via Gcc-patches
> > wrote:
> > > + // Internal version of std::is_constant_evaluated() f
On Sat, 27 Nov 2021, 12:20 Jakub Jelinek via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> On Sat, Nov 27, 2021 at 12:59:56PM +0100, Jakub Jelinek via Gcc-patches
> wrote:
> > This patch attempts to implement P1272R4 (except for the std::bit_cast
> > changes in there which seem quite unrelated to t
Pushed to wwwdocs.
---
htdocs/gcc-12/changes.html | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index b8524f47..10ac025f 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -289,9 +289,9
1001 - 1100 of 3694 matches
Mail list logo
