Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only.
Reviews requested.
-- >8 --
This is a step towards implementing the C++23 change P2408R5, "Ranges
iterators as inputs to non-Ranges algorithms". C++20 random access
iterators which do not meet the C==17RandomAccessIterator
On Wed, 10 Jan 2024 at 18:28, François Dumont wrote:
>
> libstdc++: [_GLIBCXX_DEBUG] Fix assignment of value-initialized iterator
> [PR112477]
>
> Now that _M_Detach do not reset iterator _M_version value we need to
> reset it when
> the iterator is attached to a new sequence. Even if this
I was finding it frustrating when returning from a function in GDB and
the return value was shown as $1 = { }, so this makes it
print std::true_type or std::false_type.
There are some contexts where the output isn't ideal, e.g. a type
derived from std::true_type will now show something like:
$2
On Tue, 9 Jan 2024 at 22:00, Jonathan Wakely wrote:
>
> Does anybody see any problem with making this change, so that we avoid
> the problem described in the PR?
Pushed to trunk. We should backport this too.
>
> -- >8 --
>
> As described in PR libstdc++/113258 there are
On Thu, 11 Jan 2024 at 16:04, Marcus Hähnel wrote:
>
> Forwarding since I forgot to add gcc-patches in the original mail.
> Sorry for the noise.
And I forgot about this one, so thanks for the ping. I'll push it.
>
> -- >8 --
>
> Commit f4130a3eb545ab1aaf3ecb44f3d06b43e3751e04 changed the type
On Thu, 11 Jan 2024 at 00:26, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK. Nice to see explicit object functions landing in the library so soon!
>
> -- >8 --
>
> This simplifies the operator() of the _Pipe and _Partial range adaptor
> closure objects
On Wed, 10 Jan 2024 at 21:40, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> This avoids redundant moves when composing and partially applying range
> adaptor objects.
>
> Note that the new constraints on _Partial's constructor templates are
On Wed, 13 Sept 2023 at 21:50, Jonathan Wakely wrote:
>
> On Wed, 13 Sept 2023 at 21:47, François Dumont wrote:
> >
> > It's working and what's I've committed.
>
> Nice, thanks!
>
>
> >
> > Thanks
> >
> > On 12/09/2023 19:04, Jonathan Wakel
The first two paragraphs are cloned from existing text for other point
releases. The third paragraph documents a recent backport that should be
called out in the release notes.
Pushed to wwwdocs.
---
htdocs/gcc-13/changes.html | 26 ++
1 file changed, 26 insertions(+)
Some failures related to std::find_if and stdint types were observed
doing mass rebuilds with GCC 14.
Pushed to wwwdocs.
---
htdocs/gcc-14/porting_to.html | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index
On Thu, 11 Jan 2024 at 12:23, Ken Matsui wrote:
>
> On Thu, Jan 11, 2024 at 3:45 AM Ken Matsui wrote:
> >
> > On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely wrote:
> > > On Thu, 11 Jan 2024 at 10:56, Ken Matsui wrote:
> > > >
> > > > On Thu, 11
On Thu, 11 Jan 2024 at 10:50, Jonathan Wakely wrote:
>
> On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
> >
> > On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
> > >On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
> &
On Thu, 11 Jan 2024 at 11:28, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 10:50, Jonathan Wakely wrote:
> > On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
> > >
> > > On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely
> > > wrote:
> > > >
On Thu, 11 Jan 2024 at 10:56, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely wrote:
> > On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
> > >
> > > This patch made std::filesystem::equivalent correctly throw an exception
> > >
On Thu, 11 Jan 2024 at 10:12, Ken Matsui wrote:
>
> On Thu, 11 Jan 2024 at 09:55, Jonathan Wakely wrote:
> >On Thu, 11 Jan 2024, 09:43 Ken Matsui, <[1]kmat...@gcc.gnu.org> wrote:
> >
> >> libstdc++-v3/ChangeLog:
> >
> >> * sr
On Thu, 11 Jan 2024 at 09:43, Ken Matsui wrote:
>
> This patch made std::filesystem::equivalent correctly throw an exception
> when either path does not exist as per [fs.op.equivalent]/4.
Thanks, OK for trunk and all active branches (let me know if you need
help backporting it).
>
>
On Thu, 11 Jan 2024, 09:43 Ken Matsui, wrote:
> libstdc++-v3/ChangeLog:
>
> * src/filesystem/ops-common.h (stat_type): Use using.
>
> Signed-off-by: Ken Matsui
> ---
> libstdc++-v3/src/filesystem/ops-common.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
rib/ChangeLog
> index 04bde02b65b..11c9c1178bc 100644
> --- a/contrib/ChangeLog
> +++ b/contrib/ChangeLog
> @@ -1,3 +1,8 @@
> +2024-01-10 Michael Levine
> +
> + * libstdc++-v3/include/std/ranges: Remove a duplicate define directive
> + for __glibcxx_want_ranges_iota.
> +
On Wed, 10 Jan 2024 at 22:08, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK (thanks, this was on my TODO list).
> -- >8 --
>
> Since _Nth_type has a fallback native implementation, use
> _GLIBCXX_USE_BUILTIN_TRAIT when deciding whether
On Wed, 10 Jan 2024 at 19:47, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_scalar
> by dispatching to the new __is_scalar built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:47, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_signed
> by dispatching to the new __is_signed built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:41, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_unsigned
> by dispatching to the new __is_unsigned built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 19:41, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_compound
> by dispatching to the new __is_arithmetic built-in trait.
OK for trunk (no need to wait for anything else to be approved).
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 10 Jan 2024 at 19:47, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_arithmetic
> by dispatching to the new __is_arithmetic built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 10 Jan 2024 at 19:43, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of
> std::is_floating_point by dispatching to the new
> __is_floating_point built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 10 Jan 2024 at 19:48, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_integral
> by dispatching to the new __is_integral built-in trait.
OK for trunk (if the new built-in gets approved).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits
On Wed, 10 Jan 2024 at 18:33, Daniel Krügler wrote:
>
> Am Mo., 8. Jan. 2024 um 03:25 Uhr schrieb Jonathan Wakely
> :
> >
> > Tested x86_64-linux and aarch64-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > This adds std::runtime_format for C
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Fix some copy & pasted logic in __is_extended_pictographic. This
function should yield false for the values before the first edge, not
true. Also add a missing boundary condition check in __incb_property.
Also Fix an off-by-one error in
On Tue, 9 Jan 2024 at 21:47, Andreas Schwab wrote:
>
> Tighten the regex to find the start of the .dynsym symtab in the readelf
> output to avoid matching the section symbol in the normal symtab.
OK, thanks.
>
> libstdc++-v3:
> * scripts/extract_symvers.in: Require final colon to only
Does anybody see any problem with making this change, so that we avoid
the problem described in the PR?
-- >8 --
As described in PR libstdc++/113258 there are old versions of tcmalloc
which replace malloc and related APIs, but do not repalce aligned_alloc
because it didn't exist at the time they
Tested aarch64-linux. Pushed to trunk.
-- >8 --
I don't remember exactly why I made these bits of code reserve space in
a COW string and append to it, rather than just use the string returned
from std::format (which will undergo copy elision). The _Str_sink type
used by std::format means the
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
already did that for trunk with r14-3812-gb96b554592c5cb and trunk no
longer installs
On Mon, 8 Jan 2024 at 01:19, Jonathan Wakely wrote:
>
> I decided to push this now, not wait for the morning.
>
> This is mostly the same as V2, but adds to the contrib/unicode/README as
> suggested by Lewis, and avoids a trailing whitespace character in the
> generated header.
On Mon, 8 Jan 2024 at 16:25, Hans-Peter Nilsson wrote:
>
> (Sorry, never a bringer of good news...)
Regarding this bit ... even if you're reporting something I've broken,
I like to see it as an incremental step towards better portability, so
it's always good news ;-)
On Mon, 8 Jan 2024 at 16:28, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Mon, 8 Jan 2024 17:24:35 +0100
>
> > For some reason, this (r14-6990-g74a0dab18292be) breaks a
> > build of (newlib targets) at least cris-elf and arm-eabi:
>
> ...aaand, just now fixed in
Tested x86_64-linux, pushed to trunk.
-- >8 --
The name __null_sentinel is defined as a macro by newlib, so we can't
use it as an identifier. That variable is not actually used by
libstdc++, it was added because P2728R6 proposes std::uc::null_sentinel.
Since we don't need it and it breaks
On Mon, 8 Jan 2024 at 01:22, Jonathan Wakely wrote:
>
> On Mon, 8 Jan 2024 at 01:13, Jonathan Wakely wrote:
> >
> > This V2 patch failed CI:
> > https://patchwork.sourceware.org/project/gcc/patch/20240106151802.3356059-1-jwak...@redhat.com/
> >
> > But
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This change makes std::make_format_args refuse to create dangling
references to temporaries. This makes the std::vformat API safer. This
was approved in Kona 2023 as a DR for C++20 so the change is implemented
unconditionally.
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This adds std::runtime_format for C++26. These new overloaded functions
enhance the std::format API so that it isn't necessary to use the less
ergonomic std::vformat and std::make_format_args (which are meant to be
implementation
Tested x86_64-linux and aarch64-linux. Pushed to trunk.
-- >8 --
This change ensures that char and wchar_t arguments are formatted
consistently when using integer presentation types. This avoids
non-portable std::format output that depends on whether char and wchar_t
happen to be signed or
On Sun, 7 Jan 2024 at 18:50, François Dumont wrote:
>
>
> On 07/01/2024 17:34, Jonathan Wakely wrote:
> > On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
> >> Hi
> >>
> >> While working on the patch to use the cxx11 abi in gnu version
On Sun, 7 Jan 2024 at 16:40, Patrick Palka wrote:
>
> On Tue, 5 Dec 2023, Jonathan Wakely wrote:
>
> > On Wed, 22 Nov 2023 at 14:50, Jonathan Wakely wrote:
> > >
> > > On Mon, 20 Nov 2023 at 02:56, Jason Merrill wrote:
> > > >
> > > > T
On Sun, 7 Jan 2024 at 12:57, François Dumont wrote:
>
> Hi
>
> While working on the patch to use the cxx11 abi in gnu version namespace
> mode I got a small problem with this missing constructor. I'm not sure
> that the main patch will be integrated in gcc 14 so I think it is better
> if I
Tested x86_64-linux. Pushed to trunk.
-- >8 --
r14-1527-g2415024e0f81f8 changed the parameter of the
__cxa_call_terminate definition, but there's also a declaration in
unwind-cxx.h which should have been changed too.
libstdc++-v3/ChangeLog:
PR libstdc++/112997
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As the comment notes, the increased timeout was needed because of PR
102780, but that was fixed long ago.
libstdc++-v3/ChangeLog:
* testsuite/20_util/variant/87619.cc: Remove dg-timeout-factor.
---
Pushed to trunk now.
On Thu, 14 Dec 2023 at 01:09, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Does this look right? Can we do it faster, or simplify it?
>
> -- >8 --
>
> This reduces the overhead of using std::is_trivially_destructible_v and
> as a result
On Sat, 6 Jan 2024 at 17:03, Jonathan Wakely wrote:
>
> On Sat, 6 Jan 2024 at 16:57, Lewis Hyatt wrote:
> >
> > On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote:
> > >
> > > Here's a V2 patch which addresses the two things I mentioned: the new
> >
On Sat, 6 Jan 2024 at 16:57, Lewis Hyatt wrote:
>
> On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote:
> >
> > Here's a V2 patch which addresses the two things I mentioned: the new
> > Python script now generates a complete file that can just be included by
> >
On Fri, 5 Jan 2024 at 14:12, Jonathan Wakely wrote:
>
> On 06/12/23 15:34 +0100, Gwenole Beauchesne wrote:
> >Tested on x86_64-pc-linux-gnu with --enable-languages=c,c++ and
> >additional -Wformat to CXXFLAGS.
>
> Please CC the libstd...@gcc.gnu.org list on all libstdc++
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This prevents a std::filesystem::path from exceeding INT_MAX/4
components (which is unlikely to ever be a problem except on 16-bit
targets). That limit ensures that the capacity*1.5 calculation doesn't
overflow. We should also check that we don't
Tested x86_64-linux. Pushed to trunk, backport to gcc-13 needed too.
-- >8 --
The new __is_convertible built-in should only be used after checking
that it's supported.
libstdc++-v3/ChangeLog:
PR libstdc++/113241
* include/std/type_traits (is_convertible_v): Guard use of
On 06/12/23 15:34 +0100, Gwenole Beauchesne wrote:
Tested on x86_64-pc-linux-gnu with --enable-languages=c,c++ and
additional -Wformat to CXXFLAGS.
Please CC the libstd...@gcc.gnu.org list on all libstdc++ patches, as
documented at https://gcc.gnu.org/lists.html
Otherwise I won't see the
On Fri, 5 Jan 2024 at 13:00, Martin Küttler
wrote:
>
>
> >>This is a small change to libstdc++ which does not change any behavior.
> >
> > Please CC the libstd...@gcc.gnu.org list on all libstdc++ patches, as
> > documented at https://gcc.gnu.org/lists.html
>
> Acknowledged. Sorry.
>
> >>This
On 18/12/23 09:36 +0100, Martin Küttler wrote:
This is a small change to libstdc++ which does not change any behavior.
Please CC the libstd...@gcc.gnu.org list on all libstdc++ patches, as
documented at https://gcc.gnu.org/lists.html
Otherwise I won't see the patches unless I happen to glance
Tested x86_64-linux. Pushed to trunk. Backports needed too.
-- >8 --
The current constexpr implementation of std::char_traits::move relies
on being able to compare the pointer parameters, which is not allowed
for unrelated pointers. We can use __builtin_constant_p to determine
whether it's safe
From: Cassio Neri
Tested x86_64-linux. Pushed to trunk.
This seems suitable for backporting too, at least to gcc-13.
-- >8 --
The following invoke signed integer overflow (UB) [1]:
month + months{MAX} // where MAX is the maximum value of months::rep
month + months{MIN} // where MIN
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As noted in the PR, we can use if-constexpr for the explicit
instantantiation definitions that are compiled with -std=gnu++11. We
just need to disable the -Wc++17-extensions diagnostics.
libstdc++-v3/ChangeLog:
PR libstdc++/113099
gt; __is_pointer built-in trait. Optimize its implementation.
> * include/std/type_traits (is_pointer): Likewise.
> (is_pointer_v): Likewise.
>
> Co-authored-by: Jonathan Wakely
> Signed-off-by: Ken Matsui
> ---
> libstdc++-v3/include/bits/cpp_type_traits.
built-in traits in the type_traits header through
> _GLIBCXX_DO_NOT_USE_BUILTIN_TRAITS macro, without needing to modify the
> source code.
OK for trunk, thanks.
+Reviewed-by: Jonathan Wakely
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits: Use _GLIBCXX_USE_BUIL
I plan to push this as obvious.
There are also 32 other files that match "^# .*licenses/>\. *\*/$" in
the repo, mostly .exp files in the testsuite. I'm not changing them,
only the Python files under contrib.
-- >8 --
These Python scripts have "*/" at the end of the license header comment
I intend to commit this as obvious later today.
-- >8 --
contrib/ChangeLog:
* unicode/gen_wcwidth.py: Add sys.argv[0] to usage error.
---
contrib/unicode/gen_wcwidth.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/unicode/gen_wcwidth.py
On Thu, 4 Jan 2024 at 12:01, Arsen Arsenović wrote:
>
>
> Jonathan Wakely writes:
>
> > On Thu, 21 Dec 2023 at 21:26, Arsen Arsenović wrote:
> >> +
> >> +template
> >> +concept _Stateless_alloc =
>
On Thu, 21 Dec 2023 at 21:26, Arsen Arsenović wrote:
> +
> +template
> +concept _Stateless_alloc = (allocator_traits<_A>::is_always_equal::value
> + && default_initializable<_A>);
The _A here is a BADNAME and needs to be more than one letter.
FAIL:
On Tue, 2 Jan 2024, 17:49 Patrick Palka, wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and release
> branches (r14-205 was backported everywhere)?
>
Yes, thanks.
> -- >8 --
>
> The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
> inadvertently increased the
On Sat, 30 Dec 2023, 01:41 Hans-Peter Nilsson, wrote:
> I'm not completely sure I got the intent of the "log2_limit",
> or whether "limit" is sane to decrease like this; it just
> looked like an obvious and safe reduction. Also, I verified
> the 10+ minute runtime, on this same host (clocked at
On Sat, 30 Dec 2023, 01:24 Hans-Peter Nilsson, wrote:
> Tested for mmix and observing the increased timeout in the .log
> file - and the test passing.
>
> Ok to commit? Or better suggestions?
>
OK to commit, thanks.
> -- >8 --
> Testing for mmix (a 64-bit target using Knuth's simulator).
On Thu, 23 Nov 2023 at 22:00, François Dumont wrote:
>
> libstdc++: [_Hashtable] Extend the small size optimization
>
> A number of methods were still not using the small size
> optimization which
> is to prefer an O(N) research to a hash computation as long as N is
> small.
>
>
On Thu, 23 Nov 2023 at 21:59, François Dumont wrote:
>
> libstdc++: [_Hashtable] Avoid redundant usage of rehash policy
>
> Bypass call to __detail::__distance_fwd and the check if rehash is
> needed when
> assigning an initializer_list to an unordered_multimap or
>
On Thu, 23 Nov 2023 at 21:59, François Dumont wrote:
>
> libstdc++: [_Hashtable] Fix some implementation inconsistencies
>
> Get rid of the different usages of the mutable keyword. For
> _Prime_rehash_policy methods are exported from the library, we need to
> keep their const
On Thu, 23 Nov 2023 at 21:58, François Dumont wrote:
>
> libstdc++: [_Hashtable] Enhance/Add performance benches
This one is OK for trunk now, thanks.
I think this should wait for the next stage 1. It's a big patch
affecting the default -std mode (not just experimental C++20/23/26
material), and was first posted after the end of stage 1.
Do we really need the changes for versioned namespace? How much
difference does that extra member make to
On Thu, 21 Dec 2023 at 21:26, Arsen Arsenović wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/Makefile.am: Install std/generator, bits/elements_of.h
> as freestanding.
> * include/Makefile.in: Regenerate.
> * include/bits/version.def: Add __cpp_lib_generator.
>
On Thu, 21 Dec 2023 at 21:26, Arsen Arsenović wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_util.h: Add missing
> include.
OK
> ---
> libstdc++-v3/include/bits/ranges_util.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On Sun, 17 Dec 2023 at 15:38, Florian Weimer wrote:
>
> This matches other compiler diagnostics. No test updates are needed
> because c-c++-common/pr95378.c does not match a specific -W option.
>
> Fixes commit d2384b7b24f8557b66f6958a05ea99ff4307e75c ("c-family:
> check qualifiers of arguments
On Sun, 17 Dec 2023 at 00:02, Jonathan Wakely wrote:
>
> On Sat, 16 Dec 2023 at 23:06, David Edelsohn wrote:
> >
> > On Sat, Dec 16, 2023 at 4:44 PM Jakub Jelinek wrote:
> >>
> >> On Sat, Dec 16, 2023 at 04:24:13PM -0500, David Edelsohn wrote:
> >
Tested x86_64-linux (and built on AIX). Pushed to trunk.
-- >8 --
On AIX fileno is a function-like macro, so enclose the name in
parentheses to ensure we use the real function.
libstdc++-v3/ChangeLog:
* src/c++23/print.cc (__open_terminal(FILE*)): Avoid fileno
macro.
---
On Sat, 16 Dec 2023 at 23:06, David Edelsohn wrote:
>
> On Sat, Dec 16, 2023 at 4:44 PM Jakub Jelinek wrote:
>>
>> On Sat, Dec 16, 2023 at 04:24:13PM -0500, David Edelsohn wrote:
>> > AIX stdio.h defines fileno as a macro although there is a symbol in libc.
>> >
>> > I think that print.cc at
Pushed to wwwdocs.
-- >8 --
---
htdocs/gcc-14/porting_to.html | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index dea9ac80..3e4cedc3 100644
--- a/htdocs/gcc-14/porting_to.html
+++
Pushed to wwwdocs.
-- >8 --
---
htdocs/gcc-14/changes.html | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 346785a0..eb14e09d 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
ry patches for library folks to apply.
I've reviewed all the library patches in v26 and they are all OK for
trunk. Please push (or Patrick can do so).
Thanks, Ken! Great work, I'm really happy to see this land in GCC trunk.
+Reviewed-by: Jonathan Wakely
On Sat, 16 Dec 2023 at 16:26, Patrick Palka wrote:
>
> On Sat, 16 Dec 2023, Jonathan Wakely wrote:
>
> > On Sat, 16 Dec 2023 at 09:14, Jonathan Wakely wrote:
> > >
> > > On Sat, 16 Dec 2023 at 00:27, Patrick Palka wrote:
> > > >
>
On Sat, 16 Dec 2023 at 09:14, Jonathan Wakely wrote:
>
> On Sat, 16 Dec 2023 at 00:27, Patrick Palka wrote:
> >
> > On Wed, 6 Dec 2023, Jonathan Wakely wrote:
> >
> > > Any comments on this approach?
> > >
> > > -- >8 --
> > >
> >
On Sat, 16 Dec 2023 at 00:27, Patrick Palka wrote:
>
> On Wed, 6 Dec 2023, Jonathan Wakely wrote:
>
> > Any comments on this approach?
> >
> > -- >8 --
> >
> > This makes constexpr std::vector (mostly) work in Debug Mode. All safe
> > iterator
On Fri, 15 Dec 2023 at 14:49, Tim Song wrote:
>
>
>
> On Fri, Dec 15, 2023 at 4:43 AM Jonathan Wakely wrote:
>>
>> On Fri, 15 Dec 2023 at 01:17, Tim Song wrote:
>> >
>> > On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely wrote:
>> >>
Tested x86_64-linux and x86_64-w64-mingw. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* src/c++23/print.cc (__write_to_terminal) [_WIN32]: If handle
does not refer to the console then just write to it using normal
file I/O.
* testsuite/27_io/print/2.cc
Tested x86_64-linux and x86_64-w64-mingw. Pushed to trunk.
-- >8 --
Since we don't need to do anything special to print Unicode on
non-Windows targets, we might as well just use std::vprint_nonunicode to
implement std::vprint_unicode. Removing the duplicated code should
reduce code size in cases
Tested x86_64-linux and x86_64-w64-mingw. Pushed to trunk.
-- >8 --
Tim Song pointed out that although std::print behaves as a formatted
output function, it does "determine padding" using the stream's flags.
libstdc++-v3/ChangeLog:
* include/std/ostream (vprint_nonunicode,
On Fri, 15 Dec 2023 at 01:17, Tim Song wrote:
>
> On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely wrote:
>> + inline void
>> + vprint_unicode(ostream& __os, string_view __fmt, format_args __args)
>> + {
>> +ostream::sentry __cerb(__os);
>> +if (_
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This adds the C++23 std::print functions, which use std::format to write
to a FILE stream or std::ostream (defaulting to stdout).
The new extern symbols are in the libstdc++exp.a archive, so we aren't
committing to stable symbols in the DSO yet.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_CHECK_FILEBUF_NATIVE_HANDLES): Add
missing header to configure test. Check correct variable.
* config/io/basic_file_stdio.cc (__basic_file::native_handle):
Fix typo.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Fix an incorrect call to _Sink::_M_reserve() which should have passed
the __n parameter. This was not actually a problem because it was in an
discarded statement, because only the _Seq_sink>
specialization was used.
Also add some branch prediction
Tested x86_64-linux. Pushed to trunk. Backport needed too.
-- >8 --
I got the order of arguments to std::format_to wrong. It was in a
discarded statement, for a case which wasn't being tested.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono::_M_S): Fix order
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These tests are expected to run interactively, with the output checked
by eye. Nobody ever does that, but we can at least use dg-output to
check that the output is as expected.
libstdc++-v3/ChangeLog:
* testsuite/27_io/objects/char/2.cc:
On Wed, 6 Dec 2023 at 14:30, Jonathan Wakely wrote:
>
> Any comments on this approach?
Pushed to trunk now.
>
> -- >8 --
>
> This makes constexpr std::vector (mostly) work in Debug Mode. All safe
> iterator instrumentation and checking is disabled during consta
Tested x86_64-linux.
Does this look right? Can we do it faster, or simplify it?
-- >8 --
This reduces the overhead of using std::is_trivially_destructible_v and
as a result fixes some recent regressions seen with a non-default
GLIBCXX_TESTSUITE_STDS env var:
FAIL: 20_util/variant/87619.cc
On Wed, 13 Dec 2023 at 10:51, haochen.jiang
wrote:
>
> On Linux/x86_64,
>
> a01462ae8bafa86e7df47a252917ba6899d587cf is the first bad commit
> commit a01462ae8bafa86e7df47a252917ba6899d587cf
> Author: Jonathan Wakely
> Date: Mon Dec 11 15:33:59 2023 +
>
>
It seems that what I pushed didn't match what I tested, due to testing
on a different machine!
Tested x86_64-linux, on the right machine this time. Pushed to trunk.
-- >8 --
The change in r14-6468-ga01462ae8bafa8 was only supposed to apply to %C
formats, not %Y.
libstdc++-v3/ChangeLog:
Tested x86_64-linux. Pushed to trunk.
-- >8--
When I added a fast path for std::format("{}", x) in
r14-5587-g41a5ea4cab2c59 I forgot to handle char separately from other
integral types. That caused std::format("{}", 'c') to return "99"
instead of "c".
libstdc++-v3/ChangeLog:
*
Tested x86_64-linux. Pushed to trunk.
-- >8--
During discussion of LWG 4022 I noticed that we do not correctly
implement floored division for the century. We were just truncating
towards zero, rather than applying the floor function. For negative
values that rounds the wrong way.
Tested x86_64-linux. Pushed to trunk.
-- >8--
In r14-4060-gc4baeaecbbf7d0 I moved some files from src/c++98 to
src/c++11 but I didn't remove the redundant -std=gnu++11 flags for those
files. The flags aren't needed now, because AM_CXXFLAGS for that
directory already uses -std=gnu++11. This
301 - 400 of 9534 matches
Mail list logo
