On Fri, 19 Sep 2025, Jonathan Wakely wrote:
> This was reported as LWG 4257 and moved to Tentatively Ready status.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/chrono_io.h: Remove unused header.
> (operator<<): Constrain overload for chrono::local_time.
> * testsuite/std/tim
On Mon, 15 Sep 2025, Eczbek wrote:
> From d70ac2b0a7b524829d22b3bb6bacbe1ef381c7fb Mon Sep 17 00:00:00 2001
> From: Eczbek
> Date: Mon, 15 Sep 2025 19:37:20 -0400
> Subject: [PATCH] c++: Fix lambdas with variadic parameters and static
> specifier [PR119048]
>
> PR c++/119048
>
> gcc/cp/C
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk and eventually backports?
-- >8 --
Here the normal form of the two immediately-declared D<, V>
constraints is the same, so we rightfully share the normal form between
them. However we first normalize the constraint fr
Tested on x86_64-pc-linux-gnu, does thsi look OK for trunk and
perhaps 15/14?
-- >8 --
When running libstdc++ tests using an installed gcc (as opposed to
an in-tree gcc), warnings from within system headers are suppressed,
so tests that check for such warnings need to pass -Wsystem-headers
explic
On Tue, 16 Sep 2025, Jonathan Wakely wrote:
> The r16-3835-g7801236069a95c change to use ranges::iter_move should also
> have used iter_value_t<_Iter> to ensure we get an object of the value
> type, not a proxy reference.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/121913
> * includ
Bootstrapped and regttested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Apparently an explicitly defined operator<=> isn't required to return
std::foo_ordering, so build_min_non_dep_op_overload needs to be able
to handle a (x <=> y) @ 0 expression where the @ resolved to a built
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15/14?
-- >8 --
As in r16-3912-g412a1f78b53709, this fixes some other spots where we
wrongly use a deduced type and non-direct-initialization when intending
to initialize a value type from an iterator's reference type.
PR libstdc
On Wed, 17 Sep 2025, Jonathan Wakely wrote:
> On Wed, 17 Sept 2025 at 15:19, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15/14?
> >
> > -- >8 --
> >
> > As in r16-3912-g412a1f78b53709, this fixes some other spo
On Tue, 16 Sep 2025, Jonathan Wakely wrote:
> The std::tuple_cat function has to determine a std::tuple return type
> from zero or more tuple-like arguments. This uses the __make_tuple class
> template to transform a tuple-like type into a std::tuple, and the
> __combine_tuples class template to c
On Tue, 16 Sep 2025, Jonathan Wakely wrote:
> ranges::adjacent_view::_Iterator::value_type should have been changed by
> r14-8710-g65b4cba9d6a9ff to always produce std::tuple, even for the
> N == 2 views::pairwise specialization.
LGTM. I missed this part of P2165R4 because it didn't use the
__tup
On Fri, 12 Sep 2025, Jonathan Wakely wrote:
> On Thu, 11 Sept 2025 at 22:41, Jonathan Wakely wrote:
> >
> > Whenever we use operator+ or similar operators on random access
> > iterators we need to be careful to use the iterator's difference_type
> > rather than some other integer type. It's no
On Mon, 15 Sep 2025, Jonathan Wakely wrote:
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/119820
> * include/bits/ranges_algo.h (__shuffle_fn): Use
> ranges::distance to get difference type value to add to
> iterator.
> * include/std/format (__formatter_str::_M_format_r
On Mon, 15 Sep 2025, Jonathan Wakely wrote:
> The _GLIBCXX_MAKE_MOVE_ITERATOR macro is needed for code that needs to
> compile as C++98, where it just produces the original iterator. In
> std::uninitialized_move and std::uninitialized_move_n we can just call
> std::make_move_iterator directly.
>
On Fri, 12 Sep 2025, Patrick Palka wrote:
> On Fri, 12 Sep 2025, Jonathan Wakely wrote:
>
> > On Fri, 12 Sept 2025 at 18:39, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > > Patch generated with -w du
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Patch generated with -w due to otherwise noisy whitespace changes.
-- >8 --
The ranges::shuffle optimization, copied from std::shuffle, has a
two-at-a-time PRNG optimization that considers the range of the
PRNG vs the size of the range.
On Thu, 11 Sep 2025, Jonathan Wakely wrote:
> Using std::move(*it) is incorrect for iterators that use proxy refs, we
> should use ranges::iter_move(it) instead.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/121913
> * include/bits/ranges_algo.h (__rotate_fn::operator()): Use
>
On Thu, 11 Sep 2025, Jonathan Wakely wrote:
> Whenever we use operator+ or similar operators on random access
> iterators we need to be careful to use the iterator's difference_type
> rather than some other integer type. It's not guaranteed that an
> expression with an arbitrary integer type, such
On Wed, 10 Sep 2025, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> look OK for trunk?
>
> -- >8 --
>
> Some accessor macros unintentionally accept more kinds of nodes than
> they should, e.g. PACK_EXPANSION_PATTERN accept
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
-- >8 --
Some accessor macros unintentionally accept more kinds of nodes than
they should, e.g. PACK_EXPANSION_PATTERN accepts any EXPR_P node.
gcc/cp/ChangeLog:
* cp-tree.h (PACK_EXPANSION_PATTERN): Assert
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/15?
-- >8 --
We weren't explicitly treating a pack index specifier as a non-deduced
context.
PR c++/121795
gcc/cp/ChangeLog:
* pt.cc (unify) : New non-deduced context
case.
gcc/testsuite/Cha
On Wed, 3 Sep 2025, Tomasz Kamiński wrote:
> This patch refactors ranges::_Partial to be implemented using _Bind_back_t.
> This allows it to benefit from the changes in r16-3398-g250dd5b5604fbc,
> specifically making the closure trivially copyable. Since _Bind_back_t
> already provides an optimiz
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Since this helper (added in r16-3576-g7f7f1878eedd80) is used in the
noexcept-spec of iter_move and iter_swap, it in turn needs an accurate
noexcept-spec.
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::_Itera
On Wed, Sep 3, 2025 at 2:56 PM Harald Anlauf wrote:
>
> Am 03.09.25 um 20:40 schrieb Patrick Palka:
> > On Wed, 3 Sep 2025, Tobias Burnus wrote:
> >
> >>
> >> Hi Andre, hi all,
> >>
> >> Andre Vehreschild wrote:
> >>
> >
On Wed, 3 Sep 2025, Tomasz Kamiński wrote:
> The _Bind_front and _Bind_back class templates are now merged into a single
> _Binder implementation that accepts _Back as a template parameter. This makes
> the bind_back implementation available in C++20 mode, allowing it to be used
> for range adapto
On Wed, 3 Sep 2025, Tobias Burnus wrote:
>
> Hi Andre, hi all,
>
> Andre Vehreschild wrote:
>
> I am experiencing a strange issue with gfortran. Compiling a simple program:
>
> $ cat end.f90
> end
> $ gfortran end.f90 -o end
> f951: Fatal Error: Cannot open pre-included file '\xe0\xd4\xf2,'
>
On Tue, Aug 19, 2025 at 11:23 AM Patrick Palka wrote:
>
> On Wed, 16 Jul 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Tue, Jul 15, 2025 at 6:13 PM Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk onl
On Mon, 1 Sep 2025, Tomasz Kaminski wrote:
>
>
> On Fri, Aug 29, 2025 at 5:23 PM Tomasz Kaminski wrote:
>
> On Fri, Aug 29, 2025 at 5:21 PM Tomasz Kaminski
> wrote:
>
>
> On Fri, Aug 29, 2025 at 5:16 PM Patrick Palka wrote:
> On Fri, 29 A
On Tue, 2 Sep 2025, Jonathan Wakely wrote:
> For the pair(T1, T2) explicit deduction type to decay its arguments as
> intended, we need the pair(const T1&, const T2&) constructor to not be
> used for CTAD. Otherwise we try to instantiate pair without
> decaying, which is ill-formed for function lv
Bootstrapped and regtested on x86_64-cp-linux-gnu, does this look
OK for trunk and eventual backports?
-- >8 --
Here although the local templated variables x and y have the same
reduced constant value, only x's initializer is well-formed as written
since A::m has private access. We correctly rej
On Fri, 29 Aug 2025, Patrick Palka wrote:
> On Fri, 29 Aug 2025, Tomasz Kamiński wrote:
>
> > The changes the _Variadic_union implementation, in a way that the
> > _Unitialized partial specialization for non-trivial types is not
> > necessary.
> >
> > T
On Fri, 29 Aug 2025, Tomasz Kamiński wrote:
> The changes the _Variadic_union implementation, in a way that the
> _Unitialized partial specialization for non-trivial types is not
> necessary.
>
> This is simply done by separating the specialization for
> __trivially_destructible
> being true an
On Thu, 28 Aug 2025, Jonathan Wakely wrote:
> On Thu, 28 Aug 2025 at 14:26, Tomasz Kamiński wrote:
> >
> > This slightly improve the readability of error message, by suggesting
> > that 0 (literal) is expected as argument:
> > invalid conversion from 'int' to 'std::__cmp_cat::__zero_literal*'
>
On Wed, 27 Aug 2025, Jonathan Wakely wrote:
> On Wed, 27 Aug 2025 at 11:05, Tomasz Kamiński wrote:
> >
> > For any minimum value of a signed type, its negation (with wraparound)
> > results
> > in the same value, behaving like zero. Representing the unordered result
> > with
> > this minimum va
On Tue, 26 Aug 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Aug 26, 2025 at 5:50 PM Patrick Palka wrote:
> On Tue, 26 Aug 2025, Jonathan Wakely wrote:
>
> > On 20/08/25 10:13 +0200, Tomasz Kamiński wrote:
> > > This patch refactors the im
On Tue, 26 Aug 2025, Jonathan Wakely wrote:
> On 20/08/25 10:13 +0200, Tomasz Kamiński wrote:
> > This patch refactors the implementation of bind_front and bind_back to
> > avoid using std::tuple for argument storage. Instead, bound arguments are
> > now:
> > * stored directly if there is only one
On Wed, 20 Aug 2025, Tomasz Kamiński wrote:
> This patch adjusts the implementation of bind_front(f) and bind_back(f)
> (with zero bound arguments), so it returns an auto(f) (a copy of the
> functor), rather than a specialization of Bind_front/Bind_back. This change
> is mostly unobservable, as st
On Tue, 19 Aug 2025, Tomasz Kamiński wrote:
> Previously, an empty functor (EmptyIdFunc) stored inside a
> std::move_only_function being first member of a Composite class could have the
> same address as the base of the EmptyIdFunc type (see included test cases),
> resulting in two objects of the
On Tue, 26 Aug 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Aug 26, 2025 at 3:54 PM Patrick Palka wrote:
> On Wed, 20 Aug 2025, Tomasz Kamiński wrote:
>
> > This patch refactors the implementation of bind_front and bind_back to
> > avoid using std:
On Wed, 20 Aug 2025, Tomasz Kamiński wrote:
> This patch refactors the implementation of bind_front and bind_back to
> avoid using std::tuple for argument storage. Instead, bound arguments are
> now:
> * stored directly if there is only one,
> * within a dedicated _Bound_arg_storage otehrwise.
I
On Mon, 25 Aug 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs during expansion, because cfun->returns_struct
> wasn't cleared, despite auto being deduced to int.
>
> The problem is that check_return_type -> apply_deduced_return_type
> is called when parsing the expansion stmt b
On Fri, 22 Aug 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> In the PR, we're getting a linker error from _Vector_impl's destructor
> never getting emitted. This is because of a combination of factors:
>
> 1. in imp-member-4_a,
gain for the
patch!
>
> Best regards,Yihan
>
> Patrick Palka 于2025年8月19日周二 23:16写道：
> LGTM! Perhaps we want to backport this, not sure how far back
> (std::expected was implemented in GCC 12).
>
> On Sat, 16 Aug 2025, Yihan Wang wrote:
&g
On Tue, 5 Aug 2025, 1nfocalypse wrote:
> Implements Philox Engine (P2075R6) and associated tests.
>
> Implements additional feedback from v5 from Patrick Palka.
> Also cut some trailing whitespace from the limb propagation
> fix in v5.
>
> Apologies for the delay from
On Wed, 16 Jul 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Jul 15, 2025 at 6:13 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk only
> (since it impacts ABI)?
>
> Changes in v2:
>
> - Condition on
On Wed, 16 Jul 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Jul 15, 2025 at 9:51 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> The offset-based partial specialization of _CachedPositio
LGTM! Perhaps we want to backport this, not sure how far back
(std::expected was implemented in GCC 12).
On Sat, 16 Aug 2025, Yihan Wang wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/expected: Add missing constraint as per LWG 4222.
> * testsuite/20_util/expected/lwg4222.cc: Ne
Bootstrapped anh regtested on x86_64-pc-linux-gnu, does this look
OK for trunk and 15?
-- >8 --
When a using refers to a member from a partial specialization, we
need to substitute the arguments relative to partial specialization
into the constraints, not those relative to the primary template.
O
On Thu, 14 Aug 2025, Yihan Wang wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/expected: Add missing constraint as per LWG 4222.
> * testsuite/20_util/expected/lwg4222.cc: New test.
>
> Signed-off-by: Yihan Wang
> ---
> libstdc++-v3/include/std/expected | 1 +
> ..
Hi, thanks for the patch!
On Fri, 15 Aug 2025, seha-bot wrote:
> From: Nedim Šehić
>
> Regtested on x86_64-pc-linux-gnu.
>
> This patch fixes deduction for member array types from parenthesized
> initializers which use braces and string literals.
>
> PR c++/121518
>
> gcc/cp/ChangeLo
On Thu, 14 Aug 2025, Tomasz Kamiński wrote:
Typo in subject line, "inserting"
> For __n == 0, the elements where self move-assigned by
> std::move_backward(__ins, __old_finish - __n, __old_finish).
s/where/were?
LGTM besides that.
>
> PR libstdc++/121313
>
> libstdc++-v3/ChangeLog:
>
On Wed, 13 Aug 2025, Patrick Palka wrote:
> Thanks for the patch! Looks good to me for the most part.
>
> On Fri, 8 Aug 2025, Yihan Wang wrote:
>
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/expected:
>
> This ChangeLog entry should be fill
Thanks for the patch! Looks good to me for the most part.
On Fri, 8 Aug 2025, Yihan Wang wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/expected:
This ChangeLog entry should be filled in, e.g.
* include/std/expected (expected::expected(_Up&&)): Add
missing constraint
On Wed, 13 Aug 2025, Iain Sandoe wrote:
> Hi Patrick,
>
> > On 13 Aug 2025, at 16:26, Patrick Palka wrote:
> >
> > On Sun, 10 Aug 2025, Jason Merrill wrote:
> >
> >> On 8/8/25 1:27 PM, Patrick Palka wrote:
> >>> Bootstrapped and regtested
On Sun, 10 Aug 2025, Jason Merrill wrote:
> On 8/8/25 1:27 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk?
> >
> > -- >8 --
> >
> > At some point these flag start getting defined i
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
At some point these flag start getting defined in terms of the previous
flag, which is inconvenient when we want to test if the flag is set
during a debugging session since we don't immediately know its actua
On Fri, 25 Jul 2025, Patrick Palka wrote:
>
> On Fri, 25 Jul 2025, Patrick Palka wrote:
>
> > After r16-2519-gba5a6787374dea, we should never see a C++20 rewritten
> > comparison operator expressed as a built-in acting on an operator<=>
> > call, e.g. operat
On Tue, 5 Aug 2025, Jason Merrill wrote:
> On 7/31/25 10:51 AM, Patrick Palka wrote:
> > On Thu, 31 Jul 2025, Jason Merrill wrote:
> >
> > > On 7/30/25 5:48 PM, Patrick Palka wrote:
> > > > On Wed, 30 Jul 2025, Patrick Palka wrote:
> > > >
&g
Tested on x86_64-pc-linux-gnu, pushed as obvious.
-- >8 --
Here's a previously accepted testcase that is now ambiguous after
r16-2771-gb9f1cc4e119da, since the uninstantiated constraints are
equivalent but the partially instantiated constraints aren't, so
the two member functions no longer corres
On Mon, 4 Aug 2025, hexne wrote:
> Previously, std::ranges::shift_left and std::ranges::shift_right did
> not use feature test macros, so compiling std.cc files under c++20
> would result in compilation failure
Thanks for the patch (and the std::byteswap one)! They have been
folded into a larger
_On Mon, 4 Aug 2025, Patrick Palka wrote:
> On Mon, 4 Aug 2025, Jakub Jelinek wrote:
>
> > On Mon, Aug 04, 2025 at 11:33:17AM -0400, Patrick Palka wrote:
> > > > @@ -1693,6 +1697,8 @@ export namespace std
> > > >{
> > > > using std:
On Mon, 4 Aug 2025, Jakub Jelinek wrote:
> On Mon, Aug 04, 2025 at 11:33:17AM -0400, Patrick Palka wrote:
> > > @@ -1693,6 +1697,8 @@ export namespace std
> > >{
> > > using std::ranges::advance;
> > > using std::ranges::distance;
On Mon, 4 Aug 2025, Jakub Jelinek wrote:
> On Mon, Aug 04, 2025 at 12:00:32PM +0200, Jonathan Wakely wrote:
> > using std::operator""d;
> > using std::operator""h;
> > using std::operator""min;
> > using std::operator""ms;
> > using std::operator""ns;
> > using std::operator""sv;
> > using std::op
On Mon, Aug 4, 2025 at 10:39 AM Jakub Jelinek wrote:
>
> On Mon, Aug 04, 2025 at 03:11:32PM +0200, Jonathan Wakely wrote:
> > Somebody submitted patches for those and byteswap in the past 24 hours, but
> > your patch is more complete.
>
> I was aware of byteswap but missed the second version of th
On Sun, 3 Aug 2025, Jason Merrill wrote:
> On 8/1/25 11:16 AM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk and 15/14 after 15.2 is released?
> >
> > -- >8 --
> >
> > r13-3299 changed our
Three small review comments below:
On Fri, 1 Aug 2025, Nathan Myers wrote:
> Changes in v8:
> * Adjust template indentation to match rest of file
> * Change std Mandates conditions from "requires" to static_asserts.
> * Make _Bind_fn_t definition conditional on C++26, for static op().
> * Add
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk and 15 after 15.2 is released?
-- >8 --
The below testcases started to get rejected due to overload resolution
ambiguity after r15-3740 which corrected our inheritedness tiebreaker to
only apply to constructors and not
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and 15/14 after 15.2 is released?
-- >8 --
r13-3299 changed our internal declaration of __dynamic_cast to reside
inside the abi / __cxxabiv1 namespace instead of the global namespace,
matching the real declaration. Th
On Thu, 31 Jul 2025, Jason Merrill wrote:
> On 7/30/25 5:48 PM, Patrick Palka wrote:
> > On Wed, 30 Jul 2025, Patrick Palka wrote:
> >
> > > On Wed, 30 Jul 2025, Patrick Palka wrote:
> > >
> > > > On Wed, 30 Jul 2025, Patrick Palka wrote:
> >
On Thu, 31 Jul 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> And maybe 15?
Good catch re the invisiref handling! This LGTM, Jason what do you
think?
>
> -- >8 --
>
> When we merge a function definition, if there already exists a forward
> de
On Wed, 30 Jul 2025, Patrick Palka wrote:
> On Wed, 30 Jul 2025, Patrick Palka wrote:
>
> > On Wed, 30 Jul 2025, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > &
On Wed, 30 Jul 2025, Patrick Palka wrote:
> On Wed, 30 Jul 2025, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > Here the result of A::make(0, 0, 1), (0, 1, 0
On Wed, 30 Jul 2025, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> -- >8 --
>
> Here the result of A::make(0, 0, 1), (0, 1, 0) and (1, 0, 0) are each
> represented as a single-element CONSTRUCTOR with
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here the result of A::make(0, 0, 1), (0, 1, 0) and (1, 0, 0) are each
represented as a single-element CONSTRUCTOR with CONSTRUCTOR_NO_CLEARING
cleared, and we end up mangling them all as A{1}, i.e. eliding bo
On Wed, 30 Jul 2025, Nathaniel Shead wrote:
> On Tue, Jul 29, 2025 at 03:45:29PM -0400, Patrick Palka wrote:
> > On Tue, 29 Jul 2025, Nathaniel Shead wrote:
> >
> > > Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap+regtest
> > > passes?
> >
On Wed, 23 Jul 2025, 1nfocalypse wrote:
> Implements Philox Engine (P2075R6) and associated tests.
>
> Implements additional feedback from v4 from Patrick Palka.
>
> While fixing the carry bit propagation, I noted an issue for the
> limb carry reset as well, which has been fix
On Tue, 29 Jul 2025, Nathaniel Shead wrote:
> Tested on x86_64-pc-linux-gnu, OK for trunk if full bootstrap+regtest
> passes?
>
> -- >8 --
>
> For the sake of determining if there are other errors in user code to
> report early, many trait functions don't return error_mark_node if not
> called i
On Sat, 26 Jul 2025, Nathaniel Shead wrote:
> On Fri, Jul 25, 2025 at 08:58:47AM -0400, Patrick Palka wrote:
> > On Fri, 25 Jul 2025, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8
On Fri, 25 Jul 2025, Patrick Palka wrote:
> After r16-2519-gba5a6787374dea, we should never see a C++20 rewritten
> comparison operator expressed as a built-in acting on an operator<=>
> call, e.g. operator<=>(x, y) < 0. This is because operator<=> always
>
After r16-2519-gba5a6787374dea, we should never see a C++20 rewritten
comparison operator expressed as a built-in acting on an operator<=>
call, e.g. operator<=>(x, y) < 0. This is because operator<=> always
returns a class type (std::strong/weak/partial_ordering), so the < will
necessarily resolv
On Fri, 25 Jul 2025, Tomasz Kaminski wrote:
>
>
> On Fri, Jul 25, 2025 at 4:57 PM Tomasz Kaminski wrote:
>
>
> On Fri, Jul 25, 2025 at 4:49 PM Patrick Palka wrote:
> On Fri, 25 Jul 2025, Tomasz Kamiński wrote:
>
> > PR libstdc++/121196
&g
On Fri, 25 Jul 2025, Tomasz Kamiński wrote:
> PR libstdc++/121196
>
> libstdc++-v3/ChangeLog:
>
> * include/std/inplace_vector (std::erase): Provide default argument
> for _Up parameter.
> * testsuite/23_containers/inplace_vector/erasure.cc: Add test for
> using bra
On Fri, 18 Jul 2025, Jonathan Wakely wrote:
> When the C++98 std::distance and std::advance functions (and C++11
> std::next and std::prev) are used with C++20 iterators there can be
> unexpected results, ranging from compilation failure to decreased
> performance to undefined behaviour.
>
> An i
On Fri, 25 Jul 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> I noticed that C++26 trivial relocation didn't work in modules yet, and
> there are a couple of other flags that seem potentially useful we
> weren't streaming. This s
On Thu, 24 Jul 2025, Jason Merrill wrote:
> On 7/23/25 8:29 PM, Patrick Palka wrote:
> > On Wed, 23 Jul 2025, Jason Merrill wrote:
> >
> > > On 7/23/25 3:46 PM, Patrick Palka wrote:
> > > > As a follow-up to r16-2448-g7590c14b
On Thu, 24 Jul 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> The lambda conversion was ICEing for two C++23 features, static op() and
> explicit object parameters. The issue with the former seems like a more
> general issue: tsubst_function_decl re
On Wed, 23 Jul 2025, Patrick Palka wrote:
> On Wed, 23 Jul 2025, Jason Merrill wrote:
>
> > On 7/23/25 3:46 PM, Patrick Palka wrote:
> > > As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
> > > build_min_non_dep_op_overload how to re
On Wed, 23 Jul 2025, Tomasz Kamiński wrote:
> This replaces most test_constexpr invocations with direct calls to
> test_ranges(), which is also used for runtime tests.
>
> SimpleAllocator was made constexpr to simplify this refactoring. Other
> test allocators, like uneq_allocator (used in from_r
On Thu, 24 Jul 2025, Tomasz Kamiński wrote:
> Removed the wrong_stuff() function, which was effectively empty for
> actual test runs. Replaced the manual failure counter with the VERIFY
> macro to simplify identifying failures.
LGTM
>
> PR libstdc++/104874
>
> libstdc++-v3/ChangeLog:
>
On Wed, 23 Jul 2025, Jason Merrill wrote:
> On 7/23/25 3:46 PM, Patrick Palka wrote:
> > As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
> > build_min_non_dep_op_overload how to rebuild all rewritten comparison
> > operators, not just != -> =
On Wed, 23 Jul 2025, Patrick Palka wrote:
> As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
> build_min_non_dep_op_overload how to rebuild all rewritten comparison
> operators, not just != -> == ones, so that we don't incorrectly repeat
> the unqual
As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
build_min_non_dep_op_overload how to rebuild all rewritten comparison
operators, not just != -> == ones, so that we don't incorrectly repeat
the unqualified name lookup at instantiation time.
While working on this I noticed w
On Sat, 19 Jul 2025, 1nfocalypse wrote:
> Implements Philox Engine (P2075R6) and associated tests.
>
> Implements additional feedback from v3 from Patrick Palka.
>
> I went ahead and qualified the STL functions to avoid ADL ambiguity,
> as recommended. However, if this was
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Our implementation of the INVOKE spec ([func.require]) was incorrectly
treating reference_wrapper::get() as returning T instead of T&, which
notably makes a difference when invoking a ref-qualified memfn poin
Bootstrapped and rgetested on x86_64-pc-linux-gnu, does this look OK for
trunk?
In order to properly handle all rewritten operator expressions, I
suppose we could teach build_min_non_dep_op_overload to carefully look
through 'non_dep' and note when arguments are reversed etc. But rather
than that
On Tue, 22 Jul 2025, Tomasz Kamiński wrote:
> Adds negative tests for preconditions on inserting into a full
> inplace_vector and erasing non-existent elementsi at compile-time.
> This ensures coverage for the inplace_vector specialization.
>
> Also extends element access tests to cover front() a
On Tue, 22 Jul 2025, Tomasz Kamiński wrote:
> All functions in testsuite_iterators.h are now marked constexpr,
> targeting the earliest possible standard. Most functions use C++14 due
> to multi-statement bodies, with exceptions:
>
> * BoundsContainer and some constructors are C++11 compatible.
>
On Fri, 18 Jul 2025, 1nfocalypse wrote:
> Implements Philox Engine (P2075R6) and associated tests.
>
> Additionally implements changes based on feedback from Patrick
> Palka and jwakely on v2.
>
> Regarding the question posed by Patrick on why some things are
> defined i
ite/23_containers/inplace_vector/relops.cc: New file.
> * testsuite/23_containers/inplace_vector/version.cc: New file.
> * testsuite/util/testsuite_iterators.h (input_iterator_wrapper::base):
> Define.
>
> Reviewed-by: Patrick Palka
> Reviewed-by: Jonathan Wak
On Thu, 17 Jul 2025, Jonathan Wakely wrote:
> On 17/07/25 11:26 -0400, Patrick Palka wrote:
> > On Thu, 17 Jul 2025, Tomasz Kamiński wrote:
> >
> > > From: Jonathan Wakely
> > >
> > > Implement std::inplace_vector as specified in P0843R14, without fol
On Thu, 17 Jul 2025, Jonathan Wakely wrote:
> On 17/07/25 15:31 +0200, Tomasz Kamiński wrote:
> > From: Jonathan Wakely
> >
> > Implement std::inplace_vector as specified in P0843R14, without follow
> > up papers, in particular P3074R7 (trivial unions). In consequence
> > inplace_vector can be u
1 - 100 of 1577 matches
Mail list logo
