[PATCH] c++: partial ordering with dependent NTTP type [PR105289]

Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing (respectively) on two testcases that we used to accept in C++17 mode. Both testcases declare partial specializations for which the primary template contains an NTTP with dependent type, but the correctness of these partial

[PATCH] c++: partial ordering with dependent NTTP type [PR105289]

Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing (respectively) on two testcases that we used to accept in C++17 mode. Both testcases declare partial specializations for which the primary template contains an NTTP with dependent type, but the correctness of these partial

[PATCH] libstdc++: Avoid ASCII assumptions in floating_from_chars.cc

In starts_with_ci and in __floating_from_chars_hex's inf/nan handling, we were assuming that the letters are contiguous and that 'A' + 32 == 'a' which is true for ASCII but not for other character encodings. This patch fixes starts_with_ci by using a constexpr lookup table that maps uppercase

[PATCH] libstdc++: Work around modules ICE in [PR105297]

This makes the initializer for __table in __from_chars_alnum_to_val dependent in an artificial way, which works around the modules testsuite ICE reported in PR105297 by preventing the initializer from getting evaluated at parse time. Compared to the alternative workaround of using a non-local

[PATCH] libstdc++: Micro-optimize __from_chars_pow2_base

At the first iteration of __from_chars_pow2_base's main loop, we need to remember the value of the leading significant digit for sake of the overflow check at the end of the function (for bases other than 2). This patch manually unrolls this first iteration so as to not encumber the entire loop

Re: [PATCH] c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

On Sun, Apr 17, 2022 at 6:24 PM Jason Merrill wrote: > > On 4/15/22 07:22, Jakub Jelinek wrote: > > Hi! > > > > The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate > > PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it > > (variable, TARGET_EXPR slot, ...)

Re: [PATCH] libstdc++: Avoid double-deref of __first in ranges::minmax [PR104858]

On Thu, 14 Apr 2022, Jonathan Wakely wrote: > On Thu, 14 Apr 2022 at 16:21, Patrick Palka via Libstdc++ > wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and 11/10 > > once the branch is unfrozen? > > > > PR libstdc++/1

[PATCH] libstdc++: Stop defining _GLIBCXX_ASSERTIONS in floating_to_chars.cc

Assertions were originally enabled in the compiled-in floating-point std::to_chars implementation to help shake out any bugs, but they apparently impose a significant performance penalty, in particular for the hex formatting which is around 25% slower with assertions enabled. This seems too high

Re: [PATCH] libstdc++: Optimize std::has_single_bit

On Thu, Apr 14, 2022 at 2:59 PM Jonathan Wakely wrote: > > On Thu, 14 Apr 2022 at 19:17, Patrick Palka via Libstdc++ > wrote: > > > > This reimplements std::has_single_bit using the well-known bit-twiddilng > > trick[1], which is much faster than popcount on x86_

[PATCH] libstdc++: Optimize std::has_single_bit

This reimplements std::has_single_bit using the well-known bit-twiddilng trick[1], which is much faster than popcount on x86_64. Note that when __x is signed and maximally negative then this implementation invokes UB due to signed overflow, whereas the previous implementation would return true.

[PATCH] libstdc++: Avoid double-deref of __first in ranges::minmax [PR104858]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and 11/10 once the branch is unfrozen? PR libstdc++/104858 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__minmax_fn): Avoid dereferencing __first twice at the start. *

Re: [PATCH] libstdc++: Optimize integer std::from_chars

On Thu, 14 Apr 2022, Patrick Palka wrote: > This applies the following optimizations to the integer std::from_chars > implementation: > > 1. Use a lookup table for converting an alphanumeric digit to its > base-36 value instead of using a range test (for 0-9) and switch

[PATCH] libstdc++: Optimize integer std::from_chars

This applies the following optimizations to the integer std::from_chars implementation: 1. Use a lookup table for converting an alphanumeric digit to its base-36 value instead of using a range test (for 0-9) and switch (for a-z and A-Z). The table is constructed using a C++14

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

On Wed, Feb 16, 2022 at 2:47 PM Patrick Palka wrote: > > On Tue, 15 Feb 2022, Jason Merrill wrote: > > > On 2/15/22 17:00, Patrick Palka wrote: > > > On Tue, 15 Feb 2022, Jason Merrill wrote: > > > > > > > On 2/15/22 15:13, Patrick Palka wrote: >

Re: [PATCH] c++: requires-expr in pack expansion using pack [PR103105]

On Tue, Apr 12, 2022 at 12:33 PM Jason Merrill wrote: > > On 4/12/22 12:17, Patrick Palka wrote: > > Here after dependent substitution of {Ts...} into the alias 'wrap', > > since we never partially instantiate a requires-expr, we end up with a > > requires-expr whose

[PATCH] c++: requires-expr in pack expansion using pack [PR103105]

Here after dependent substitution of {Ts...} into the alias 'wrap', since we never partially instantiate a requires-expr, we end up with a requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an ARGUMENT_PACK_SELECT (which just resolves to the parameter pack Ts). Then when looking up the

[PATCH] c++: respect complain for -Wctad-maybe-unsupported [PR105143]

We were attempting to issue a -Wctad-maybe-unsupported warning even when complain=tf_none, which led to a crash in the first testcase below and a bogus error during SFINAE in the second testcase. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/11? PR

[PATCH] c++: implicit guides should inherit class constraints [PR104873]

An implicit guide already inherits the (rewritten) constraints of the constructor. Thus it seems natural that the guide must also inherit the constraints of the class template, since a constructor's constraints might assume the class's constraints are satisfied, and therefore checking these two

Re: [pushed] c++: parse trivial DMI immediately [PR96645]

On Wed, 30 Mar 2022, Jason Merrill via Gcc-patches wrote: > The recent change to reject __is_constructible for nested classes with DMI > is breaking some code loudly that was previously only silently broken. > Let's allow simple cases by immediately parsing DMI that do no name lookup; > then

[PATCH] c++: deduction for dependent class type of NTTP [PR105110]

Here deduction for the P/A pair V/a spuriously fails with types ‘A’ and ‘const A’ have incompatible cv-qualifiers because the argument type is const, whereas the parameter type is non-const. Since the type of an NTTP is always cv-unqualified, it seems natural to ignore cv-qualifiers on the

Re: [PATCH] c++: ICE with failed __is_constructible constraint [PR100474]

On Tue, 29 Mar 2022, Jason Merrill wrote: > On 3/29/22 15:22, Patrick Palka wrote: > > Here we're crashing when diagnosing a failed __is_constructible constraint > > because diagnose_atomic_constraint don't know how to diagnose a trait > > that diagnose_trait_expr doesn'

[PATCH] c++: ICE with failed __is_constructible constraint [PR100474]

Here we're crashing when diagnosing a failed __is_constructible constraint because diagnose_atomic_constraint don't know how to diagnose a trait that diagnose_trait_expr doesn't specifically handle. This patch fixes this by falling through to the default case in this situation. Bootstrapped and

[committed] c-family: Add -Wmisleading-indentation testcase [PR71637]

We no longer emit a bogus warning for the below testcase after r11-3266-g4839de55e2c986. Tested on x86_64-pc-linux-gnu, committed to trunk as obvious. PR c++/71637 gcc/testsuite/ChangeLog: * c-c++-common/Wmisleading-indentation-6.c: New test. ---

[PATCH] c++: ICE during constrained template friend matching [PR105064]

Here during declaration matching for the two constrained template friends, we crash from maybe_substitute_reqs_for because the second friend doesn't yet have DECL_TEMPLATE_INFO set (we're being called indirectly from push_template_decl). As far as I can tell, this situation happens only when

[PATCH] c++: reject concept w/ multiple tparm lists [PR105067]

We weren't rejecting a concept declared with multiple template parameter lists. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? PR c++/105067 gcc/cp/ChangeLog: * pt.cc (finish_concept_definition): Require that a concept is declared with

[PATCH] c++: ICE when building builtin operator->* set [PR103455]

When constructing the builtin operator->* candidate set according to the available conversion functions for each operand type, we end up considering a candidate with C1=T (a TEMPLATE_TYPE_PARM) and C2=F, during which we crash from lookup_base because dependent_type_p sees a TEMPLATE_TYPE_PARM when

[PATCH] c++: diagnosing if-stmt with non-constant branches [PR105050]

When an if-stmt is deemed non-constant because both of its branches are non-constant, we issue a rather generic error which, given that it points to the 'if' token, misleadingly suggests the condition is at fault: constexpr-105050.C:8:3: error: expression ‘’ is not a constant expression

Re: [PATCH] c++: memory corruption during name lookup w/ modules [PR99479]

On Thu, 17 Mar 2022, Patrick Palka wrote: > On Tue, Mar 1, 2022 at 8:13 AM Patrick Palka wrote: > > > > On Thu, Feb 17, 2022 at 3:24 PM Patrick Palka wrote: > > > > > > name_lookup::search_unqualified uses a statically allocated vector > > > in o

[PATCH] c++: missing SFINAE for consteval calls [PR104620]

Here we weren't respecting SFINAE when evaluating a substituted call to a consteval function, which caused us to reject the new testcase below. This patch fixes this by making build_over_call use the SFINAE-friendly version of cxx_constant_value. This change causes us to no longer diagnose ahead

Re: [pushed] c++: using from enclosing class template [PR105006]

On Wed, 23 Mar 2022, Jason Merrill via Gcc-patches wrote: > Here, DECL_DEPENDENT_P was false for the second using because Row is > "the current instantiation", so lookup succeeds. But since Row itself has a > dependent using-decl for operator(), the set of functions imported by the > second

Re: [PATCH] c++: alias template arguments are evaluated [PR101906]

On Tue, 22 Mar 2022, Patrick Palka wrote: > Here we're neglecting to clear cp_unevaluated_operand when substituting > into the arguments of the alias template-id skip<(T(), 0), T> with T=A, > which means cp_unevaluated_operand remains set during mark_used for > A::A() and so w

[PATCH] c++: alias template arguments are evaluated [PR101906]

Here we're neglecting to clear cp_unevaluated_operand when substituting into the arguments of the alias template-id skip<(T(), 0), T> with T=A, which means cp_unevaluated_operand remains set during mark_used for A::A() and so we never synthesize it. Later constant evaluation for the substituted

Re: [pushed] c++: designated init and aggregate members [PR102337]

On Mon, 21 Mar 2022, Jason Merrill via Gcc-patches wrote: > Our C++20 designated initializer handling was broken with members of class > type; we would find the relevant member and then try to find a member of > the member with the same name. Or we would sometimes ignore the designator >

Re: [PATCH] c++: memory corruption during name lookup w/ modules [PR99479]

On Tue, Mar 1, 2022 at 8:13 AM Patrick Palka wrote: > > On Thu, Feb 17, 2022 at 3:24 PM Patrick Palka wrote: > > > > name_lookup::search_unqualified uses a statically allocated vector > > in order to avoid repeated reallocation, under the assumption that > >

[PATCH] c++: further lookup_member simplification

As a followup to r12-7656-gffe9c0a0d3564a, this minor patch condenses the handling of ambiguity and access w.r.t. the value of 'protect' so that it more clearly matches the function comment. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? gcc/cp/ChangeLog:

Re: [PATCH] c++: fold calls to std::move/forward [PR96780]

On Tue, 15 Mar 2022, Jason Merrill wrote: > On 3/15/22 10:03, Patrick Palka wrote: > > On Mon, 14 Mar 2022, Jason Merrill wrote: > > > > > On 3/14/22 13:13, Patrick Palka wrote: > > > > On Fri, 11 Mar 2022, Jason Merrill wrote: > > > >

Re: [PATCH] libstdc++: Ensure that std::from_chars is declared when supported

On Mon, 14 Mar 2022, Jonathan Wakely wrote: > On Mon, 14 Mar 2022 at 14:17, Patrick Palka via Libstdc++ > wrote: > > > > On Fri, 11 Mar 2022, Jonathan Wakely wrote: > > > > > Patrick, I think this is right, but please take a look to double check. > > &g

Re: [PATCH] c++: fold calls to std::move/forward [PR96780]

On Mon, 14 Mar 2022, Jason Merrill wrote: > On 3/14/22 13:13, Patrick Palka wrote: > > On Fri, 11 Mar 2022, Jason Merrill wrote: > > > > > On 3/10/22 11:27, Patrick Palka wrote: > > > > On Wed, 9 Mar 2022, Jason Merrill wrote: > > > >

[PATCH] c++: extraneous access error with ambiguous lookup [PR103177]

When a lookup is ambiguous, lookup_member still attempts to check access of the first member found before diagnosing the ambiguity and erroring out, which may cause us to issue an extraneous access error in case of ambiguous lookup as in the testcase below (for B1::foo). This patch fixes this by

Re: [PATCH] c++: fold calls to std::move/forward [PR96780]

On Fri, 11 Mar 2022, Jason Merrill wrote: > On 3/10/22 11:27, Patrick Palka wrote: > > On Wed, 9 Mar 2022, Jason Merrill wrote: > > > > > On 3/1/22 18:08, Patrick Palka wrote: > > > > A well-formed call to std::move/forward is equivalent to a cast, but the

Re: [PATCH] libstdc++: Ensure that std::from_chars is declared when supported

On Fri, 11 Mar 2022, Jonathan Wakely wrote: > Patrick, I think this is right, but please take a look to double check. > > I think we should fix the feature-test macro conditions for gcc-11 too, > although it's a bit more complicated there. It should depend on IEEE > float and double *and*

Re: [PATCH] c++: Fix ICE with non-constant satisfaction [PR98644]

On Thu, 10 Mar 2022, Jason Merrill wrote: > On 3/1/22 00:10, Patrick Palka wrote: > > On Tue, 19 Jan 2021, Jason Merrill wrote: > > > > > On 1/13/21 12:05 PM, Patrick Palka wrote: > > > > In the below testcase, the expression of the atomic constrain

Re: [PATCH] c++: return-type-req in constraint using only outer tparms [PR104527]

On Thu, 10 Mar 2022, Jason Merrill wrote: > On 2/16/22 15:56, Patrick Palka wrote: > > On Tue, 15 Feb 2022, Jason Merrill wrote: > > > > > On 2/14/22 11:32, Patrick Palka wrote: > > > > Here the template context for the atomic constraint has two levels of &

[PATCH] c++: Fix ICE with bad conversion shortcutting [PR104622]

When shortcutting bad conversions during overload resolution, we assume argument conversions get computed in sequential order and that therefore we just need to inspect the last conversion in order to determine if _any_ conversion is missing. But this assumption turns out to be false for

Re: [PATCH] c++: naming a dependently-scoped template for CTAD [PR104641]

On Wed, 9 Mar 2022, Jason Merrill wrote: > On 3/9/22 10:39, Patrick Palka wrote: > > On Tue, 8 Mar 2022, Jason Merrill wrote: > > > > > On 3/2/22 14:32, Patrick Palka wrote: > > > > In order to be able to perform CTAD for a dependently-scoped template > &

Re: [PATCH] c++: fold calls to std::move/forward [PR96780]

On Wed, 9 Mar 2022, Jason Merrill wrote: > On 3/1/22 18:08, Patrick Palka wrote: > > A well-formed call to std::move/forward is equivalent to a cast, but the > > former being a function call means it comes with bloated debug info, which > > persists even after the call

[committed] libstdc++: Avoid implicit narrowing from uint128_t [PR104859]

We need to be explicit about narrowing conversions from uint128_t since, on targets that lack __int128, this type is defined as an integer-class type that is only _explicitly_ convertible to the builtin integer types. This issue was latent until r12-7563-ge32869a17b788b made the frontend correctly

Re: [PATCH] contrib: Fix non-portable sed commands in gcc-descr [PR102664/]

On Wed, Mar 9, 2022 at 8:54 AM Mikael Morin wrote: > > Hello, > > Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit : > > Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in release > > branch numbers, where > > a leading zero does not occur. > > > Note that you also

Re: [PATCH] c++: naming a dependently-scoped template for CTAD [PR104641]

On Tue, 8 Mar 2022, Jason Merrill wrote: > On 3/2/22 14:32, Patrick Palka wrote: > > In order to be able to perform CTAD for a dependently-scoped template > > such as A::B in the testcase below, we need to permit a > > typename-specifier to resolve to a template as pe

Re: [PATCH] c++: detecting copy-init context during CTAD [PR102137]

On Tue, 8 Mar 2022, Jason Merrill wrote: > On 3/8/22 14:38, Patrick Palka wrote: > > On Tue, 8 Mar 2022, Jason Merrill wrote: > > > > > On 3/8/22 11:36, Patrick Palka wrote: > > > > On Mon, 7 Mar 2022, Jason Merrill wrote: > > > >

Re: [PATCH] c++: non-constant non-dependent decltype folding [PR104823]

On Tue, 8 Mar 2022, Jason Merrill wrote: > On 3/8/22 12:54, Patrick Palka wrote: > > > > > > On Mon, 7 Mar 2022, Jason Merrill wrote: > > > > > On 3/7/22 14:41, Patrick Palka wrote: > > > > instantiate_non_dependent_expr_sfinae instantiat

Re: [PATCH] c++: detecting copy-init context during CTAD [PR102137]

On Tue, 8 Mar 2022, Jason Merrill wrote: > On 3/8/22 11:36, Patrick Palka wrote: > > On Mon, 7 Mar 2022, Jason Merrill wrote: > > > > > On 3/7/22 10:47, Patrick Palka wrote: > > > > On Fri, 4 Mar 2022, Jason Merrill wrote: > > > > > > > &

Re: [PATCH] c++: non-constant non-dependent decltype folding [PR104823]

On Mon, 7 Mar 2022, Jason Merrill wrote: > On 3/7/22 14:41, Patrick Palka wrote: > > instantiate_non_dependent_expr_sfinae instantiates only potentially > > constant expressions > > Hmm, that now strikes me as a problematic interface, as we don't know whether > what

Re: [PATCH] c++: detecting copy-init context during CTAD [PR102137]

On Mon, 7 Mar 2022, Jason Merrill wrote: > On 3/7/22 10:47, Patrick Palka wrote: > > On Fri, 4 Mar 2022, Jason Merrill wrote: > > > > > On 3/4/22 14:24, Patrick Palka wrote: > > > > Here we're failing to communicate to cp_finish_decl from tsubst_expr > &g

[PATCH] c++: non-constant non-dependent decltype folding [PR104823]

instantiate_non_dependent_expr_sfinae instantiates only potentially constant expressions, but when processing a non-dependent decltype operand we want to instantiate it even if it's non-constant since such non-dependent decltype is always resolved ahead of time. Currently finish_decltype_type

Re: [PATCH] c++: detecting copy-init context during CTAD [PR102137]

On Fri, 4 Mar 2022, Jason Merrill wrote: > On 3/4/22 14:24, Patrick Palka wrote: > > Here we're failing to communicate to cp_finish_decl from tsubst_expr > > that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING > > flag), which causes do_class_deducti

[PATCH] c++: detecting copy-init context during CTAD [PR102137]

Here we're failing to communicate to cp_finish_decl from tsubst_expr that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING flag), which causes do_class_deduction to always consider explicit deduction guides when performing CTAD for a templated variable initializer. We could

[committed] c++: Add testcase for already fixed PR [PR103443]

Fixed by r12-7264. PR c++/103443 gcc/testsuite/ChangeLog: * g++.dg/cpp2a/consteval29.C: New test. --- gcc/testsuite/g++.dg/cpp2a/consteval29.C | 20 1 file changed, 20 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval29.C diff --git

[PATCH] c++: merge default targs for function templates [PR65396]

We currently merge default template arguments for class templates, but not for function templates. This patch fixes this by splitting out the argument merging logic in redeclare_class_template into a separate function and using it in duplicate_decls as well. Bootstrapped and regtested on

[PATCH] c++: naming a dependently-scoped template for CTAD [PR104641]

In order to be able to perform CTAD for a dependently-scoped template such as A::B in the testcase below, we need to permit a typename-specifier to resolve to a template as per [dcl.type.simple]/2, at least when it appears in a CTAD-enabled context. This patch implements this using a new tsubst

[PATCH] c++: fold calls to std::move/forward [PR96780]

A well-formed call to std::move/forward is equivalent to a cast, but the former being a function call means it comes with bloated debug info, which persists even after the call has been inlined away, for an operation that is never interesting to debug. This patch addresses this problem in a

Re: [PATCH] c++: return-type-req in constraint using only outer tparms [PR104527]

On Wed, Feb 16, 2022 at 2:56 PM Patrick Palka wrote: > > On Tue, 15 Feb 2022, Jason Merrill wrote: > > > On 2/14/22 11:32, Patrick Palka wrote: > > > Here the template context for the atomic constraint has two levels of > > > template arguments, but since it depen

Re: [PATCH] c++: memory corruption during name lookup w/ modules [PR99479]

On Thu, Feb 17, 2022 at 3:24 PM Patrick Palka wrote: > > name_lookup::search_unqualified uses a statically allocated vector > in order to avoid repeated reallocation, under the assumption that > the function can't be called recursively. With modules however, > this assum

[PATCH] c++: improve location of fold expressions

This improves diagnostic quality for unsatisfied atomic constraints that consist of a fold expression, e.g. in concepts/diagnostics3.C: .../diagnostic3.C:10:22: note: the expression ‘(foo && ...) [with Ts = {int, char}]’ evaluated to ‘false’ 10 | requires (foo && ...) |

Re: [PATCH] c++: Fix ICE with non-constant satisfaction [PR98644]

On Tue, 19 Jan 2021, Jason Merrill wrote: > On 1/13/21 12:05 PM, Patrick Palka wrote: > > In the below testcase, the expression of the atomic constraint after > > substitution is (int *) NON_LVALUE_EXPR <1> != 0B which is not a C++ > > constant expression, but its TREE

[PATCH] libstdc++: Implement P2415R2 "What is a view?"

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? libstdc++-v3/ChangeLog: * include/bits/ranges_base.h (__detail::__is_initializer_list): Define. (viewable_range): Adjust as per P2415R2. * include/std/ranges (owning_view): Define as per P2415R2.

[committed] c++: Add testcase for already fixed PR [PR85493]

The a1 and a2 case were fixed (by diagnosing the invalid expression) with r11-434, and the a3 case with r8-7625. PR c++/85493 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/decltype80.C: New test. --- gcc/testsuite/g++.dg/cpp0x/decltype80.C | 16 1 file changed, 16

[PATCH] c++: memory corruption during name lookup w/ modules [PR99479]

name_lookup::search_unqualified uses a statically allocated vector in order to avoid repeated reallocation, under the assumption that the function can't be called recursively. With modules however, this assumption turns out to be false, and search_unqualified can be called recursively as

[PATCH] c++: implicit 'this' in noexcept-spec within class tmpl [PR94944]

Here when instantiating the noexcept-spec we fail to resolve the implicit object parameter for the call A::f() ultimately because maybe_instantiate_noexcept sets current_class_ptr/ref to the dependent 'this' (of type B) rather than the specialized 'this' (of type B). This ends up causing

[PATCH] c++: double non-dep folding from finish_compound_literal [PR104565]

In finish_compound_literal, we perform non-dependent expr folding before calling check_narrowing (ever since r9-5973). But ever since r10-7096, check_narrowing also performs non-dependent expr folding of its own. This double folding cause tsubst to see non-templated trees during the second

Re: [PATCH] c++: return-type-req in constraint using only outer tparms [PR104527]

On Tue, 15 Feb 2022, Jason Merrill wrote: > On 2/14/22 11:32, Patrick Palka wrote: > > Here the template context for the atomic constraint has two levels of > > template arguments, but since it depends only on the innermost argument > > T we use a single-level argument vecto

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

On Tue, 15 Feb 2022, Jason Merrill wrote: > On 2/15/22 17:00, Patrick Palka wrote: > > On Tue, 15 Feb 2022, Jason Merrill wrote: > > > > > On 2/15/22 15:13, Patrick Palka wrote: > > > > On Tue, 15 Feb 2022, Patrick Palka wrote: > &g

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

On Tue, 15 Feb 2022, Jason Merrill wrote: > On 2/15/22 15:13, Patrick Palka wrote: > > On Tue, 15 Feb 2022, Patrick Palka wrote: > > > > > Here we're crashing from potential_constant_expression because it tries > > > to perform trial evaluatio

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

On Tue, 15 Feb 2022, Patrick Palka wrote: > Here we're crashing from potential_constant_expression because it tries > to perform trial evaluation of the first operand '(bool)__r' of the > conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but > cxx_eval_constant_exp

[PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

Here we're crashing from potential_constant_expression because it tries to perform trial evaluation of the first operand '(bool)__r' of the conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but cxx_eval_constant_expression ICEs on unhandled trees (of which CAST_EXPR is one). Since

Re: [PATCH] c++: return-type-req in constraint using only outer tparms [PR104527]

On Mon, 14 Feb 2022, Patrick Palka wrote: > Here the template context for the atomic constraint has two levels of > template arguments, but since it depends only on the innermost argument > T we use a single-level argument vector during substitution into the > constraint (built by get

[PATCH] c++: return-type-req in constraint using only outer tparms [PR104527]

Here the template context for the atomic constraint has two levels of template arguments, but since it depends only on the innermost argument T we use a single-level argument vector during substitution into the constraint (built by get_mapped_args). We eventually pass this vector to

Re: [PATCH] libstdc++: Back out some changes in P2325R3 backport [PR103904]

On Fri, 11 Feb 2022, Patrick Palka wrote: > In the P2325R3 backport r11-9555 the relaxation of the constraints on > the partial specialization of __box (which is semantically equivalent to > the primary template, only more space efficient) means some > specializations of __box

[PATCH] libstdc++: Back out some changes in P2325R3 backport [PR103904]

In the P2325R3 backport r11-9555 the relaxation of the constraints on the partial specialization of __box (which is semantically equivalent to the primary template, only more space efficient) means some specializations of __box will now use the partial specialization instead of the primary

Re: [PATCH 1/3, 11 backport] libstdc++: Implement P2325 changes to default-constructibility of views

On Thu, 10 Feb 2022, Patrick Palka wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for the 11 branch? > The backport to the 10 branch hasn't been started yet, I figured it'd > be good to first get the 11 backport right then base the 10 backport > on the 11 one. > >

Re: [PATCH 1/3, 11 backport] libstdc++: Implement P2325 changes to default-constructibility of views

On Thu, 10 Feb 2022, Patrick Palka wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for the 11 branch? > The backport to the 10 branch hasn't been started yet, I figured it'd > be good to first get the 11 backport right then base the 10 backport > on the 11 one. > >

[PATCH 1/3, 11 backport] libstdc++: Implement P2325 changes to default-constructibility of views

Tested on x86_64-pc-linux-gnu, does this look OK for the 11 branch? The backport to the 10 branch hasn't been started yet, I figured it'd be good to first get the 11 backport right then base the 10 backport on the 11 one. NB: This backport of r12-1606 to the 11 branch deliberately omits parts of

[PATCH 3/3, 11 backport] libstdc++: invalid default init in _CachedPosition [PR101231]

The primary template for _CachedPosition is a dummy implementation for non-forward ranges, the iterators for which generally can't be cached. Because this implementation doesn't actually cache anything, _M_has_value is defined to be false and so calls to _M_get (which are always guarded by

[PATCH 2/3, 11 backport] libstdc++: Sync __cpp_lib_ranges macro defined in ranges_cmp.h

r12-1606 bumped the value of __cpp_lib_ranges defined in , but this macro is also defined in , so it needs to be updated there as well. PR libstdc++/103904 libstdc++-v3/ChangeLog: * include/bits/ranges_cmp.h (__cpp_lib_ranges): Adjust value. (cherry picked from commit

Re: [PATCH] c++: memfn lookup consistency and using-decls [PR104432]

On Wed, 9 Feb 2022, Jason Merrill wrote: > On 2/9/22 11:36, Patrick Palka wrote: > > On Wed, 9 Feb 2022, Jason Merrill wrote: > > > > > On 2/9/22 10:45, Patrick Palka wrote: > > > > In filter_memfn_lookup, we weren't correctly recognizing and matching up >

Re: [PATCH] c++: memfn lookup consistency and using-decls [PR104432]

On Wed, 9 Feb 2022, Jason Merrill wrote: > On 2/9/22 10:45, Patrick Palka wrote: > > In filter_memfn_lookup, we weren't correctly recognizing and matching up > > member functions introduced via a non-dependent using-decl. This caused > > us to crash in the below testcases

[PATCH] c++: memfn lookup consistency and using-decls [PR104432]

In filter_memfn_lookup, we weren't correctly recognizing and matching up member functions introduced via a non-dependent using-decl. This caused us to crash in the below testcases in which we correctly pruned the overload set for the non-dependent call ahead of time, but then at instantiation

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

On Thu, 3 Feb 2022, Jason Merrill wrote: > On 2/3/22 15:55, Patrick Palka wrote: > > On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote: > > > > > > On 2/3/22 12:04, Patrick Palka wrote: > > > > On Wed, 2 Feb 2022, Jason Merrill wrote: > > > &

[PATCH] c++: deducing only from noexcept-spec [PR80951]

The fail-fast predicate uses_deducible_template_parms used by unify_one_argument is neglecting to look inside the noexcept-spec of a function type, and this causes deduction to fail for the below testcase since the noexcept-spec is the only part of the type which contains a deducible template

[PATCH] c++: satisfaction value of type const bool [PR104410]

Here constant evaluation of the atomic constraint use_func_v with T=int sensibly yields an INTEGER_CST of type const bool, but the assert in satisfaction_value expects unqualified bool. Let's just relax the assert to accept cv-qualified bool more generally. Bootstrapped and regtested on

Re: [PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

On Thu, 3 Feb 2022, Jason Merrill wrote: > On 2/3/22 16:06, Patrick Palka wrote: > > On Thu, 3 Feb 2022, Jason Merrill wrote: > > > > > On 2/3/22 14:58, Patrick Palka wrote: > > > > When synthesizing a defaulted comparison op from > > > > mayb

Re: [PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

On Thu, 3 Feb 2022, Jason Merrill wrote: > On 2/3/22 14:58, Patrick Palka wrote: > > When synthesizing a defaulted comparison op from > > maybe_instantiate_noexcept, we seem to be forgetting to instantiate the > > noexcept-spec afterwards. > > Hmm, there shouldn't

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote: > > On 2/3/22 12:04, Patrick Palka wrote: > > On Wed, 2 Feb 2022, Jason Merrill wrote: > > > >> On 2/2/22 12:09, Patrick Palka wrote: > >>> The satisfaction cache needs to look through ARGUMENT_PACK_SELECT

[PATCH] c++: conditional noexcept-spec on defaulted comparison op [PR96242]

When synthesizing a defaulted comparison op from maybe_instantiate_noexcept, we seem to be forgetting to instantiate the noexcept-spec afterwards. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 11? PR c++/96242 gcc/cp/ChangeLog: *

Re: [PATCH] c++: constrained auto in lambda using outer tparms [PR103706]

On Wed, 2 Feb 2022, Jason Merrill wrote: > On 2/2/22 13:21, Patrick Palka wrote: > > On Wed, 2 Feb 2022, Patrick Palka wrote: > > > > > Here we're crashing during satisfaction of the lambda's placeholder type > > > constraints because the constraints

Re: [PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

On Wed, 2 Feb 2022, Jason Merrill wrote: > On 2/2/22 12:09, Patrick Palka wrote: > > The satisfaction cache needs to look through ARGUMENT_PACK_SELECT > > template arguments before calling iterative_hash_template_arg and > > template_args_equal, which would otherwise crash.

[PATCH] c++: dependence of member's noexcept-spec [PR104079]

Here a stale value of TYPE_DEPENDENT_P/_P_VALID for f's function type after replacing its DEFERRED_NOEXCEPT with its parsed (dependent) noexcept-spec leads us to try to instantiate g's noexcept-spec (which incorrectly appears non-dependent) ahead of time, causing an ICE. This patch fixes this by

Re: [PATCH] c++: constrained auto in lambda using outer tparms [PR103706]

On Wed, 2 Feb 2022, Patrick Palka wrote: > Here we're crashing during satisfaction of the lambda's placeholder type > constraints because the constraints depend on the template arguments > from the enclosing scope, which aren't a part of the lambda's > DECL_TI_ARGS. So when ins

[PATCH] c++: lambda in pack expansion using outer pack in constraint [PR103706]

The satisfaction cache needs to look through ARGUMENT_PACK_SELECT template arguments before calling iterative_hash_template_arg and template_args_equal, which would otherwise crash. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 11? PR

[PATCH] c++: constrained auto in lambda using outer tparms [PR103706]

Here we're crashing during satisfaction of the lambda's placeholder type constraints because the constraints depend on the template arguments from the enclosing scope, which aren't a part of the lambda's DECL_TI_ARGS. So when inside a lambda, do_auto_deduction needs to add the "regenerating"

<    5   6   7   8   9   10   11   12   13   14   >