[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 > &

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

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 passing *this to the promise type ctor, and as a drive-by change we also simplified the code to use cp_build_fold_indirect_ref. But cp_build_fold_indire

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On Fri, 9 Aug 2024, Jason Merrill wrote: > On 8/9/24 2:32 PM, Patrick Palka wrote: > > On Fri, 9 Aug 2024, Patrick Palka wrote: > > > > > On Fri, 9 Aug 2024, Jason Merrill wrote: > > > > > > > On 8/8/24 1:00 PM, Patrick Palka wrote: > > >

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On Fri, 9 Aug 2024, Patrick Palka wrote: > On Fri, 9 Aug 2024, Jason Merrill wrote: > > > On 8/8/24 1:00 PM, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > > look OK for trunk/14? > > > > > > -- >8 -

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On Fri, 9 Aug 2024, Jason Merrill wrote: > On 8/8/24 1:00 PM, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > look OK for trunk/14? > > > > -- >8 -- > > > > This implements the inherited vs non-inherited guid

[pushed] c-family: regenerate c.opt.urls

The addition of -Wtemplate-body in r15-2774-g596d1ed9d40b10 means we need to regenerate c.opt.urls. gcc/c-family/ChangeLog: * c.opt.urls: Regenerate. --- gcc/c-family/c.opt.urls | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls index

[PATCH 13 backport] c++: local class memfn synth from uneval context [PR113063]

Bootstrap and regtest in progress, does this look OK for the 13 branch if successful? -- >8 -- This is essentially a narrow backport of r14-6724-gfced59166f95e9 that uses cp_evaluated instead of maybe_push_to_top_level to clear cp_unevaluated_operand within synthesize_method, which turns out is s

[PATCH] c++: inherited CTAD fixes [PR116276]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- This implements the inherited vs non-inherited guide tiebreaker specified by P2582R1. In order to track inherited-ness of a guide it seems natural to reuse the lang_decl_fn::context field that already tra

[PATCH] c++: clean up cp_identifier_kind checks

The predicates for checking an IDENTIFIER node's cp_identifier_kind currently directly test the three flag bits that encode the kind. This patch instead makes the checks first reconstruct the cp_identifier_kind in its entirety and then compare that. gcc/cp/ChangeLog: * cp-tree.h (get_ide

[PATCH] c++: DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P cleanups

DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P templates can only appear as part of a template friend declaration, and in turn get partially instantiated only from tsubst_friend_function or tsubst_friend_class. So rather than having tsubst_template_decl clear the flag, let's leave it up to the tsubst frien

Re: [PATCH v2] c++/modules: Handle instantiating qualified template friend classes [PR115801]

On Wed, 7 Aug 2024, Patrick Palka wrote: > On Thu, 8 Aug 2024, Nathaniel Shead wrote: > > > On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote: > > > On 8/6/24 2:35 AM, Nathaniel Shead wrote: > > > > Bootstrapped and regtested on

Re: [PATCH v2] c++/modules: Handle instantiating qualified template friend classes [PR115801]

On Thu, 8 Aug 2024, Nathaniel Shead wrote: > On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote: > > On 8/6/24 2:35 AM, Nathaniel Shead wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > > > Another potential approach would be to go searching for this

[PATCH] c++: erroneous partial spec vs primary tmpl [PR116064]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- When a partial specialization is deemed erroneous at parse time, we currently flag the primary template as erroneous instead. Later at instantiation time we check if the primary template is erroneous rather

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Tue, 6 Aug 2024, Jason Merrill wrote: > On 8/6/24 5:47 PM, Patrick Palka wrote: > > On Tue, 6 Aug 2024, Jason Merrill wrote: > > > > > On 8/6/24 2:00 PM, Patrick Palka wrote: > > > > On Tue, 6 Aug 2024, Jason Merrill wrote: > > > >

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Tue, 6 Aug 2024, Jason Merrill wrote: > On 8/6/24 2:00 PM, Patrick Palka wrote: > > On Tue, 6 Aug 2024, Jason Merrill wrote: > > > > > On 8/5/24 6:09 PM, Patrick Palka wrote: > > > > On Mon, 5 Aug 2024, Jason Merrill wrote: > > > >

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Tue, 6 Aug 2024, Jason Merrill wrote: > On 8/5/24 6:09 PM, Patrick Palka wrote: > > On Mon, 5 Aug 2024, Jason Merrill wrote: > > > > > On 8/5/24 3:47 PM, Patrick Palka wrote: > > > > On Mon, 5 Aug 2024, Jason Merrill wrote: > > > >

Re: [PATCH] c++: further concept_check_p clean-up

On Tue, 6 Aug 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? LGTM > > -- >8 -- > Patrick noticed a few more concept_check_p checks that can be removed > now. > > gcc/cp/ChangeLog: > > * constexpr.cc (cxx_eval_call_expression): Remove concept_ch

[PATCH] c++: fold calls to std::forward_like [PR96780]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This extends our folding of cast-like standard library functions to also include C++23's std::forward_like. PR c++/96780 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold) : Fold calls t

Re: [PATCH] c++: remove function/var concepts code

On Fri, 2 Aug 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu. Comments? > > -- >8 -- > This patch removes vestigial Concepts TS code as discussed in > . Yay! FWIW I think we can also remove the concept

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Mon, 5 Aug 2024, Jason Merrill wrote: > On 8/5/24 3:47 PM, Patrick Palka wrote: > > On Mon, 5 Aug 2024, Jason Merrill wrote: > > > > > On 8/5/24 1:14 PM, Patrick Palka wrote: > > > > On Mon, 5 Aug 2024, Jason Merrill wrote: > > > >

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Mon, 5 Aug 2024, Jason Merrill wrote: > On 8/5/24 1:14 PM, Patrick Palka wrote: > > On Mon, 5 Aug 2024, Jason Merrill wrote: > > > > > On 8/2/24 4:18 PM, Patrick Palka wrote: > > > > On Fri, 2 Aug 2024, Patrick Palka wrote: > > > > &

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Mon, 5 Aug 2024, Jason Merrill wrote: > On 8/2/24 4:18 PM, Patrick Palka wrote: > > On Fri, 2 Aug 2024, Patrick Palka wrote: > > > > > On Fri, 2 Aug 2024, Jason Merrill wrote: > > > > > > > On 8/1/24 2:52 PM, Patrick Palka wrote: > > > &g

Re: [PATCH] libstdc++: Do not use deduced return type for std::forward_like

On Fri, 2 Aug 2024, Patrick Palka wrote: > On Fri, 2 Aug 2024, Jonathan Wakely wrote: > > > This isn't properly tested so I'm not pushing it, but I'm sharing it now > > for comment. > > > > -- >8 -- > > > > Inspired by https://gith

Re: [PATCH] libstdc++: Do not use deduced return type for std::forward_like

On Fri, 2 Aug 2024, Jonathan Wakely wrote: > This isn't properly tested so I'm not pushing it, but I'm sharing it now > for comment. > > -- >8 -- > > Inspired by https://github.com/llvm/llvm-project/issues/101614 this > replaces the deduced return type of std::forward_like with a type trait > to

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Fri, 2 Aug 2024, Patrick Palka wrote: > On Fri, 2 Aug 2024, Jason Merrill wrote: > > > On 8/1/24 2:52 PM, Patrick Palka wrote: > > > In recent versions of GCC we've been diagnosing more and more kinds of > > > errors inside a template ahead of time. This is

Re: [PATCH] c++: Move -Wdangling-reference to -Wextra

On Fri, 2 Aug 2024, Marek Polacek wrote: > On Thu, Aug 01, 2024 at 05:18:35PM -0400, Jason Merrill wrote: > > On 8/1/24 4:20 PM, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > -- >8 -- > > > Despite a number of mitigations (don't warn for std::

Re: [PATCH] c++: permit errors inside uninstantiated templates [PR116064]

On Fri, 2 Aug 2024, Jason Merrill wrote: > On 8/1/24 2:52 PM, Patrick Palka wrote: > > In recent versions of GCC we've been diagnosing more and more kinds of > > errors inside a template ahead of time. This is a largely good thing > > because it catches bugs, t

[PATCH] c++: permit errors inside uninstantiated templates [PR116064]

In recent versions of GCC we've been diagnosing more and more kinds of errors inside a template ahead of time. This is a largely good thing because it catches bugs, typos, dead code etc sooner. But if the template never gets instantiated then such errors are harmless, and can be inconvenient to w

Re: [RFH PATCH] c++: Implement C++26 P2963R3 - Ordering of constraints involving fold expressions [PR115746]

On Tue, 30 Jul 2024, Jason Merrill wrote: > On 7/29/24 5:32 PM, Patrick Palka wrote: > > On Mon, 29 Jul 2024, Jakub Jelinek wrote: > > > > > On Fri, Jul 26, 2024 at 06:00:12PM -0400, Patrick Palka wrote: > > > > On Fri, 26 Jul 2024, Jakub Jelinek wrote: > &

Re: [RFH PATCH] c++: Implement C++26 P2963R3 - Ordering of constraints involving fold expressions [PR115746]

On Mon, 29 Jul 2024, Jakub Jelinek wrote: > On Fri, Jul 26, 2024 at 06:00:12PM -0400, Patrick Palka wrote: > > On Fri, 26 Jul 2024, Jakub Jelinek wrote: > > > > > On Fri, Jul 26, 2024 at 04:42:36PM -0400, Patrick Palka wrote: > > > > > // P2963R3 -

[PATCH] c++: generic lambda as default template argument [PR88313]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14.3? It should only make a differenc for C++20 code where lambdas are permitted as template arguments. -- >8 -- Here we're rejecting the generic lambda inside the default template argument ultimately beca

Re: [RFH PATCH] c++: Implement C++26 P2963R3 - Ordering of constraints involving fold expressions [PR115746]

On Fri, 26 Jul 2024, Jakub Jelinek wrote: > On Fri, Jul 26, 2024 at 04:42:36PM -0400, Patrick Palka wrote: > > > // P2963R3 - Ordering of constraints involving fold expressions > > > // { dg-do compile { target c++20 } } > > > > > > t

Re: [RFH PATCH] c++: Implement C++26 P2963R3 - Ordering of constraints involving fold expressions [PR115746]

On Fri, 26 Jul 2024, Jakub Jelinek wrote: > On Fri, Jul 26, 2024 at 09:49:27PM +0200, Jakub Jelinek wrote: > > On Fri, Jul 26, 2024 at 08:43:44PM +0200, Jakub Jelinek wrote: > > > Yeah, I saw ARGUMENT_PACK_SELECT being used, but didn't notice that > > > important > > > if (arg_pack && TREE_C

Re: [RFH PATCH] c++: Implement C++26 P2963R3 - Ordering of constraints involving fold expressions [PR115746]

On Fri, 26 Jul 2024, Patrick Palka wrote: > On Fri, 26 Jul 2024, Jakub Jelinek wrote: > > > Hi! > > > > I've tried to implement the C++26 fold expanded constraints paper but ran > > into issues (see below). Would appreciate some guidance/help, I'm

Re: [RFH PATCH] c++: Implement C++26 P2963R3 - Ordering of constraints involving fold expressions [PR115746]

On Fri, 26 Jul 2024, Jakub Jelinek wrote: > Hi! > > I've tried to implement the C++26 fold expanded constraints paper but ran > into issues (see below). Would appreciate some guidance/help, I'm afraid > I'm stuck. > > The patch introduces a FOLD_CONSTR tree to represent fold expanded > constrai

Re: [pushed] c++: #pragma target and deferred instantiation [PR115403]

On Thu, 25 Jul 2024, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > Also built highway to check. > > -- 8< -- > > My patch for 109753 applies the current #pragma target/optimize to a > function when we compile it, which was a problem for a template > instantiation def

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On Thu, 25 Jul 2024, Patrick Palka wrote: > On Mon, 22 Jul 2024, Jason Merrill wrote: > > > On 7/19/24 10:30 AM, Patrick Palka wrote: > > > On Thu, 18 Jul 2024, Jason Merrill wrote: > > > > > > > On 7/18/24 12:45 PM, Patrick Palka wrote: > > >

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On Mon, 22 Jul 2024, Jason Merrill wrote: > On 7/19/24 10:30 AM, Patrick Palka wrote: > > On Thu, 18 Jul 2024, Jason Merrill wrote: > > > > > On 7/18/24 12:45 PM, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, d

[PATCH] libstdc++: fix uses of explicit object parameter [PR116038]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 (after 14.2 is released)? -- >8 -- The type of an implicit object parameter is always the current class. For an explicit object parameter however, its deduced type can be a class derived from the current class. So when combining multi

Re: [PATCH] c++/modules: Stream warning suppressions [PR115757]

On Tue, 23 Jul 2024, Jason Merrill wrote: > On 7/7/24 12:39 AM, Nathaniel Shead wrote: > > Bootstrapped on x86_64-pc-linux-gnu, successfully regtested modules.exp; > > OK for trunk if full regtest passes? > > Patrick, I assume this change won't mess with your streaming optimizations? Should be f

Re: [PATCH] c++: normalizing ttp parm constraints [PR115656]

On Tue, 23 Jul 2024, Jason Merrill wrote: > On 7/5/24 12:18 PM, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > > for trunk/14 and perhaps 13? > > > > Alternatively we can set current_template_parms from weakly_subsume

Re: [PATCH] c++: Some cp-tree.def comment fixes

On Mon, 22 Jul 2024, Jakub Jelinek wrote: > Hi! > > While reading the fold expression and concept tree comments, I found > various spots referring to non-existent macros etc. > > The following patch attempts to sync that with what is actually implemented. > > Ok for trunk? > > 2024-07-22 Jaku

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On Fri, 19 Jul 2024, Patrick Palka wrote: > On Thu, 18 Jul 2024, Jason Merrill wrote: > > > On 7/18/24 12:45 PM, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look > > > OK for trunk/14? > > > > > >

[PATCH] c++/coroutines: correct passing *this to promise type

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps backports? -- >8 -- When passing *this to the promise type ctor (or operator new) (as per [dcl.fct.def.coroutine]/4), we add an explicit cast to lvalue reference, but that's unnecessary since *this is already an lvalue. And it

Re: [PATCH] c++: missing SFINAE during alias CTAD [PR115296]

On Fri, 19 Jul 2024, Jason Merrill wrote: > On 7/19/24 10:55 AM, Patrick Palka wrote: > > On Fri, Jul 5, 2024 at 1:50 PM Patrick Palka wrote: > > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > > OK for trunk/14? > > >

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

Seems to be fixed by r15-521-g6ad7ca1bb90573. PR c++/109464 gcc/testsuite/ChangeLog: * g++.dg/template/explicit-instantiation8.C: New test. --- .../g++.dg/template/explicit-instantiation8.C | 24 +++ 1 file changed, 24 insertions(+) create mode 100644 gcc/testsu

Re: [PATCH] c++: xobj fn call without obj [PR115783]

On Sat, Jul 6, 2024 at 8:22 PM Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > look OK for trunk/14? Ping. > > -- >8 -- > > The code path for rejecting an object-less call to a non-static > member function should also consid

Re: [PATCH] c++: missing SFINAE during alias CTAD [PR115296]

On Fri, Jul 5, 2024 at 1:50 PM Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk/14? > > -- >8 -- > > During the alias CTAD transformation, if substitution failed for some > guide we should just discard the guide

Re: [PATCH] c++: normalizing ttp parm constraints [PR115656]

On Fri, Jul 5, 2024 at 12:18 PM Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > for trunk/14 and perhaps 13? > > Alternatively we can set current_template_parms from weakly_subsumes > instead, who has only one caller anyway.

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On Thu, 18 Jul 2024, Jason Merrill wrote: > On 7/18/24 12:45 PM, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look > > OK for trunk/14? > > > > -- >8 -- > > > > As a followup of r15-2047-g7954bb4fcb6fa8, we also

  1   2   3   4   5   6   7   8   9   10   >