These new headers should probably have the usual boilerplate at the top,
so make the Python scripts output it.
-- >8 --
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Add copyright and
license text to the output.
libstdc++-v3/ChangeLog:
*
On Tue, 9 Jan 2024 at 12:44, Jonathan Wakely wrote:
>
> I was talking to Matthias Klose about enabling libstdc++_libbacktrace.a
> for Ubuntu's gcc package and I realised that it would be preferable if
> the gcc-13 branch had those libbacktrace symbols in libstdc++exp.a. I
&
On 02/02/24 12:14 +, Jonathan Wakely wrote:
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended
This should fix the problem that libstdc++exp.a doesn't actually contain
the symbols from libstdc++fs.a, despite me claiming it did.
This increases the size of libstdc++exp.a considerably, because now it
really does contain what I intended it to contain. We might be able to
avoid that increased
Tested x86_64-linux. Pushed to releases/gcc-12 branch.
-- >8 --
This avoids a linker error with -fkeep-inline-functions when including
. We can't backport the fix from trunk because it adds an
export to the shared library. By marking the "missing" symbol
always_inline for C++20 mode we don't
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v6::network): Define.
(network_v6::hosts): Finish implementing.
(network_v6::to_string): Do not concatenate std::string to
arbitrary std::basic_string
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This looks like a typo in the upstream test that causes a failure in
debug mode. It has been reported upstream.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/25_algorithms/pstl/alg_merge/inplace_merge.cc: Fix
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The reverse_invoker utility for PSTL tests uses forwarding references for
all parameters, but some of those parameters get forwarded to move
constructors which then leave the objects in a moved-from state. When
the parameters are forwarded a second
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This was changed by LWG 3857.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(R&&)): Remove
constraint that traits_type must be the same, as per LWG 3857.
*
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This should not be noexcept because its _M_syncbuf member has a
potentially-throwing move assignment operator. The noexcept was removed
by LWG 3867.
libstdc++-v3/ChangeLog:
* include/std/syncstream (basic_osyncstream::operator=): Remove
Tested aarch64-linux. Pushed to trunk.
-- >8 --
This overload of std::generator::promise_type::yield_value calls things
which might throw, so should not be noexcept. The noexcept was remove by
LWG 3894.
libstdc++-v3/ChangeLog:
* include/std/generator (promise_type::yield_value): Remove
I'm going to push this as obvious.
-- >8 --
gcc/ChangeLog:
* doc/extend.texi (Common Type Attributes): Fix typo in
description of hardbool.
---
gcc/doc/extend.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
On Thu, 1 Feb 2024 at 17:22, Jonathan Wakely wrote:
>
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all i
On Thu, 1 Feb 2024, 17:23 Jonathan Wakely, wrote:
> On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
> >
> > On Feb 01 2024, Jonathan Wakely wrote:
> >
> > > This will result in an ABI change for targets that use 1-byte alignment
> > > for all integral
On Thu, 1 Feb 2024 at 16:34, Andreas Schwab wrote:
>
> On Feb 01 2024, Jonathan Wakely wrote:
>
> > This will result in an ABI change for targets that use 1-byte alignment
> > for all integral types, e.g. cris-elf.
>
> Or 2-byte alignment as on m68k.
Ah yes.
In fact
On Thu, 1 Feb 2024 at 17:08, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Thu, 1 Feb 2024 17:16:47 +0100
>
> > Not speaking for other platforms with default-packed layout
> > or where ABI structure layout alignment implies a change due
> > to PCC_BITFIELD_TYPE_MATTERS and
I am undecided about pushing this PATCH 2/2 to trunk. PATCH 1/2 needs to
be done now due to the ABI impact on cris-elf. This one could wait for
stage 1. (HP, this one probably isn't of interest to you, but I don't
know how to tell git-send-email to only CC you on the first patch).
I'd like to do
I plan to push this to trunk soon.
CC HP for visibility of the change affecting cris-elf. In practice it
shouldn't make any difference to any sensible code. It only affects
C++20 mode (and later), and only changes the size of std::formatter
objects which are typically only created by the library
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These line markers are not needed, because searching
for a macro name works fine. Removing them means that small changes to
do not result in large diffs to
because of all the changed line numbers.
libstdc++-v3/ChangeLog:
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We no longer hit a __builtin_unreachable() in these tests, so we need to
update the dg-error patterns to match _Error_formatter::_M_error().
We can also remove some dg-prune-output directives matching notes saying
"in 'constexpr' expansion" because
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In C++20 it's deprecated for a [=] lambda capture to capture the 'this'
pointer. Using resize_and_overwrite with a lambda seems like overkill to
write three chars to the string anyway. Just resize the string and
overwrite the end of it directly.
On Wed, 31 Jan 2024 at 17:20, xndcn wrote:
>
> Thanks!
>
> > Why not just use -latomic unconditionally here?
> testsuites of libstdc++ seems to have some tricks to find and link
> libatomic.a by using "dg-add-options libatomic", which do nothing for
> x86 target. In previous email, we decide not
On Tue, 30 Jan 2024 at 21:35, Jonathan Wakely wrote:
>
> On 30/01/24 15:02 +, Jonathan Wakely wrote:
> >That way other subdirectories could add their own extra generated files to
> >it.
>
> Like so.
>
> mklog: Add lookup for generated fil
rward<>
> calls when
> done several times on the same arguments.
>
> Ok to commit ?
>
> François
>
>
> On 31/01/2024 14:11, redi at gcc dot gnu.org wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
>
> Jonathan Wakely changed:
>
On Wed, 31 Jan 2024 at 19:41, Patrick Palka wrote:
>
> On Wed, 31 Jan 2024, Patrick Palka wrote:
>
> > On Wed, 24 Jan 2024, Patrick Palka wrote:
> > >
> > > In v2:
> > >
> > > * Named the template parameters of the forward declaration of pair.
> > > * Added dangling checks for the new tuple and
On Wed, 31 Jan 2024 at 09:38, Iain Sandoe wrote:
>
> Hi Jonathan,
>
> > On 30 Jan 2024, at 15:02, Jonathan Wakely wrote:
> >
> > This should fix the std/text_encoding/* FAILs that Iain sees on darwin.
> > I assume it will make it work for FreeBSD too.
>
SG16 (Unicode and Text Study Group) and LWG are overwhelmingly in favour
of adding this alias, so let's not wait for the issue to get voted into
the working draft.
Tested aarch64-linux. Pushed to trunk.
-- >8 --
As noted in LWG 4043, "ASCII" is not an alias for any known registered
character
Another piece of the manual that needs to be kept up to date as we add
features.
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/using.xml: Update tables of supported headers.
* doc/html/*: Regenerate.
---
libstdc++-v3/doc/html/manual/index.html | 2
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This shift only happens if the unsigned long long type is wider than
unsigned long but the compiler warns when it sees the shift, without
caring if it's reachable.
Use the preprocessor to compare the sizes and just reuse
On 30/01/24 15:02 +, Jonathan Wakely wrote:
That way other subdirectories could add their own extra generated files to it.
Like so.
mklog: Add lookup for generated files in specific sub-directories
The mklog.py output for libstdc++-v3/include/bits/version.h is awful
On Tue, 30 Jan 2024, 15:03 Jonathan Wakely, wrote:
> OK for trunk?
>
> -- >8 --
>
> The mklog.py output for libstdc++-v3/include/bits/version.h is awful.
> Teaching mklog.py that it's generated makes it correctly use
> "Regenerate" for its changes. We
On Tue, 16 Jan 2024 at 16:17, xndcn wrote:
>
> Sorry about the mangled content...
> So I add a new add-options for libatomic_16b:
>
> ---
> libstdc++-v3/ChangeLog:
>
> * include/bits/atomic_base.h: add __builtin_clear_padding in
> __atomic_float constructor.
> * testsuite/lib/dg-options.exp: add
On Tue, 16 Jan 2024 at 16:17, xndcn wrote:
>
> Sorry about the mangled content...
> So I add a new add-options for libatomic_16b:
>
> ---
> libstdc++-v3/ChangeLog:
>
> * include/bits/atomic_base.h: add __builtin_clear_padding in
> __atomic_float constructor.
> * testsuite/lib/dg-options.exp: add
On 28/09/23 18:37 +0200, Dimitry Andric wrote:
Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
When building gcc's C++ sources against recent libc++, the poisoning of
the ctype macros due to including safe-ctype.h before including C++
standard headers such as , , etc, causes many
OK for trunk?
-- >8 --
The mklog.py output for libstdc++-v3/include/bits/version.h is awful.
Teaching mklog.py that it's generated makes it correctly use
"Regenerate" for its changes. We can do the same for the other new
generated headers as well.
contrib/ChangeLog:
* mklog.py
This should fix the std/text_encoding/* FAILs that Iain sees on darwin.
I assume it will make it work for FreeBSD too.
I won't push this until I hear it works for at least one of those.
Tested x86_64-linux.
-- >8 --
The header is needed for newlocale and locale_t on these
targets.
l: Link against libstdc++exp.a to use
> _GLIBCXX_DEBUG_BACKTRACE macro.
>
> Ok to commit ?
Yes please - thanks.
>
> François
>
> On 29/01/2024 11:10, Jonathan Wakely wrote:
> > On Mon, 29 Jan 2024 at 06:13, François Dumont wrote:
> >> Hi
> >>
&
On Wed, 24 Jan 2024 at 17:27, Jonathan Wakely wrote:
>
> On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> >
> > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > > @@ -1016,10
On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
>
> On Wed, 24 Jan 2024, Jonathan Wakely wrote:
>
> > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > > b/libstdc++-v3/include/bits/stl_pair.h
>
On Wed, 24 Jan 2024 at 12:01, Jonathan Wakely wrote:
>
> On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > b/libstdc++-v3/include/bits/stl_pair.h
> > index b81b479ad43..a9b20fbe7ca 100644
> > --- a/libstd
On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> diff --git a/libstdc++-v3/include/bits/stl_pair.h
> b/libstdc++-v3/include/bits/stl_pair.h
> index b81b479ad43..a9b20fbe7ca 100644
> --- a/libstdc++-v3/include/bits/stl_pair.h
> +++ b/libstdc++-v3/include/bits/stl_pair.h
> @@ -85,12 +85,70 @@
On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
>
> GDB emits end of lines as \r\n, we currently match the reverse \n\r,
We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> possibly leading to mismatches under racy conditions.
What do we incorrectly match? Is the
On Tue, 23 Jan 2024, 23:53 Patrick Palka, wrote:
> This is consistent with std::tuple's __const_assignable member function,
> and will be reused when implementing the new pair::operator= overloads
> from P2165R4.
>
OK
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_pair.h
On Mon, 22 Jan 2024 at 09:51, Jonathan Wakely wrote:
>
> On Sun, 21 Jan 2024 at 22:27, Jonathan Wakely wrote:
> > --- a/libstdc++-v3/testsuite/std/time/clock/file/io.cc
> > +++ b/libstdc++-v3/testsuite/std/time/clock/file/io.cc
> > @@ -17,6 +17,23 @@ test_ostream()
> &g
On Sun, 21 Jan 2024 at 22:27, Jonathan Wakely wrote:
> --- a/libstdc++-v3/testsuite/std/time/clock/file/io.cc
> +++ b/libstdc++-v3/testsuite/std/time/clock/file/io.cc
> @@ -17,6 +17,23 @@ test_ostream()
>VERIFY( ss1.str() == ss2.str() );
> }
>
> +void
> +test_
Tested aarch64-linux. Pushed to trunk.
Backport to gcc-13 would be good too, I think.
-- >8 --
Currently trying to use std::format with certain specializations of
std::chrono::time_point is ill-formed, due to one member function of the
__formatter_chrono type which tries to write a time_point
Tested aarch64-linux. Pushed to trunk. Backport needed to gcc-13 too.
-- >8 --
THe std::chrono::file_clock conversions were not using common_type and
so failed to compile when converting anything that should have increased
precision after arithmetic with a std::chrono::seconds value.
Tested aarch64-linux. Pushed to trunk. Backport to gcc-13 to follow.
-- >8 --
The logic for handling '#' forms was ... not good. The count of
significant figures just counted digits, instead of ignoring leading
zeros. And when moving the result from the stack buffer to a dynamic
string the
On Sat, 20 Jan 2024, 03:47 Marek Polacek, wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
OK, thanks.
The standard ranges have their own protection against dangling via the
opt-in borrowed_range concept, and algorithms that don't allow returning
iterators into rvalue
Tested powerp64le-linux. Pushed to trunk.
-- >8 --
My change in r14-8181-g665a3ff1539ce2 was incomplete as there's a second
place using CTAD with the _Utf32_view alias template. This fixes it.
libstdc++-v3/ChangeLog:
* include/std/format (_Spec::_M_parse_fill_and_align): Do not
Tested powerp64le-linux. Pushed to trunk.
-- >8 --
I accidentally used && in a fold-expression instead of || which meant
that in C++17 the tuple(UElements&&...) constructor only failed its
debug assertion if all tuple elements were dangling references. Some
missing tests (noted as "TODO") meant
On Fri, 19 Jan 2024 at 15:16, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK.
This was on my TODO list after somebody asked about on
IRC this week, so thanks for doing it.
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> *
On Thu, 18 Jan 2024 at 13:51, Patrick Palka wrote:
>
> On Thu, 18 Jan 2024, Jonathan Wakely wrote:
>
> > On Thu, 18 Jan 2024 at 02:48, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > Please
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These variables are only read from if we haven't reached the end of
either range, in which case they're guaranteed to be initialized to the
next alphanumeric character. But we can just initialize them to make the
compiler happy.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
When int8_t is a typedef for char (rather than signed char) this test
fails because it tries to format a char, which is treated differently
from formatting other integral types (including signed char).
Use signed char explicitly so the result
Pushed to wwwdocs.
-- >8 --
std::generator, std::format improvements, std::text_encoding.
---
htdocs/gcc-14/changes.html | 10 ++
1 file changed, 10 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 5644de1e..951d005b 100644
---
On Thu, 18 Jan 2024 at 02:48, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Please add PR109536 to the commit message.
>
> -- >8 --
>
> Some _Safe_iterator member functions define a variable of non-literal
> type __gnu_cxx::__scoped_lock, which
Here's the final version that I pushed.
Tested aarch64-linux, x86_64-linux.
commit df0a668b784556fe4317317d58961652d93d53de
Author: Jonathan Wakely
Date: Mon Jan 15 15:42:50 2024
libstdc++: Implement C++26 std::text_encoding (P1885R12) [PR113318]
This is another C++26 change
On Tue, 16 Jan 2024 at 21:28, Jonathan Wakely wrote:
>
> Tested aarch64-linux. I plan to push this to fix an error when using
> trunk with Clang.
Pushed.
>
> -- >8 --
>
> We were relying on P1814R0 (CTAD for alias templates) which isn't
> supported by Clang. We can ju
On Wed, 17 Jan 2024, 08:14 Huanghui Nie via Gcc, wrote:
> Thanks. Done.
>
And don't CC the main gcc@ list, that's not for patch discussion. And if
you CC the right list, you don't need to CC the individual maintainers.
Anyway, it's on the right list now so we'll review it there, thanks.
>
On Wed, 17 Jan 2024 at 02:41, Patrick Palka wrote:
>
> Similar to the previous change for , but since stl_pair.h is an
> internal header we need to use the corresponding internal macro instead.
OK thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_pair.h [__cplusplus > 202002L]:
On Wed, 17 Jan 2024 at 02:40, Patrick Palka wrote:
>
> Guard additions from P2321R2 zip with __cpp_lib_ranges_zip
> instead of __cplusplus > 202020L.
Ah yes, I should have changed all of these in r14-7225-gf8a5298c97c460
OK for trunk, thanks.
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 17 Jan 2024 at 00:31, Jason Merrill wrote:
>
> On 1/10/24 04:22, Ken Matsui wrote:
> > +/* Return true if T is an integral type. With __STRICT_ANSI__, __int128
> > and
> > + unsigned __int128 are not integral types. */
>
> This really needs a rationale, since they are actually integer
On Wed, 17 Jan 2024, 02:37 Patrick Palka, wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
OK
> -- >8 --
>
> This compile-time and diagnostic improvement[1] is less important in
> C++23 mode where deducing this is available and used in _Pipe, but for
> benefit of C++20
Tested aarch64-linux. I plan to push this to fix an error when using
trunk with Clang.
-- >8 --
We were relying on P1814R0 (CTAD for alias templates) which isn't
supported by Clang. We can just not use CTAD and provide an explicit
template argument list for _Utf32_view.
Ideally we'd define a
On Tue, 16 Jan 2024 at 15:39, Jonathan Wakely wrote:
>
> On Tue, 16 Jan 2024 at 14:07, Jonathan Wakely wrote:
> >
> > On 15/01/24 19:09 -0500, Patrick Palka wrote:
> > >> +friend _Iterator
> > >> +operator+(_Iterator __i, difference_type __n)
On Tue, 16 Jan 2024 at 14:07, Jonathan Wakely wrote:
>
> On 15/01/24 19:09 -0500, Patrick Palka wrote:
> >> +friend _Iterator
> >> +operator+(_Iterator __i, difference_type __n)
> >
> >constexpr?
>
> Fixed. I've added tests that all iterator ops a
On Tue, 16 Jan 2024 at 14:39, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
Oh! I thought this went in as part of the original cartesian_product
commit. I would have asked you to do it at the same time otherwise,
sorry.
Yes, OK for trunk and gcc-13,
On 15/01/24 19:09 -0500, Patrick Palka wrote:
On Mon, 15 Jan 2024, Jonathan Wakely wrote:
I think I'm happy with this now. It has tests for all the new functions,
and the performance of the charset alias match algorithm is improved by
reusing part of .
Tested x86_64-linux.
-- &g
I think I'm happy with this now. It has tests for all the new functions,
and the performance of the charset alias match algorithm is improved by
reusing part of .
Tested x86_64-linux.
-- >8 --
This is another C++26 change, approved in Varna 2022. We require a new
static array of data that is
On Mon, 15 Jan 2024 at 19:32, Patrick Palka wrote:
>
> On Sun, Jan 7, 2024 at 3:33 PM Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> Ping.
Huh, I thought I'd already approved this ... sorry.
OK for trunk, with the -ftemplate-depth test change too.
On Mon, 15 Jan 2024 at 18:50, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
OK for both, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_iterator.h (const_iterator): Define
> conversion operators as per P2836R1.
> *
On Mon, 15 Jan 2024 at 16:51, Jonathan Wakely wrote:
>
> On Mon, 15 Jan 2024 at 16:27, Patrick Palka wrote:
> >
> > On Sat, 13 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Sat, 13 Jan 2024 at 00:06, Patrick Palka wrote:
> > > >
>
Tested x86_64-linux. Pushed to trunk.
-- >8 --
There's an error for -fconcepts-ts due to using a concept where a bool
NTTP is required, which is fixed by using the vraiable template that
already exists in the class scope.
This doesn't fix the problem with -fconcepts-ts as changes to the
On Sat, 13 Jan 2024 at 11:18, Jonathan Wakely wrote:
>
> On Fri, 12 Jan 2024 at 22:59, Jonathan Wakely wrote:
> >
> > It would be good to update the bundled tzdata for GCC 14.1 and 13.3
>
> The expiry date for the hardcoded leapseconds list should be updated
>
On Mon, 15 Jan 2024 at 16:27, Patrick Palka wrote:
>
> On Sat, 13 Jan 2024, Jonathan Wakely wrote:
>
> > On Sat, 13 Jan 2024 at 00:06, Patrick Palka wrote:
> > >
> > > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> > >
> > > &
On Sun, 14 Jan 2024, 01:36 Julia DeMille, wrote:
> On 1/13/24 19:17, Andrew Pinski wrote:
> > 2 things, changelogs go into the email message rather than directly as
> > part of the patch.,
>
The reason for this is that the ChangeLog files are auto-generated from the
git commit messages, not
Patch v2, with more tests. This fixes a bug in lookup by name where if
an alias was matched then the aliases() view wouldn't contain the
primary name or other aliases earlier in the table.
It also optimizes text_encoding::environment_is so it constructs an
encoding by ID and then only matches the
On Sat, 13 Jan 2024 at 09:36, Pilar Latiesa wrote:
>
> Hi Jonathan
>
> Thanks so much for implementing this.
>
> There are a couple of typos in the patch description:
> 's/C==17RandomAccessIterator/Cpp17RandomAccessIterator/' and
> 's/__or_/__and_/'.
Thanks for the comments, I'll fix those.
>
On Fri, 12 Jan 2024 at 22:59, Jonathan Wakely wrote:
>
> It would be good to update the bundled tzdata for GCC 14.1 and 13.3
The expiry date for the hardcoded leapseconds list should be updated
too, as there's a new date in the file in the tzdata distro. There are
no new leap seconds though
On Sat, 13 Jan 2024 at 00:06, Patrick Palka wrote:
>
> On Fri, 12 Jan 2024, Jonathan Wakely wrote:
>
> > On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
> > >
> > > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> > >
> > > &
On Fri, 12 Jan 2024 at 18:11, Patrick Palka wrote:
>
> On Thu, 11 Jan 2024, Jonathan Wakely wrote:
>
> > Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only.
> >
> > Reviews requested.
> >
> > -- >8 --
> >
> > This is a step
On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
>
> On Fri, 12 Jan 2024, Jonathan Wakely wrote:
>
> > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
> > >
> > > On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> > >
> > > > I'd like
It would be good to update the bundled tzdata for GCC 14.1 and 13.3
Tested x86_64-linux.
Any objections?
-- >8 --
Import the new 2023d tzdata.zi file.
libstdc++-v3/ChangeLog:
* src/c++20/tzdata.zi: Import new file from 2023d release.
---
libstdc++-v3/src/c++20/tzdata.zi | 23
Here's a partial patch for PR libstdc++/113318 to implement another
C++26 feature: https://wg21.link/p1885r12
I'm writing the rest of the tests, but thought I would post it now for
comments on the general approach.
The text_encoding class is basically just a pointer to an {ID,name} pair
in the
On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
>
> On Fri, 12 Jan 2024, Jonathan Wakely wrote:
>
> > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
> > >
> > > On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> > >
> > > > I'd like
On Fri, 12 Jan 2024 at 20:10, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK
>
> PR libstdc++/108827
> PR libstdc++/111327
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (bind_back): Define.
> *
On Fri, 12 Jan 2024 at 20:09, Patrick Palka wrote:
>
> This simplifies the operator() of _Bind_front using C++23 deducing
> this, allowing us to condense multiple nearly identical operator()
> overloads into one.
>
> In passing I think we can remove _Bind_front's defaulted special member
>
On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
>
> On Thu, 11 Jan 2024, Jonathan Wakely wrote:
>
> > I'd like to commit this to trunk for GCC 14. Please take a look.
> >
> > -- >8 --
> >
> > This is the last part of PR libstdc++/108822 implement
On Thu, 11 Jan 2024 at 22:17, Jonathan Wakely wrote:
>
> I'd like to commit this to trunk for GCC 14. Please take a look.
>
> -- >8 --
>
> This is the last part of PR libstdc++/108822 implementing P2255R2, which
> makes it ill-formed to create a std::tuple tha
On Fri, 12 Jan 2024 at 06:53, Daniel Krügler wrote:
>
> Am Do., 11. Jan. 2024 um 21:23 Uhr schrieb Jonathan Wakely
> :
> >
> > Tested x86_64-linux. Does this look better now?
>
> Yes, thank you.
Thanks, pushed.
Tested aarch64-linux, pushed to trunk.
-- >8 --
This was approved for C++23 at he June 2021 virtual meeting.
This allows more efficient construction of std::pair members when {} is
used as a constructor argument. The perfect forwarding constructor can
be used, so that the member variables are
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/format (__format::_Arg_store): Fix PR number in
comment. Simplify preprocessor code.
---
libstdc++-v3/include/std/format | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
This fixes a regression introduced by the LWG 3809 change, so is needed
on trunk and gcc-13 and gcc-12.
Tested x86_64-linux and aarch64-linux.
-- >8 --
I implemented the resolution of LWG 3809 in r13-4364-ga64775a0edd469 but
more recently it was noted that the change causes possible truncation
On Thu, 11 Jan 2024 at 16:12, Patrick Palka wrote:
>
> On Thu, 11 Jan 2024, Jonathan Wakely wrote:
>
> > On Wed, 10 Jan 2024 at 21:40, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > --
I'd like to commit this to trunk for GCC 14. Please take a look.
-- >8 --
This is the last part of PR libstdc++/108822 implementing P2255R2, which
makes it ill-formed to create a std::tuple that would bind a reference
to a temporary.
The dangling checks are implemented as deleted constructors
And a follow-up to fix the obvious typo in the first word.
Pushed to trunk and gcc-13.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/evolution.xml: Fix spelling.
* doc/html/manual/api.html: Regenerate.
---
libstdc++-v3/doc/html/manual/api.html | 6 --
Tested x86_64-linux. Does this look better now?
It also fixes PR113320 that got reported.
-- >8 --
I seem to have implemented this feature based on the P2918R0 revision,
not the final P2918R2 one that was approved for C++26. This commit fixes
it.
The runtime-format-string type should not have
Pushed to trunk. I'll backport to gcc-13 too.
-- >8 --
The API Evolution section of the manual should mention when the
libstdc++exp.a library was added.
libstdc++-v3/ChangeLog:
* doc/xml/manual/evolution.xml: Document addition of
libstdc++exp.a.
* doc/html/*:
On Wed, 10 Jan 2024 at 23:31, Jonathan Wakely wrote:
>
> On Wed, 10 Jan 2024 at 21:28, Michael Levine (BLOOMBERG/ 120 PARK)
> wrote:
> >
> > From a67cfd07ce27a62f764b381268502acb68b6bad9 Mon Sep 17 00:00:00 2001
> > From: Michael Levine
> > Date: Wed, 10 Ja
201 - 300 of 9534 matches
Mail list logo
