On 14/02/20 10:35 -0500, Patrick Palka wrote:
These subroutines have only a single call site, so it might be best and simplest
to eliminate them before we convert the algos into function objects.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (ranges::__find_end): Fold into ...
On 14/02/20 10:35 -0500, Patrick Palka wrote:
This is the standard way to inhibit ADL for these entities, which is required as
per [algorithms.requirements] p2 and [specialized.algorithms] p4. The
conversion was done mostly mechanically with a custom Vim macro.
[ To make it easier to review, t
On 14/02/20 10:35 -0500, Patrick Palka wrote:
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h: Adjust whitespace and formatting.
* include/bits/ranges_algobase.h: Likewise.
* include/bits/ranges_uninitialized.h: Likewise.
OK for master, thanks!
-error lineno.
Tested powerpc64le-linux, committed to master.
commit 5b1d588509551291f4028497858ee9e04ce0bdee
Author: Jonathan Wakely
Date: Sat Feb 15 08:58:43 2020 +
libstdc++: Implement LWG 3150 for std::uniform_random_bit_generator
* include/bits/random.h
/23_containers/vector/erasure.cc: Likewise.
Tested powerpc64le-linux, committed to master.
commit 55b00d14f4daf671b865550c119dafdeb3139672
Author: Jonathan Wakely
Date: Sat Feb 15 09:02:30 2020 +
libstdc++: Update __cpp_lib_erase_if macro (P1115R3)
Now that this feature has
On 15/02/20 11:28 -0500, Patrick Palka wrote:
This avoids instantiating dead code when the true branch of the constexpr if is
taken.
[ diffstat generated with -w to ignore noisy whitespace changes ]
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__lexicographical_compare_fn::ope
On 03/12/19 23:38 +0100, Paul M. Bendixen wrote:
Hello
I've made an implementation of P0829 and tested it with gcc for avr.
This is great, thanks!
What's the status of libstdc++ for AVR? If I understand correctly, it
doesn't build by default when GCC is configured for AVR. Are you
overriding t
On 03/12/19 20:30 -0500, JeanHeyd Meneide wrote:
This patch implements deprecate POD for the C++ Standard Library,
Thanks.
bringing libstdc++ that much closer to 2020 conformance 🎉!
N.B. adding the attribute is not required for conformance.
+#if defined(__DEPRECATED) && (__cplusplus > 201
Committed.
commit feb29e18726065475769568bf46860fada5c4257
Author: Jonathan Wakely
Date: Wed Dec 4 23:26:45 2019 +
Document some more C++20 support in libstdc++
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index afbcd067..dadd3f22 100644
--- a/htdocs/gcc-10
I forgot about , so I actually committed this patch
instead.
commit 46f60e0689384ba6e58a9896b5831969940ac74b
Author: Jonathan Wakely
Date: Wed Dec 4 23:26:45 2019 +
Document some more C++20 support in libstdc++
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
ators/constexpr.cc:
Test three-way comparisons and arrays of unsigned char.
* testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust
dg-error line numbers.
Tested powerpc64le-linux, committed to trunk.
commit 48d500f7ffbc8f33db4c7b0a6d92f9ad52ef26bb
Author: Jonathan Wakely
* python/libstdcxx/v6/printers.py (StdCmpCatPrinter): New printer.
* testsuite/libstdc++-prettyprinters/cxx20.cc: New test.
Tested x86_64-linux, committed to trunk.
commit b41a87d7889f2399d4c1a0c626a656ba384e71a8
Author: Jonathan Wakely
Date: Thu Dec 5 00:24:58 2019 +
On 05/12/19 09:00 +0100, Christophe Lyon wrote:
On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely wrote:
On 03/12/19 09:11 +0100, Christophe Lyon wrote:
>On Mon, 16 Sep 2019 at 04:34, Tom Honermann wrote:
>>
>> A revised patch is attached that modifies the tests for deleted ostre
.
Tested powerpc64le-linux, committed to trunk.
commit 5012548fd62526fdf5e04aeacee2b127efbac0e0
Author: Jonathan Wakely
Date: Thu Dec 5 12:23:53 2019 +
libstdc++: Define std::lexicographical_compare_three_way for C++20
* include/bits/stl_algobase.h
l.
With those changes I'm committing it to trunk, thanks!
Tested powerpc64le-linux, committed to trunk as attached.
commit b36c7ac03aab419afa177d7a5f1b1f671391e675
Author: Jonathan Wakely
Date: Thu Dec 5 13:35:09 2019 +
libstdc++: Implement P1872R0 and P1394R0 for std::span
On 05/12/19 13:49 +, Jonathan Wakely wrote:
This also causes two new FAILs in 23_containers/span/lwg3255.cc but
that turns out to be a bug in the test, which fails now t hat you've
fixed a bug in span. I'll fix that as well.
Here's that fix for the buggy test.
Tested po
On Thu, 5 Dec 2019 at 16:44, Michael Matz wrote:
>
> Hello,
>
> (oh a flame bait :) )
>
> On Thu, 5 Dec 2019, Thomas Schwinge wrote:
>
> > So, I formally propose that we lift this characters per line restriction
> > from IBM punch card (80) to mainframe line printer (132).
> >
> > Tasks:
> >
> >
On Thu, 5 Dec 2019 at 20:07, Segher Boessenkool
wrote:
>
> Hi!
>
> On Thu, Dec 05, 2019 at 05:03:43PM +0000, Jonathan Wakely wrote:
> > C++17 introduces a nice feature, with rationale similar to declaring
> > variables in a for-loop init-statement:
> >
>
On Thu, 5 Dec 2019 at 22:19, Segher Boessenkool wrote:
>
> On Thu, Dec 05, 2019 at 08:56:35PM +, Jonathan Wakely wrote:
> > On Thu, 5 Dec 2019 at 20:07, Segher Boessenkool
> > wrote:
> > > On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote:
> > &g
On Thu, 5 Dec 2019 at 22:19, Segher Boessenkool wrote:
> Or you could write
>
> auto __c = (__builtin_memcmp(&*__first1, &*__first2, __len) <=> 0);
> if (__c)
> return __c;
>
> which is much easier to read, to my eyes anyway. And it is exactly the
> same for the compiler.
In this ca
I'll backport to
gcc-9-branch too.
commit ac0d55229433ddd9609684e56474ed2335dd98d8
Author: Jonathan Wakely
Date: Mon Dec 9 09:12:26 2019 +
libstdc++: fix buffer overflow in path::operator+= (PR92853)
When concatenating a path ending in a root-directory onto another path,
On 09/12/19 09:55 +, Jonathan Wakely wrote:
When concatenating a path ending in a root-directory onto another path,
we added an empty filename to the end of the path twice, but only
reserved space for one. That meant the second write went past the end of
the allocated buffer.
PR
.
* testsuite/std/ranges/safe_range_types.cc: New test.
* testsuite/util/testsuite_iterators.h: Add comment about safe_range.
Tested powerpc64le-linux, committed to trunk.
commit b081863b2bb9d2a0b5421556a3e3d7c638278145
Author: Jonathan Wakely
Date: Mon Dec 9 08:50:48 2019 +
On 09/12/19 10:32 +0100, François Dumont wrote:
After completing this work and running more tests I realized that the
declaration of algos was still not ideal.
So here is another version where algos are not re-declare in
stl_deque.h, I rather include stl_algobase.h in deque.tcc. The problem
w
pack.
* testsuite/24_iterators/indirect_callable/projected.cc: New test.
Tested powerpc64le-linux, committed to trunk.
commit c87d75745e6a133a2e8e2703cec24d09bc53c636
Author: Jonathan Wakely
Date: Tue Dec 10 15:52:50 2019 +
libstdc++: Fix bug in std::indirect_result_t
The alias tem
* include/std/span: Do not include and .
(tuple_size, tuple_element): Declare.
Tested powerpc64le-linux, committed to trunk.
commit a32163a1de2a84dde15df80dd33e54a57746d6eb
Author: Jonathan Wakely
Date: Tue Dec 10 15:59:54 2019 +
libstdc++: Reduce header
-linux, committed to trunk.
commit fb98f3d61b578aedabf371608b105d8d0b2dc999
Author: Jonathan Wakely
Date: Tue Dec 10 16:03:43 2019 +
libstdc++: Define __cpp_lib_constexpr_complex macro
This is LWG issue 3349.
* include/std/complex (__cpp_lib_constexpr_complex
PR libstdc++/92886
* include/bits/ios_base.h (std::ios_base::trunc): Fix comment.
Committing to trunk as obvious.
commit 9acff881dea3a00ae588f8ebc4c5289b98f7ee52
Author: Jonathan Wakely
Date: Tue Dec 10 17:00:30 2019 +
libstdc++: Fix description of std::ios::trunc
a1cc0205b3a297db1399519f5169a6a1f245a421
Author: Jonathan Wakely
Date: Tue Dec 10 23:39:22 2019 +
libstdc++: Correct noexcept-specifiers on span constructors
As discussed at https://github.com/cplusplus/draft/issues/3534 two
std::span constructors specify incorrect conditions for throwing
On 10/12/19 22:38 -0800, Thomas Rodgers wrote:
User-agent: mu4e 1.3.4; emacs 26.2
* include/std/condition_variable
(condition_variable_any::wait_on(_Lock&, stop_token, _Predicate): Rename
to match current draft standard.
(condition_variable_any::wait_on_until(_Lock
On 11/12/19 08:29 +0100, François Dumont wrote:
I plan to commit this tomorrow.
Note that rather than just adding the missing
_GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace
usage outside std namespace. Let me know if it was intentional.
It was intentional, why move it
On 11/12/19 11:16 +, Jonathan Wakely wrote:
On 11/12/19 08:29 +0100, François Dumont wrote:
I plan to commit this tomorrow.
Note that rather than just adding the missing
_GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous
namespace usage outside std namespace. Let me know if it
On 11/12/19 08:29 +0100, François Dumont wrote:
I plan to commit this tomorrow.
Note that rather than just adding the missing
_GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous namespace
usage outside std namespace. Let me know if it was intentional.
* src/c++11/random.cc: Add
On 11/12/19 21:23 +0100, François Dumont wrote:
On 12/11/19 12:16 PM, Jonathan Wakely wrote:
On 11/12/19 08:29 +0100, François Dumont wrote:
I plan to commit this tomorrow.
Note that rather than just adding the missing
_GLIBCXX_[BEGIN,END]_VERSION_NAMESPACE I also move anonymous
namespace
On 11/12/19 21:25 +0100, François Dumont wrote:
On 12/11/19 12:22 PM, Jonathan Wakely wrote:
On 11/12/19 11:16 +, Jonathan Wakely wrote:
On 11/12/19 08:29 +0100, François Dumont wrote:
I plan to commit this tomorrow.
Note that rather than just adding the missing
_GLIBCXX_[BEGIN,END
On 11/12/19 22:28 +0100, François Dumont wrote:
On 12/11/19 9:44 PM, Jonathan Wakely wrote:
On 11/12/19 21:23 +0100, François Dumont wrote:
On 12/11/19 12:16 PM, Jonathan Wakely wrote:
On 11/12/19 08:29 +0100, François Dumont wrote:
I plan to commit this tomorrow.
Note that rather than just
x86_64-linux, committed to trunk.
commit 70a1dc5fb4465642c00306d003164bdd9a5b8e08
Author: Jonathan Wakely
Date: Thu Dec 12 13:21:07 2019 +
libstdc++: Simplify std::common_comparison_category
* libsupc++/compare (common_comparison_category): Define without
using
On 05/12/19 17:12 +0100, Christophe Lyon wrote:
On Thu, 5 Dec 2019 at 12:43, Jonathan Wakely wrote:
On 05/12/19 09:00 +0100, Christophe Lyon wrote:
>On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely wrote:
>>
>> On 03/12/19 09:11 +0100, Christophe Lyon wrote:
>> >On Mon, 1
On 13/12/19 18:54 +0100, Olivier Hainque wrote:
This change adjusts the libstdc++ configuration for VxWorks
to set ac_has_nanosleep=yes, which enables the use of nanosleep
from the library.
While this technically depends on the kernel configuration
(INCLUDE_POSIX_TIMERS) this is the normal conf
On 17/12/19 10:04 +0100, Jérôme Lambourg wrote:
Hello,
This patch to libstdc++ configure ensures that pthread_rwlock_t is used only
when pthread is used for gthreads implementation.
The original issue is that VxWorks comes with its native tasking layer and an
optional pthread layer built above
On 10/12/19 15:58 +0100, Corentin Gay wrote:
Hello there !
When implementing the support for gthreads in VxWorks, we stumbled on a
problem in the testsuite. In the libstdc++ testsuite, we
indiscriminately add the `-pthread` switch to the tests that require
linking against the pthread library.
On 13/12/19 22:27 +0100, François Dumont wrote:
Here is a patch to fix prettyprinters.exp failures in normal and debug
modes.
In 80276.cc I replicate the #define with comment from other tests even
if it isn't true that cxx11 abi string isn't supported. It's just that
it doesn't appear as 'std
On 16/12/19 14:51 +0100, Jérôme Lambourg wrote:
Hello,
In libstdc++, the test for the presence of setrlimit on the target is currently
performed in C as opposed to the other similar tests there. This leads on only a
warning being issued during configure as opposed to the expected error, and thus
ommit 1c52a87af8a3931fc4bad440430d908264087a47
Author: Jonathan Wakely
Date: Fri Dec 20 15:07:34 2019 +
fortran: Fix PR number in comment of testcase for PR 69497
The testcase was originally committed with an incorrect changelog and PR
number. The changelog was fixed later, but no
On 19/12/19 09:36 +, Jonathan Wakely wrote:
On 05/12/19 17:12 +0100, Christophe Lyon wrote:
On Thu, 5 Dec 2019 at 12:43, Jonathan Wakely wrote:
On 05/12/19 09:00 +0100, Christophe Lyon wrote:
On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely wrote:
On 03/12/19 09:11 +0100, Christophe Lyon
On Sat, 21 Dec 2019 at 23:37, Gerald Pfeifer wrote:
>
> Hi Matthew,
>
> On Mon, 4 Feb 2019, Matthew Bauer wrote:
> > The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
> > have changed their ctype.h definition. It was updated in their intree
> > libstdc++-v3 but not in the GCC o
On 27/12/19 22:27 -0500, JeanHeyd Meneide wrote:
On Fri, Dec 27, 2019 at 2:33 PM Jakub Jelinek wrote:
This will be ABI incompatible between GCC and Clang, that doesn't look like
a good idea to me. I thought the plan is to use what you have in the
_GLIBCXX_HAVE_BUILTIN_SOURCE_LOCATION case alw
On 29/12/19 12:07 +0100, Stephan Bergmann wrote:
On 05/12/2019 13:46, Jonathan Wakely wrote:
commit 5012548fd62526fdf5e04aeacee2b127efbac0e0
Author: Jonathan Wakely
Date: Thu Dec 5 12:23:53 2019 +
libstdc++: Define std::lexicographical_compare_three_way for C++20
* include
On 03/01/20 14:54 +, Jonathan Wakely wrote:
On 29/12/19 12:07 +0100, Stephan Bergmann wrote:
FYI, the above fails with -std=c++2a and recent Clang trunk after <https://github.com/llvm/llvm-project/commit/bc633a42dd409dbeb456263e3388b8caa4680aa0>
"Mark the major papers for C++20
On 02/01/20 17:16 -0500, JeanHeyd Meneide wrote:
This implementation does not update the internal
__allocate_shared and __make_shared functions (I don't know why there
seems to be a duplicate front-end for those functions: it seems a
little weird to use both? Maybe it's for legacy reasons, al
On 25/12/19 03:40 -0300, Alexandre Oliva wrote:
When cross-building for vxworks, test for declarations of long double
functions in math.h. We don't normally test for these functions when
cross compiling, because link tests don't work, or ever really, but
not defining them as available causes re
On 03/01/20 15:03 +, Jonathan Wakely wrote:
On 03/01/20 14:54 +, Jonathan Wakely wrote:
On 29/12/19 12:07 +0100, Stephan Bergmann wrote:
FYI, the above fails with -std=c++2a and recent Clang trunk after <https://github.com/llvm/llvm-project/com
55ac97433857c19cd9ecf3fbf6e35583d72da86d
Author: Jonathan Wakely
Date: Mon Jan 6 11:26:16 2020 +
libstdc++: Remove redundant inequality operators in
* include/std/stop_token (stop_token): Remove operator!= (LWG 3254).
(stop_source): Likewise (LWG 3362).
* testsuite
On 05/12/19 13:14 +, Wilco Dijkstra wrote:
Hi,
Add entries for the default change in changes.html and porting_to.html.
Passes the W3 validator.
Cheers,
Wilco
---
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index
e02966460450b7aad884b2d45190b9ecd8c7a5d8..304e1e8cc
On 07/11/19 20:28 +0100, François Dumont wrote:
From what I understood from recent fix the unordered containers need
to be updated the same way.
I hope you'll appreciate the usage of rvalue forwarding. Containers
Yes, I think it makes sense.
node values are moved as soon as _M_assign is cal
On 07/11/19 20:28 +0100, François Dumont wrote:
From what I understood from recent fix the unordered containers need
to be updated the same way.
I hope you'll appreciate the usage of rvalue forwarding. Containers
node values are moved as soon as _M_assign is called with a rvalue
reference to
On 03/01/20 22:04 +0100, François Dumont wrote:
This is the patch to extend PR 92124 to the associative containers.
As it is pretty simple I thought it could maybe go in now.
I also think that the existing 92124 tests are not really testing what
they should with the move assignment operators n
On 22/12/19 23:20 +0100, Olivier Hainque wrote:
Hi Jonathan,
On 19 Dec 2019, at 12:13, Jonathan Wakely wrote:
Is there a way to detect that more reliably? Should we replicate the
test used later in the file, to detect whether the timers are really
enabled for VxWorks?
AC_MSG_CHECKING
On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
Hi Matthew,
On Mon, 4 Feb 2019, Matthew Bauer wrote:
The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
have changed their ctype.h definition. It was updated in their intree
libstdc++-v3 but not in the GCC one. My understanding i
On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
Hi Matthew,
On Mon, 4 Feb 2019, Matthew Bauer wrote:
The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
have changed their ctype.h definition. It was updated in their intree
libstdc++-v3 but not in the GCC one. My understanding i
On 06/01/20 23:20 +0100, Kamil Rytarowski wrote:
On 06.01.2020 16:24, Jonathan Wakely wrote:
On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
Hi Matthew,
On Mon, 4 Feb 2019, Matthew Bauer wrote:
The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
have changed their ctype.h
On 07/01/20 00:18 +0100, Kamil Rytarowski wrote:
On 06.01.2020 16:34, Jonathan Wakely wrote:
On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
Hi Matthew,
On Mon, 4 Feb 2019, Matthew Bauer wrote:
The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
have changed their ctype.h
On 07/01/20 01:30 +0100, Kamil Rytarowski wrote:
On 07.01.2020 01:26, Jonathan Wakely wrote:
On 06/01/20 23:20 +0100, Kamil Rytarowski wrote:
On 06.01.2020 16:24, Jonathan Wakely wrote:
On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
Hi Matthew,
On Mon, 4 Feb 2019, Matthew Bauer wrote:
The
On 07/01/20 15:40 +, Jonathan Wakely wrote:
On 07/01/20 01:30 +0100, Kamil Rytarowski wrote:
On 07.01.2020 01:26, Jonathan Wakely wrote:
On 06/01/20 23:20 +0100, Kamil Rytarowski wrote:
On 06.01.2020 16:24, Jonathan Wakely wrote:
On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
Hi Matthew
On 08/01/20 06:43 +0100, François Dumont wrote:
@@ -404,15 +413,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_begin() const
{ return static_cast<__node_type*>(_M_before_begin._M_nxt); }
- // Assign *this using another _Hashtable instance. Either elements
- // are copy or move d
* testsuite/experimental/filesystem/operations/remove_all.cc: Likewise.
Tested powerpc64le-linux, committed to trunk.
commit b89525a0036c9b9f6d3d6952b54624fca27d9774
Author: Jonathan Wakely
Date: Wed Jan 8 16:23:07 2020 +
libstdc++: Fix error handling in filesystem::remove_all (PR
On 08/01/20 16:44 +, Jonathan Wakely wrote:
When recursing into a directory, any errors that occur while removing a
directory entry are ignored, because the subsequent increment of the
directory iterator clears the error_code object.
This fixes that bug by checking the result of each
On 08/01/20 18:47 -0500, David Malcolm wrote:
On Wed, 2019-12-04 at 10:59 -0700, Martin Sebor wrote:
On 11/15/19 6:23 PM, David Malcolm wrote:
> This patch adds an ordered_hash_map template, which is similar to
> hash_map, but preserves insertion order.
>
> gcc/ChangeLog:
>* Makefile.in (OBJ
few arches next week).
commit d773997e6579a31a259cd574362d86c5b57ce822
Author: Jonathan Wakely
Date: Thu Jan 9 12:06:38 2020 +
libstdc++: Define memory resource key functions non-inline (PR93208)
This prevents the vtables and RTTI from being emitted in every object
Does this look reasonable to push? There are lots of other uses of
AM_ENABLE_MULTILIB(, ..) in the tree, but I'll leave others to "fix"
those if needed.
-- >8 --
This seems to be needed to build with --enable-maintainer-mode but I
don't understand why it doesn't fail in the normal build.
libstdc
Does the text of these new diagnostics look good?
There are of course other ways for a type to be not-formattable (e.g.
the formatter::format member doesn't return the right type or has some
other kind of incorrect signature, or the formatter::parse member isn't
constexpr) but we can't predict/det
This fixes a regression on all active branches.
Tested aarch64-linux.
-- >8 --
I caused a regression with commit r10-908 by adding a constraint to the
non-explicit allocator-extended default constructor, but seemingly
forgot to add an explicit overload with the corresponding constraint.
libst
Is this OK for trunk?
-- >8 --
I'm seeing errors for --enable-maintainer-mode builds due to incorrectly
regenerating these files. They should be touched by gcc_update so they
aren't regenerated unnecessarily.
contrib/ChangeLog:
* gcc_update: Add more generated files in libcc1, lto-plugi
On 01/03/24 15:38 -0500, Jason Merrill wrote:
On 3/1/24 14:24, Marek Polacek wrote:
+@smallexample
+template
+[[gnu::no_dangling(std::is_reference_v)]] int foo (T& t) @{
I think this function should return a reference.
The condition in the attribute can only ever be true if you call this
fu
OK for trunk?
Or am I missing something and the docs are right? (sometimes? always?)
-- >8 --
The manual has always claimed that -dD differs from -dM by not
outputting predefined macros, but that's untrue. It has been untrue
since at least GCC 3.2 and probably even older.
gcc/ChangeLog:
On Tue, 5 Mar 2024 at 18:31, Joseph Myers wrote:
>
> On Tue, 5 Mar 2024, Jakub Jelinek wrote:
>
> > I can't bisect that far, supposedly predefined macros weren't included back
> > in 1996 when this was written but maybe it changed in 1999 or even earlier.
>
> It looks like this changed in 3.0 (so p
Any objection to this update to make the docs reflect reality?
-- >8 --
The macro-based concept checks are unmaintained and do not support C++11
or later, so reject valid code. If nobody plans to update them we should
consider removing them. Alternatively, we could ignore the macro for
C++11 and
Tested x86_64-linux. Pushed to trunk.
-- >8 --
I don't see why we should rely on __builtin_memset etc. in tests. We can
just include and use the public API.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/deque/allocator/default_init.cc: Use
std::memset instead of __builtin_m
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The list in tzdb.cc isn't the only hardcoded list of leap seconds in the
library, there's the one defined inline in (to avoid loading
the tzdb for the common case) and another in a testcase. This updates
them to note that there are no new leap secon
Pushed to trunk.
On Fri, 1 Mar 2024 at 15:09, Jonathan Wakely wrote:
> Does the text of these new diagnostics look good?
>
> There are of course other ways for a type to be not-formattable (e.g.
> the formatter::format member doesn't return the right type or has some
> oth
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The whole point of these typedefs is to guarantee lock-freedom, so if
the target has no such types, we shouldn't defined the typedefs at all.
libstdc++-v3/ChangeLog:
PR libstdc++/114103
* include/bits/version.def (atomic_lock_free_t
Tested x86_64-linux. Pushed to trunk.
-- >8 --
When converting a chrono::duration to a result type with an
integer representation we should use chrono::round<_Duration> so that we
don't truncate towards zero. Rounding ensures that e.g. 0.001999s
becomes 2ms not 1ms.
We can also remove some redun
Tested x86_64-linux. Pushed to trunk.
-- >8 --
With std::from_chars we can parse subsecond durations much faster than
with std::num_get, as shown in the microbenchmarks below. We were using
std::num_get and std::numpunct in order to parse a number with the
locale's decimal point character. But we
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Implementing all chrono::from_stream overloads in terms of
chrono::sys_time meant that a leap second time like 23:59:60.001 cannot
be parsed, because that cannot be represented in a sys_time.
The fix to support parsing leap seconds as utc_time is to
Tested x86_64-linux. Pushed to trunk.
-- >8 --
When parsing a std::chrono::sys_days (or a sys_time with an even longer
period) we should not require a time-of-day to be present in the input,
because we can't represent that in the result type anyway.
Rather than trying to decide which specializat
On Thu, 16 Nov 2023 at 13:49, Jonathan Wakely wrote:
> From: Thomas Rodgers
>
> These two patches were written by Tom earlier this year, before he left
> Red Hat. We should finish reviewing them for GCC 14 (and probably squash
> them into one?)
>
> Tom, you mentioned furt
On Sat, 9 Mar 2024 at 12:18, Jonathan Wakely wrote:
>
>
>
> +template
>> + __wait_result_type
>> + __wait_for(const __platform_wait_t* __addr, __wait_args __args,
>> +const chrono::duration<_Rep, _Period>& __rtime) noexcep
On Mon, 11 Mar 2024 at 23:36, Barnabás Pőcze wrote:
>
> Previously, calling erase(key) on both std::map and std::set
> would execute that same code that std::multi{map,set} would.
> However, doing that is unnecessary because std::{map,set}
> guarantee that all elements are unique.
>
> It is reason
Every year I have to scroll down further and further to the useful part,
and I'm getting too old to spend my time doing that! :)
I suggested this on IRC and iains agreed. What do others think?
-- >8 --
This seems more useful with the recent history first.
---
htdocs/develop.html | 819 +
On Thu, 7 Mar 2024 at 12:07, Jonathan Wakely wrote:
>
> Any objection to this update to make the docs reflect reality?
Pushed to trunk now.
>
> -- >8 --
>
> The macro-based concept checks are unmaintained and do not support C++11
> or later, so reject valid code. If nob
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/debug.xml: Improve docs on debug builds and
using ASan. Mention _GLIBCXX_ASSERTIONS. Reorder sections to put
the most relevant ones first.
* doc/xml/manual/using.xml: Add comma.
* doc/html/
Tested with GDB 14.1 on x86_64-linux. I'll backport this too.
-- >8 --
A recent GDB change causes this test to fail due to missing RTTI for the
custom_cast type. This is presumably because the custom_cat type was
defined as a local class, so has no linkage. Moving it to local scope
seems to fix t
I think we have all C++23 changes in this table now. At some point soon
we should replace the C++20 table of papers with the C++20 table of
contents, as we do for the other standards.
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2023.xml: Update C++23 sta
Pushed to trunk. I should backport this too.
-- >8 --
The bug with exceptions thrown during a std::call_once call affects all
targets, so fix the docs that say it only affects non-Linux targets.
libstdc++-v3/ChangeLog:
PR libstdc++/66146
* doc/xml/manual/status_cxx2011.xml: Remo
On Fri, 16 Feb 2024 at 15:15, Jonathan Wakely wrote:
>
> On Fri, 16 Feb 2024 at 14:10, Jakub Jelinek wrote:
> >
> > On Fri, Feb 16, 2024 at 01:51:54PM +0000, Jonathan Wakely wrote:
> > > Ah, although __atomic_compare_exchange only takes pointers, the
> > > c
Should we do this to silence the deprecation messages from the TBB
headers we include?
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/101228
* include/pstl/parallel_backend_tbb.h
(TBB_SUPPRESS_DEPRECATED_MESSAGES):
Define before including then undef afterwards.
---
libs
Tested aarch64-linux and x86_64-linux. Pushed to trunk.
I forgot to update the commit log to remove the speculation, because
Stephan Lavavej confirmed that MSVC doesn't mark those functions
nodiscard because it would result in too many false positives. Although
it might find some real bugs, it wou
Tested aarch64-linux. Pushed to trunk.
-- >8 --
The fast path for "{}" format strings has a bug for negative integers
where the length passed to std::to_chars is too long.
libstdc++-v3/ChangeLog:
PR libstdc++/114325
* include/std/format (_Scanner::_M_scan): Pass correct length t
OK for trunk?
-- >8 --
The hyphen can be misunderstood to mean "emitted to -" i.e. stdout.
Refer to both forms by name, rather than using "the former" for one and
referring to the other by name.
gcc/ChangeLog:
* doc/invoke.texi (Diagnostic Message Formatting Options):
Replace hy
16.cc: New test case.
> > * testsuite/23_containers/vector/debug/114316.cc: New test case.
> >
> > Tested under Linux x86_64, ok to commit ?
>
OK for trunk, thanks!
I think this is OK to backport to 13 too.
Maybe after this we can define the __cpp_lib_null_itetators macr
301 - 400 of 10280 matches
Mail list logo
