Re: [PATCH] c++: reference variable as default targ [PR101463]

On Tue, 22 Oct 2024, Patrick Palka wrote: > On Tue, 9 Jan 2024, Jason Merrill wrote: > > > On 1/5/24 15:01, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > > look OK for trunk? > > > > > > -- >8 --

Re: [PATCH 3/2] c++: remove WILDCARD_DECL

On Fri, 25 Oct 2024, Patrick Palka wrote: > On Wed, 23 Oct 2024, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > OK for trunk? > > > > -- >8 -- > > > > This tree code was added as part of the init

Re: [PATCH 2/2] c++: constrained auto NTTP vs associated constraints

On Thu, 17 Oct 2024, Patrick Palka wrote: > On Thu, 17 Oct 2024, Patrick Palka wrote: > > > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > > > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > > > > > According to [temp.param]/11, the con

Re: [PATCH 1/2] c++: some further concepts cleanups

On Tue, 15 Oct 2024, Patrick Palka wrote: > This patch further cleans up the concepts code following the removal of > Concepts TS support: > > * concept-ids are now the only kind of "concept check", so we can > simplify some code accordingly. In particu

Re: [PATCH v2] c++: Implement P2662R3, Pack Indexing [PR113798]

On Tue, 29 Oct 2024, Marek Polacek wrote: > On Tue, Oct 22, 2024 at 07:42:57PM -0400, Jason Merrill wrote: > > On 10/22/24 3:22 PM, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > -- >8 -- > > > This patch implements C++26 Pack Indexing, as desc

[PATCH] libstdc++: Avoid unnecessary copies in ranges::min/max [PR112349]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14? -- >8 -- Use a local reference for the (now possibly lifetime extended) result of *__first to avoid making unnecessary copies of it. PR libstdc++/112349 libstdc++-v3/ChangeLog: * include/bits/ranges_algo

Re: [PATCH 1/2] libstdc++: Implement C++23 (P0429R9)

On Wed, 16 Oct 2024, Patrick Palka wrote: > On Mon, 30 Sep 2024, Patrick Palka wrote: > > > This implements the C++23 container adaptors std::flat_map and > > std::flat_multimap from P0429R9. The implementation is shared > > as much as possible between the two ad

[PATCH] libstdc++: Fix complexity of drop_view::begin const [PR112641]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk/backports? Also available in PR form at https://forge.sourceware.org/gcc/gcc-TEST/pulls/8 -- >8 -- Views are required to have a amortized O(1) begin(), but our drop_view's const begin overload is O(n) for non-common ranges. This patch re

Re: [PATCH 3/2] c++: remove WILDCARD_DECL

On Wed, 23 Oct 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk? > > -- >8 -- > > This tree code was added as part of the initial Concepts TS > implementation to support type-constraints introducing any kind

Re: [PATCH] Replace 8 consecutive spaces in leading whitespace by tab

On Fri, Oct 25, 2024 at 7:54 AM Jakub Jelinek wrote: > > On Fri, Oct 25, 2024 at 01:25:25PM +0200, Arsen Arsenović wrote: > > Maybe we should go the other way around? Compressing eight spaces into > > a tab leads to strange artifacts in diffs (where lines appear > > misindented because some were

Re: [PATCH] c++: Implement P2662R3, Pack Indexing [PR113798]

On Wed, 23 Oct 2024, Jason Merrill wrote: > On 10/23/24 10:20 AM, Patrick Palka wrote: > > On Tue, 22 Oct 2024, Marek Polacek wrote: > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > -- >8 -- > > > This

[PATCH 3/2] c++: remove WILDCARD_DECL

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This tree code was added as part of the initial Concepts TS implementation to support type-constraints introducing any kind of template-parameter, not just type template-parameters, e.g. template concept C

Re: [PATCH] c++: Implement P2662R3, Pack Indexing [PR113798]

On Tue, 22 Oct 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > This patch implements C++26 Pack Indexing, as described in > . > > The issue discussing how to mangle pack indexes has not been resolved > yet

[PATCH] libstdc++: Implement LWG 4166 changes to concat_view::end()

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This patch proactively implements the proposed resolution for this LWG issue, which seems straightforward and slated to be approved as-is. I opted to not add a _GLIBCXX_RESOLVE_LIB_DEFECTS code comment for this since concat_vie

Re: [PATCH] c++: reference variable as default targ [PR101463]

On Tue, 9 Jan 2024, Jason Merrill wrote: > On 1/5/24 15:01, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > look OK for trunk? > > > > -- >8 -- > > > > Here during default template argument substitution we wron

Re: [PATCH] libstdc++: Avoid using std::__to_address with iterators

On Fri, 18 Oct 2024, Jonathan Wakely wrote: > Do others agree with my reasoning below? > > The changes to implement the rule "use std::__niter_base before C++20 > and use std::to_address after C++20" were easier than I expected. There > weren't many places that were doing it "wrong" and needed to

Re: [WIP RFC] libstdc++: add module std

On Fri, 18 Oct 2024, Jason Merrill wrote: > This patch is not ready for integration, but I'd like to get feedback on the > approach (and various specific questions below). > > -- 8< -- > > This patch introduces an installed source form of module std and std.compat. > To find them, we install a l

Re: [PATCH 1/7] libstdc++: Refactor std::uninitialized_{copy, fill, fill_n} algos [PR68350]

On Fri, 18 Oct 2024, Patrick Palka wrote: > On Fri, 18 Oct 2024, Jonathan Wakely wrote: > > > On 16/10/24 21:39 -0400, Patrick Palka wrote: > > > On Tue, 15 Oct 2024, Jonathan Wakely wrote: > > > > +#if __cplusplus < 201103L > > > > + > > >

Re: [PATCH 1/7] libstdc++: Refactor std::uninitialized_{copy, fill, fill_n} algos [PR68350]

On Fri, 18 Oct 2024, Jonathan Wakely wrote: > On 16/10/24 21:39 -0400, Patrick Palka wrote: > > On Tue, 15 Oct 2024, Jonathan Wakely wrote: > > > +#if __cplusplus < 201103L > > > + > > > + // True if we can unwrap _Iter to get a pointer by using >

[PATCH] c++: redundant hashing in register_specialization

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- After r15-4050-g5dad738c1dd164 register_specialization needs to set elt.hash to the (maybe) precomputed hash in order to avoid redundantly rehashing. gcc/cp/ChangeLog: * pt.cc (register_specializati

Re: [PATCH] libstdc++: Move std::__niter_base and std::__niter_wrap to stl_iterator.h

On Thu, 17 Oct 2024, Jonathan Wakely wrote: > I've split this out of "Refactor std::uninitialized_{copy, fill, fill_n}" > because this part can be done separately. Call it [PATCH -1/7] if you > like :-) > > This fixes the ordering problem that Patrick noticed in [PATCH 1/7], and > adds a test for

Re: [PATCH 2/2] c++: constrained auto NTTP vs associated constraints

On Thu, 17 Oct 2024, Patrick Palka wrote: > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > > > According to [temp.param]/11, the constraint on an auto NTTP is an > > > associated constraint and so shoul

Re: [PATCH 2/2] c++: constrained auto NTTP vs associated constraints

On Tue, 15 Oct 2024, Patrick Palka wrote: > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > According to [temp.param]/11, the constraint on an auto NTTP is an > > associated constraint and so should be checked as part of satisfaction > > of the overall associated constra

Re: [PATCH 2/2] libstdc++: Implement C++23 (P1222R4)

On Mon, 30 Sep 2024, Patrick Palka wrote: > This implements the C++23 container adaptors std::flat_set and > std::flat_multiset from P1222R4. The implementation is essentially > an simpler and pared down version of std::flat_map. > > The main known issues are: > >

Re: [PATCH 1/2] libstdc++: Implement C++23 (P0429R9)

On Mon, 30 Sep 2024, Patrick Palka wrote: > This implements the C++23 container adaptors std::flat_map and > std::flat_multimap from P0429R9. The implementation is shared > as much as possible between the two adaptors via a common base > class that's parameterized according

Re: [PATCH 2/7] libstdc++: Make __normal_iterator constexpr, always_inline, nodiscard

On Tue, 15 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > The __gnu_cxx::__normal_iterator type we use for std::vector::iterator > is not specified by the standard, it's an implementation detail. This > means it's not constrained by the rule that forbids strengthening >

Re: [PATCH 4/7] libstdc++: Remove indirection to __find_if in std::find etc.

ZOn Tue, 15 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > There doesn't seem to be a lot of benefit in reusing __find_if with > __gnu_cxx::__ops predicates, since they aren't going to actually > instantiate any less code if we use different predicates every time > (e.g

Re: [PATCH 3/7] libstdc++: Inline memmove optimizations for std::copy etc. [PR115444]

On Tue, 15 Oct 2024, Jonathan Wakely wrote: > This is a slightly different approach to C++98 compatibility than used > in patch 1/1 of this series for the uninitialized algos. It worked out a > bit cleaner this way for these algos, I think. > > Tested x86_64-linux. > > -- >8 -- > > This removes

Re: [PATCH 1/7] libstdc++: Refactor std::uninitialized_{copy, fill, fill_n} algos [PR68350]

On Tue, 15 Oct 2024, Jonathan Wakely wrote: > This is v2 of > https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665246.html > fixing some thinkos in uninitialized_{fill,fill_n}. We don't need to > worry about overwriting tail-padding in those algos, because we only use > memset for 1-byte int

[PATCH] doc: remove outdated C++ Concepts section

This was added as part of the initial Concepts TS implementation and reflects an early version of the Concepts TS paper, which is very different from standard C++20 concepts (and even from more recent versions of the Concepts TS, support for which we deprecated in GCC 14 and removed for GCC 15). S

[pushed] c++: add fixed testcase [PR80637]

Fixed by r15-4340-gcacbb4daac3e9a. PR c++/80637 gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-fn9.C: New test. --- gcc/testsuite/g++.dg/cpp2a/concepts-fn9.C | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-fn9.C d

Re: [PATCH 2/2] c++: constrained auto NTTP vs associated constraints

On Tue, 15 Oct 2024, Patrick Palka wrote: > According to [temp.param]/11, the constraint on an auto NTTP is an > associated constraint and so should be checked as part of satisfaction > of the overall associated constraints rather than checked individually > during coerion/deduction.

Re: [PATCH] libstdc++: Implement LWG 3798 for range adaptors [PR106676]

On Mon, 14 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > LWG 3798 modified the iterator_category of the iterator types for > transform_view, join_with_view, zip_transform_view and > adjacent_transform_view, to allow the iterator's reference type to be an > rvalue refer

[PATCH] c++: checking ICE w/ lambda targ inside constexpr if [PR117054]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here we're tripping over the assert in extract_locals_r which enforces that an extra-args tree appearing inside another extra-args tree doesn't actually have extra args. This invariant no longer always holds

[PATCH] c++: unifying lvalue vs rvalue (non-forwarding) ref [PR116710]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- When unifying two (non-forwarding) reference types, unify immediately recurses into the reference type without first comparing rvalueness. (Note that at this point forwarding references have already been coll

[PATCH 2/2] c++: constrained auto NTTP vs associated constraints

According to [temp.param]/11, the constraint on an auto NTTP is an associated constraint and so should be checked as part of satisfaction of the overall associated constraints rather than checked individually during coerion/deduction. In order to implement this we mainly need to make handling of c

[PATCH 1/2] c++: some further concepts cleanups

This patch further cleans up the concepts code following the removal of Concepts TS support: * concept-ids are now the only kind of "concept check", so we can simplify some code accordingly. In particular resolve_concept_check seems like a no-op and can be removed. * In turn, deduce_c

[PATCH 1/2] c++: some further concepts cleanups

This patch further cleans up the concepts code following the removal of Concepts TS support: * concept-ids are now the only kind of "concept check", so we can simplify some code accordingly. In particular resolve_concept_check seems like a no-op and can be removed. * In turn, deduce_c

Re: [pushed] c++: address deduction and concepts [CWG2918]

On Mon, 14 Oct 2024, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > CWG2918 changes deduction from an overload set for the case where multiple > candidates succeed and have the same type; previously this made the overload > set a non-deduced context, now i

Re: [PATCH] libstdc++: Implement LWG 3564 for ranges::transform_view

On Mon, 14 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > The _Iterator type returned by begin() const uses const F& to > transform the elements, so it should use const F& to determine the > iterator's value_type and iterator_category as well. > > This was accepted int

Re: [PATCH] libstdc++: Use std::move for iterator in ranges::fill [PR117094]

LGTM On Mon, 14 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > Input iterators aren't required to be copyable. > > libstdc++-v3/ChangeLog: > > PR libstdc++/117094 > * include/bits/ranges_algobase.h (__fill_fn): Use std::move for > iterator that migh

Re: [PATCH 4/4] c++: enable modules by default in c++20

On Wed, 9 Oct 2024, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, will apply to trunk with the rest of the patch > series. > > -- 8< -- > > At this point there doesn't seem to be much reason not to have modules > support enabled by default in C++20, and it's good get more test coverage to >

Re: [PATCH v3] libstdc++: implement concatenation of strings and string_views

On Sat, 21 Sep 2024, Giuseppe D'Angelo wrote: > On 31/07/2024 00:19, Jonathan Wakely wrote: > > One more thing that I missed last time, sorry: > > > > +#if __glibcxx_string_view >= 202403L > > + // const string & + string_view > > + template > > +_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR > >

Re: [PATCH] libstdc++: Implement P0849R8 auto(x) library changes

On Mon, 7 Oct 2024, Patrick Palka wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for trunk only? > This doesn't seem worth backporting since there should be no > behavior change. > > -- >8 -- > > This implements the library changes in P0849R8 "aut

[PATCH] libstdc++: Implement P0849R8 auto(x) library changes

Tested on x86_64-pc-linux-gnu, does this look OK for trunk only? This doesn't seem worth backporting since there should be no behavior change. -- >8 -- This implements the library changes in P0849R8 "auto(x): decay-copy in the language" which consist of replacing most uses of the exposition-only

Re: [PATCH 2/3] Release expanded template argument vector

On Mon, 7 Oct 2024, Jason Merrill wrote: > On 10/7/24 10:26 AM, Patrick Palka wrote: > > On Mon, 7 Oct 2024, Jason Merrill wrote: > > > > > On 10/7/24 9:58 AM, Patrick Palka wrote: > > > > On Sat, 5 Oct 2024, Jason Merrill wrote: > > > > &g

Re: [PATCH 2/3] Release expanded template argument vector

On Mon, 7 Oct 2024, Jason Merrill wrote: > On 10/7/24 9:58 AM, Patrick Palka wrote: > > On Sat, 5 Oct 2024, Jason Merrill wrote: > > > > > On 10/4/24 11:00 AM, Patrick Palka wrote: > > > > On Thu, 3 Oct 2024, Jason Merrill wrote: > > > > &g

Re: [PATCH 2/3] Release expanded template argument vector

On Sat, 5 Oct 2024, Jason Merrill wrote: > On 10/4/24 11:00 AM, Patrick Palka wrote: > > On Thu, 3 Oct 2024, Jason Merrill wrote: > > > > > On 10/3/24 12:38 PM, Jason Merrill wrote: > > > > On 10/2/24 7:50 AM, Richard Biener wrote: > > > > > T

Re: [PATCH 2/2 v3] libstdc++: add std::is_virtual_base_of

On Fri, 2 Aug 2024, Jonathan Wakely wrote: > On Fri, 2 Aug 2024 at 10:35, Giuseppe D'Angelo wrote: > > > > Hello, > > > > On 31/07/2024 00:55, Jonathan Wakely wrote: > > > If __cpp_lib_is_virtual_base_of depends on __has_builtin, then that > > > will do the right thing for #ifdef __cpp_lib_is_virt

[PATCH] libstdc++: Implement LWG 3664 changes to ranges::distance

Tested on x86_64-pc-linux-gnu, does this look OK for trunk/backports? -- >8 -- libstdc++-v3/ChangeLog: * include/bits/ranges_base.h (__distance_fn::operator()): Adjust iterator/sentinel overloads as per LWG 3664. * testsuite/24_iterators/range_operations/distance.cc:

Re: [PATCH 2/3] Release expanded template argument vector

On Thu, 3 Oct 2024, Jason Merrill wrote: > On 10/3/24 12:38 PM, Jason Merrill wrote: > > On 10/2/24 7:50 AM, Richard Biener wrote: > > > This reduces peak memory usage by 20% for a specific testcase. > > > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > > > > > It's very ugly so I

[PATCH] libstdc++/ranges: Implement various small LWG issues

Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and perhaps 13? -- >8 -- This implements the following small LWG issues: 3848. adjacent_view, adjacent_transform_view and slide_view missing base accessor 3851. chunk_view::inner-iterator missing custom iter_move and iter_swap

Re: [PATCH] libstdc++: Enable _GLIBCXX_ASSERTIONS by default for -O0 [PR112808]

On Wed, 2 Oct 2024, Jonathan Wakely wrote: > I think we should do this. > > Tested x86_64-linux. > > -- >8 -- > > Too many users don't know about -D_GLIBCXX_ASSERTIONS and so are missing > valuable checks for C++ standard library preconditions. This change > enables libstdc++ assertions by defa

Re: [PATCH] c++: explicit spec of constrained member tmpl [PR107522]

On Thu, 12 Sep 2024, Patrick Palka wrote: > (Sorry to resurrect this thread so late, I lost track of this patch...) > > On Fri, 2 Dec 2022, Jason Merrill wrote: > > > On 12/2/22 09:30, Patrick Palka wrote: > > > On Thu, 1 Dec 2022, Jason Merrill wrote: > > >

Re: [PATCH] c++: partial spec constraint checking context [PR105220]

On Mon, 16 Sep 2024, Patrick Palka wrote: > On Thu, 30 Nov 2023, Patrick Palka wrote: > > > On Fri, 3 Nov 2023, Patrick Palka wrote: > > > > > On Tue, 3 May 2022, Jason Merrill wrote: > > > > > > > On 5/2/22 14:50, Patrick Palka wrote: > &

[PATCH 2/2] libstdc++: Implement C++23 (P1222R4)

This implements the C++23 container adaptors std::flat_set and std::flat_multiset from P1222R4. The implementation is essentially an simpler and pared down version of std::flat_map. The main known issues are: * exception safety is likely incomplete/buggy * unimplemented from_range_t construc

[PATCH 1/2] libstdc++: Implement C++23 (P0429R9)

This implements the C++23 container adaptors std::flat_map and std::flat_multimap from P0429R9. The implementation is shared as much as possible between the two adaptors via a common base class that's parameterized according to key uniqueness. The main known issues are: * the range insert() ov

Re: [PATCH 1/2 v2] Introduce __builtin_is_virtual_base_of

On Wed, 25 Sep 2024, Jason Merrill wrote: > On 7/30/24 6:49 PM, Giuseppe D'Angelo wrote: > > On 29/07/2024 22:53, Giuseppe D'Angelo wrote: > > > Hi, > > > > > > The attached patch is a stab at adding the necessary compiler builtin to > > > support std::is_virtual_base_of (P2985R0, approved for C+

Re: [PATCH 1/2 v2] Introduce __builtin_is_virtual_base_of

[CC'ing Jason] On Wed, 25 Sep 2024, Patrick Palka wrote: > On Wed, 31 Jul 2024, Giuseppe D'Angelo wrote: > > > On 29/07/2024 22:53, Giuseppe D'Angelo wrote: > > > Hi, > > > > > > The attached patch is a stab at adding the necessary com

Re: [PATCH 1/2 v2] Introduce __builtin_is_virtual_base_of

On Wed, 31 Jul 2024, Giuseppe D'Angelo wrote: > On 29/07/2024 22:53, Giuseppe D'Angelo wrote: > > Hi, > > > > The attached patch is a stab at adding the necessary compiler builtin to > > support std::is_virtual_base_of (P2985R0, approved for C++26). The name > > of the builtin matches the one jus

[PATCH] c++: CWG 2789 and reversed operator candidates

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- As a follow-up to r15-3741-gee3efe06c9c49c, which was only concerned with usings, it seems we should also compare contexts of a reversed vs non-reversed (member) candidate during operator overload resolution.

Re: [PATCH 2/2] c++: CWG 2789 and usings [PR116492]

On Fri, 20 Sep 2024, Jason Merrill wrote: > On 9/20/24 6:51 PM, Patrick Palka wrote: > > On Fri, 20 Sep 2024, Jason Merrill wrote: > > > > > On 9/18/24 10:59 PM, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this >

Re: [PATCH 2/2] c++: CWG 2789 and usings [PR116492]

On Fri, 20 Sep 2024, Jason Merrill wrote: > On 9/18/24 10:59 PM, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > look OK for trunk? I'm not sure this is worth backporting > > without the previous CWG 2273 tweak since it'll

Re: [PATCH 1/2] c++: CWG 2273 and non-constructors

On Wed, 18 Sep 2024, Patrick Palka wrote: > Our implementation of the CWG 2273 inheritedness tiebreaker seems to be > incorrectly considering all inherited members, not just inherited > constructors. This patch restricts the tiebreaker accordingly. > > DR 2273 >

[PATCH 1/2] c++: CWG 2273 and non-constructors

Our implementation of the CWG 2273 inheritedness tiebreaker seems to be incorrectly considering all inherited members, not just inherited constructors. This patch restricts the tiebreaker accordingly. DR 2273 gcc/cp/ChangeLog: * call.cc (joust): Restrict inheritedness tiebreaker

[PATCH 2/2] c++: CWG 2789 and usings [PR116492]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm not sure this is worth backporting without the previous CWG 2273 tweak since it'll mean inconsistent behavior between implict vs explicit object members in GCC 14: the call to S<>{}.f() in concepts-memfun4.C would

Re: [PATCH] c++: crash with anon VAR_DECL [PR116676]

On Tue, 17 Sep 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13? Why not backport this to 12 as well? > > -- >8 -- > r12-3495 added maybe_warn_about_constant_value which will crash if > it gets a nameless VAR_DECL, which is what happens in this PR.

Re: [PATCH] c++: alias of decltype(lambda) is opaque [PR116714]

On Mon, 16 Sep 2024, Patrick Palka wrote: > On Mon, 16 Sep 2024, Andrew Pinski wrote: > > > On Mon, Sep 16, 2024 at 8:12 AM Patrick Palka wrote: > > > > > > Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look > > > OK for trunk?

Re: [PATCH] c++: alias of decltype(lambda) is opaque [PR116714]

On Mon, 16 Sep 2024, Andrew Pinski wrote: > On Mon, Sep 16, 2024 at 8:12 AM Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look > > OK for trunk? Sadly the prerequisity patch r15-2331-g523836716137d0 > > probably isn'

Re: [PATCH] c++: partial spec constraint checking context [PR105220]

On Thu, 30 Nov 2023, Patrick Palka wrote: > On Fri, 3 Nov 2023, Patrick Palka wrote: > > > On Tue, 3 May 2022, Jason Merrill wrote: > > > > > On 5/2/22 14:50, Patrick Palka wrote: > > > > Currently when checking the constraints of a class template,

[PATCH] c++: alias of decltype(lambda) is opaque [PR116714]

Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look OK for trunk? Sadly the prerequisity patch r15-2331-g523836716137d0 probably isn't suitable for backporting, so I reckon this should be trunk-only. -- >8 -- Here we're prematurely stripping the decltype(lambda) alias used inside th

Re: [PATCH v2] libstdc++: add default template parameters to algorithms

On Fri, 13 Sep 2024, Patrick Palka wrote: > On Fri, 13 Sep 2024, Patrick Palka wrote: > > > On Fri, 13 Sep 2024, Jonathan Wakely wrote: > > > > > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote: > > > > > > > > On Fri, 2

Re: [PATCH v2] libstdc++: add default template parameters to algorithms

On Fri, 13 Sep 2024, Patrick Palka wrote: > On Fri, 13 Sep 2024, Jonathan Wakely wrote: > > > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote: > > > > > > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo > > > wrote: > > > > > > &g

Re: [PATCH v2] libstdc++: add default template parameters to algorithms

On Fri, 13 Sep 2024, Jonathan Wakely wrote: > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote: > > > > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo > > wrote: > > > > > > Hello, > > > > > > as usual thank you for the review. V2 is attached. > > > > > > On 02/08/2024 14:38, Jonathan Wakely w

Re: [PATCH 1/2] c++: Make __builtin_launder reject invalid types [PR116673]

On Thu, 12 Sep 2024, Jonathan Wakely wrote: > Tested x86_64-linux. OK for trunk? > > -- >8 -- > > The standard says that std::launder is ill-formed for function pointers > and cv void pointers, so there's no reason for __builtin_launder to > accept them. This change allows implementations of std

Re: [PATCH v2] c++: Fix constrained auto deduction templ parms resolution [PR114915, PR115030]

On Mon, 12 Aug 2024, Seyed Sajad Kahani wrote: > When deducing auto for `adc_return_type`, `adc_variable_type`, and > `adc_decomp_type` contexts (at the usage time), we try to resolve the > outermost > template arguments to be used for satisfaction. This is done by one of the > following, dependi

Re: [PATCH] c++/modules: Merge default arguments [PR99274]

On Fri, 23 Aug 2024, Nathaniel Shead wrote: > On Thu, Aug 22, 2024 at 02:20:14PM -0400, Patrick Palka wrote: > > On Mon, 12 Aug 2024, Nathaniel Shead wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > > > I tried

Re: [PATCH] c++: explicit spec of constrained member tmpl [PR107522]

(Sorry to resurrect this thread so late, I lost track of this patch...) On Fri, 2 Dec 2022, Jason Merrill wrote: > On 12/2/22 09:30, Patrick Palka wrote: > > On Thu, 1 Dec 2022, Jason Merrill wrote: > > > > > On 12/1/22 14:51, Patrick Palka wrote: > > > > On

Re: [PATCH] c++: ICE with TTP [PR96097]

On Wed, 11 Sep 2024, Patrick Palka wrote: > On Wed, 11 Sep 2024, Patrick Palka wrote: > > > On Wed, 4 Sep 2024, Marek Polacek wrote: > > > > > On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote: > > > > On 9/3/24 6:12 PM, Marek Polacek wro

Re: [PATCH] c++: ICE with TTP [PR96097]

On Wed, 11 Sep 2024, Patrick Palka wrote: > On Wed, 4 Sep 2024, Marek Polacek wrote: > > > On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote: > > > On 9/3/24 6:12 PM, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for

Re: [PATCH] c++: ICE with TTP [PR96097]

On Wed, 4 Sep 2024, Marek Polacek wrote: > On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote: > > On 9/3/24 6:12 PM, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? > > > > The change to return bool seems like unrelated cleanup; please push t

[PATCH] c++: decltype(auto) deduction of statement-expression [PR116418]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/backports? -- >8 -- r8-7538 for PR84968 made strip_typedefs_expr diagnose seeing STATEMENT_LIST, which effectively makes us reject statement-expressions noexcept-specifiers (we already diagnose them in template argumen

Re: [PATCH] c++: template depth of lambda in default targ [PR116567]

On Thu, 5 Sep 2024, Jason Merrill wrote: > On 9/5/24 2:28 PM, Patrick Palka wrote: > > On Thu, 5 Sep 2024, Jason Merrill wrote: > > > > > On 9/5/24 1:26 PM, Patrick Palka wrote: > > > > On Thu, 5 Sep 2024, Jason Merrill wrote: > > > > &

Re: [PATCH] c++: template depth of lambda in default targ [PR116567]

On Thu, 5 Sep 2024, Jason Merrill wrote: > On 9/5/24 1:26 PM, Patrick Palka wrote: > > On Thu, 5 Sep 2024, Jason Merrill wrote: > > > > > On 9/5/24 10:54 AM, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, do

Re: [PATCH] c++: template depth of lambda in default targ [PR116567]

On Thu, 5 Sep 2024, Jason Merrill wrote: > On 9/5/24 10:54 AM, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > > for trunk/14? > > > > -- >8 -- > > > > A lambda within a default template argument used

Re: [PATCH] c++: template depth of lambda in default targ [PR116567]

On Thu, 5 Sep 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > for trunk/14? > > -- >8 -- > > A lambda within a default template argument used in some template-id > may have a smaller template depth than the context o

[PATCH] c++: template depth of lambda in default targ [PR116567]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- A lambda within a default template argument used in some template-id may have a smaller template depth than the context of the template-id. For example, the lambda in v1's default template argument has tem

Re: [PATCH] c++/modules: Merge default arguments [PR99274]

On Mon, 12 Aug 2024, Nathaniel Shead wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > I tried to implement a remapping of the slots for TARGET_EXPRs for the > FIXME but I wasn't able to work out how to do so effectively. Given > that I doubt this will be a common iss

[PATCH] libstdc++: Add some missing ranges feature-test macro tests

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14? -- >8 -- libstdc++-v3/ChangeLog: * testsuite/25_algorithms/contains/1.cc: Verify value of __cpp_lib_ranges_contains. * testsuite/25_algorithms/find_last/1.cc: Verify value of __cpp_lib_rang

Re: [PATCH 2/2] libstdc++: Implement P2997R1 changes to the indirect invocability concepts

On Wed, 21 Aug 2024, Jonathan Wakely wrote: > On Wed, 21 Aug 2024 at 01:40, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps > > 14? > > > > -- >8 -- > > > > This implements the changes of this C+

[PATCH 3/2] libstdc++: Optimize std::projected

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm not sure if the current specification of 'projected' strictly speaking allows for this optimization, but it seems like a natural one that should be allowed. -- >8 -- Algorithms that are generalized to take projections usually defaul

[PATCH 1/2] libstdc++: Implement P2609R3 changes to the indirect invocability concepts

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14? -- >8 -- This implements the changes of this C++23 paper as a DR against C++20. Note that since the later P2538R1 "ADL-proof std::projected" which we already implement, we can't use a simple partial specialization to matc

[PATCH 2/2] libstdc++: Implement P2997R1 changes to the indirect invocability concepts

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14? -- >8 -- This implements the changes of this C++26 paper as a DR against C++20. libstdc++-v3/ChangeLog: * include/bits/iterator_concepts.h (indirectly_unary_invocable): Relax as per P2997R1. (indi

[PATCH] c++: local class memfn synth from noexcept context [PR113063]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk only? -- >8 -- Extending the PR113063 testcase to additionally constant evaluate the <=> expression causes us to trip over the assert in cxx_eval_call_expression /* We used to shortcut trivial constructor/op= here,

[PATCH] c++: default targ eligibility refinement [PR101463]

> > Here during default template argument substitution we wrongly consider > > the (substituted) default arguments v and vt as value-dependent[1] > > which ultimately leads to deduction failure for the calls. > > > > The bogus value_dependent_expression_p result aside, I noticed > > type_unificatio

[pushed] c++: fix up cpp23/consteval-if3.C test [PR115583]

Compiling with optimizations is needed to trigger the bug fixed by r15-2369. PR c++/115583 gcc/testsuite/ChangeLog: * g++.dg/cpp23/consteval-if13.C: Compile with -O. --- gcc/testsuite/g++.dg/cpp23/consteval-if13.C | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/testsuite

Re: [RFC] libstdc++: Replace Ryu with Teju Jagua for float.

On Mon, 5 Aug 2024, Cassio Neri wrote: > Implement the template function teju_jagua which finds the shortest > representation of a floating-point number. The floating-point type is a > template parameter and the implementation is generic enough to handle all > floating-point types of interest, nam

[PATCH] c++: c->B::m access resolved through current inst [PR116320]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and later backports? -- >8 -- Here when checking the access of (the injected-class-name) B in c->B::m at parse time, we notice its scope B (now the type) is a base of the object type C, so we proceed to use C as qualif

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

On Tue, 13 Aug 2024, Jason Merrill wrote: > On 8/13/24 7:52 PM, Patrick Palka wrote: > > On Tue, 13 Aug 2024, Jason Merrill wrote: > > > > > On 8/12/24 10:01 PM, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

On Tue, 13 Aug 2024, Jason Merrill wrote: > On 8/12/24 10:01 PM, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? > > > > -- >8 -- > > > > In r15-2210 we got rid of the unnecessary cast to lvalue reference when > &

  1   2   3   4   5   6   7   8   9   10   >