Re: [PATCH] c++: premature analysis of requires-expression [PR96410]

On 9/16/20 6:11 PM, Patrick Palka wrote: On Wed, 16 Sep 2020, Jason Merrill wrote: On 9/16/20 1:34 PM, Patrick Palka wrote: On Thu, 13 Aug 2020, Jason Merrill wrote: On 8/13/20 11:21 AM, Patrick Palka wrote: On Mon, 10 Aug 2020, Jason Merrill wrote: On 8/10/20 2:18 PM, Patrick Palka wrote

Re: [PATCH V2 0/4] Unify C and C++ handling of loops and switches

On 9/9/20 8:20 PM, Sandra Loosemore wrote: On 9/9/20 3:13 PM, Jason Merrill wrote: My impression from Jeff's analysis in January and David's in March was that many of the testsuite changes were from the C++ approach actually providing better results, so the reversal here surprises me.  Can yo

[pushed] c++: Layout decls with newly-complete type.

Martin's -Wplacement-new patch ran into a problem with DECL_SIZE not being set on an extern variable for which the type was not complete until after its declaration. complete_vars was deliberately not calling layout_decl for some reason, instead leaving that for expand_expr_real_1 much later in th

Re: [PATCH] c++: std::is_constant_evaluated inside a constraint [PR97051]

On 9/17/20 12:36 PM, Patrick Palka wrote: According to [expr.const]/14, the result of substitution into an atomic constraint is manifestly constant-evaluated; this patch adjusts the call to maybe_constant_value in satisfy_atom to that effect. Tested on x86_64-pc-linux-gnu, and also tested on the

Re: [PATCH] c++: Fix self-mapping in map_arguments [PR96531, PR97103]

On 9/18/20 4:07 PM, Patrick Palka wrote: With r10-8077 we stopped passing the argified current_template_parms to normalize_constraint_expression from finish_nested_requirement, and instead tweaked map_arguments to perform a self-mapping of parameters when args is NULL. We're currently not handli

Re: [PATCH] c++: Fix self-mapping in map_arguments [PR96531, PR97103]

On 9/18/20 8:42 PM, Patrick Palka wrote: On Fri, 18 Sep 2020, Patrick Palka wrote: On Fri, 18 Sep 2020, Jason Merrill wrote: On 9/18/20 4:07 PM, Patrick Palka wrote: With r10-8077 we stopped passing the argified current_template_parms to normalize_constraint_expression from finish_nested_req

Re: [PATCH] c++: Implement -Wctad-maybe-unsupported.

On 9/19/20 5:34 PM, Marek Polacek wrote: I noticed that clang++ has this CTAD warning and thought that it might be useful to have it. From clang++: "Some style guides want to allow using CTAD only on types that "opt-in"; i.e. on types that are designed to support it and not just types that *happ

Re: [PATCH] c++: Detect deduction guide redeclaration [PR97099]

On 9/19/20 5:34 PM, Marek Polacek wrote: [temp.deduct.guide]p3: Two deduction guide declarations in the same translation unit for the same class template shall not have equivalent parameter-declaration-clauses. So let's detect that. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

Re: [PATCH] c++: Return only in-scope tparms in keep_template_parm [PR95310]

On 9/19/20 3:49 PM, Patrick Palka wrote: In the testcase below, the dependent specializations iter_reference_t and iter_reference_t share the same tree due to specialization caching. So when find_template_parameters walks through the requires-expression (as part of normalization), it sees and in

Re: [PATCH v2] c++: Implement -Wctad-maybe-unsupported.

On 9/21/20 3:57 PM, Marek Polacek wrote: On Mon, Sep 21, 2020 at 01:04:27AM -0400, Jason Merrill via Gcc-patches wrote: On 9/19/20 5:34 PM, Marek Polacek wrote: I noticed that clang++ has this CTAD warning and thought that it might be useful to have it. From clang++: "Some style guides

Re: [PATCH] c++: DR 1722: Make lambda to function pointer conv noexcept [PR90583]

On 9/21/20 3:57 PM, Marek Polacek wrote: DR 1722 clarifies that the conversion function from lambda to pointer to function should be noexcept(true). Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. gcc/cp/ChangeLog: PR c++/90583 DR 1722 * lambda.c (ma

Re: [PATCH] c++: Ignore __sanitizer_ptr_{sub,cmp} builtin calls during constant expression evaluation [PR97145]

On 9/22/20 3:48 AM, Jakub Jelinek wrote: Hi! These two builtin calls are added already during parsing before pointer subtractions or comparisons, normally they perform runtime verification of whether the pointers point to the same object or different objects, but during constant expressione valu

Re: [PATCH] c++: Return only in-scope tparms in keep_template_parm [PR95310]

On 9/22/20 2:41 PM, Patrick Palka wrote: On Tue, 22 Sep 2020, Patrick Palka wrote: On Mon, 21 Sep 2020, Jason Merrill wrote: On 9/19/20 3:49 PM, Patrick Palka wrote: In the testcase below, the dependent specializations iter_reference_t and iter_reference_t share the same tree due to speciali

Re: [PATCH v3] c, c++: Implement -Wsizeof-array-div [PR91741]

On 9/22/20 1:29 PM, Marek Polacek wrote: Ping. The C++ change is OK. On Tue, Sep 15, 2020 at 04:33:05PM -0400, Marek Polacek via Gcc-patches wrote: On Tue, Sep 15, 2020 at 09:04:41AM +0200, Jakub Jelinek via Gcc-patches wrote: On Mon, Sep 14, 2020 at 09:30:44PM -0400, Marek Polacek via Gcc-

Re: [PATCH] tree-optimization/97151 - improve PTA for C++ operator delete

On 9/23/20 4:14 AM, Richard Biener wrote: C++ operator delete, when DECL_IS_REPLACEABLE_OPERATOR_DELETE_P, does not cause the deleted object to be escaped. It also has no other interesting side-effects for PTA so skip it like we do for BUILT_IN_FREE. Hmm, this is true of the default implementa

Re: [PATCH] tree-optimization/97151 - improve PTA for C++ operator delete

On 9/23/20 2:42 PM, Richard Biener wrote: On September 23, 2020 7:53:18 PM GMT+02:00, Jason Merrill wrote: On 9/23/20 4:14 AM, Richard Biener wrote: C++ operator delete, when DECL_IS_REPLACEABLE_OPERATOR_DELETE_P, does not cause the deleted object to be escaped. It also has no other interest

Re: [PATCH] tree-optimization/97151 - improve PTA for C++ operator delete

On 9/24/20 3:43 AM, Richard Biener wrote: On Wed, 23 Sep 2020, Jason Merrill wrote: On 9/23/20 2:42 PM, Richard Biener wrote: On September 23, 2020 7:53:18 PM GMT+02:00, Jason Merrill wrote: On 9/23/20 4:14 AM, Richard Biener wrote: C++ operator delete, when DECL_IS_REPLACEABLE_OPERATOR_DEL

Re: [PATCH] tree-optimization/97151 - improve PTA for C++ operator delete

On 9/25/20 2:30 AM, Richard Biener wrote: On Thu, 24 Sep 2020, Jason Merrill wrote: On 9/24/20 3:43 AM, Richard Biener wrote: On Wed, 23 Sep 2020, Jason Merrill wrote: On 9/23/20 2:42 PM, Richard Biener wrote: On September 23, 2020 7:53:18 PM GMT+02:00, Jason Merrill wrote: On 9/23/20 4:1

Re: [PATCH] c++: Implement -Wrange-loop-construct [PR94695]

On 9/24/20 8:05 PM, Marek Polacek wrote: This new warning can be used to prevent expensive copies inside range-based for-loops, for instance: struct S { char arr[128]; }; void fn () { S arr[5]; for (const auto x : arr) { } } where auto deduces to S and then we copy the big S

Re: [PATCH] c++: Fix up default initialization with consteval default ctor [PR96994]

On 9/15/20 3:57 AM, Jakub Jelinek wrote: Hi! The following testcase is miscompiled (in particular the a and i initialization). The problem is that build_special_member_call due to the immediate constructors (but not evaluated in constant expression mode) doesn't create a CALL_EXPR, but returns

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 9/22/20 4:05 PM, Martin Sebor wrote: The rebased and retested patches are attached. On 9/21/20 3:17 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html (I'm working on rebasing the patch on top of the latest trunk which has changed some of the

Re: [PATCH v2] c++: Implement -Wrange-loop-construct [PR94695]

On 9/25/20 6:01 PM, Marek Polacek wrote: On Fri, Sep 25, 2020 at 04:09:44PM -0400, Jason Merrill via Gcc-patches wrote: On 9/24/20 8:05 PM, Marek Polacek wrote: This new warning can be used to prevent expensive copies inside range-based for-loops, for instance: struct S { char arr[128

Re: [PATCH v3] c++: Implement -Wrange-loop-construct [PR94695]

On 9/28/20 12:30 PM, Marek Polacek wrote: On Sat, Sep 26, 2020 at 01:22:41AM -0400, Jason Merrill wrote: +bool +ref_conv_binds_directly_p (tree type, tree expr) +{ + gcc_assert (TYPE_REF_P (type)); + conversion *conv = implicit_conversion (type, TREE_TYPE (expr), expr, +

Re: [PATCH] tree-optimization/97151 - improve PTA for C++ operator delete

On 9/28/20 3:56 AM, Richard Biener wrote: On Fri, 25 Sep 2020, Jason Merrill wrote: On 9/25/20 2:30 AM, Richard Biener wrote: On Thu, 24 Sep 2020, Jason Merrill wrote: On 9/24/20 3:43 AM, Richard Biener wrote: On Wed, 23 Sep 2020, Jason Merrill wrote: On 9/23/20 2:42 PM, Richard Biener wr

Re: [PATCH] c++: Incomplete parameter mappings during normalization

On 9/25/20 4:44 PM, Patrick Palka wrote: In the testcase concepts7.C below, we currently reject the call to f1 but we accept the call to f2, even though their associated constraints are functionally equivalent. Rather, because they are not functionally equivalent. The reason satisfaction diff

Re: [PATCH] tree-optimization/97151 - improve PTA for C++ operator delete

On 9/28/20 3:09 PM, Jason Merrill wrote: On 9/28/20 3:56 AM, Richard Biener wrote: On Fri, 25 Sep 2020, Jason Merrill wrote: On 9/25/20 2:30 AM, Richard Biener wrote: On Thu, 24 Sep 2020, Jason Merrill wrote: On 9/24/20 3:43 AM, Richard Biener wrote: On Wed, 23 Sep 2020, Jason Merrill wrot

Re: [PATCH] c++: Handle std::construct_at on automatic vars during constant evaluation [PR97195]

On 9/30/20 4:01 AM, Jakub Jelinek wrote: Hi! As mentioned in the PR, we only support due to a bug in constant expressions std::construct_at on non-automatic variables, because we VERIFY_CONSTANT the second argument of placement new, which fails verification if it is an address of an automatic va

Re: [PATCH v2] c++: Fix up default initialization with consteval default ctor [PR96994]

On 9/30/20 3:57 AM, Jakub Jelinek wrote: On Fri, Sep 25, 2020 at 04:30:26PM -0400, Jason Merrill via Gcc-patches wrote: On 9/15/20 3:57 AM, Jakub Jelinek wrote: The following testcase is miscompiled (in particular the a and i initialization). The problem is that build_special_member_call due

Re: [PATCH] c++: ICE in dependent_type_p with constrained auto [PR97052]

On 9/29/20 5:01 PM, Patrick Palka wrote: This patch fixes an "unguarded" call to coerce_template_parms in build_standard_check: processing_template_decl could be zero if we we get here during processing of the first 'auto' parameter of an abbreviated function template. In the testcase below, thi

Re: [PATCH] c++: CTAD and explicit deduction guides for copy-list-init [PR90210]

On 9/19/20 5:33 PM, Marek Polacek wrote: This PR points out that we accept template struct tuple { tuple(T); }; // #1 template explicit tuple(T t) -> tuple; // #2 tuple t = { 1 }; despite the 'explicit' deduction guide in a copy-list-initialization context. That's because in deduction

Re: [PATCH] tree-optimization/97151 - improve PTA for C++ operator delete

On 10/1/20 5:26 AM, Richard Biener wrote: On Wed, 30 Sep 2020, Jason Merrill wrote: On 9/28/20 3:09 PM, Jason Merrill wrote: On 9/28/20 3:56 AM, Richard Biener wrote: On Fri, 25 Sep 2020, Jason Merrill wrote: On 9/25/20 2:30 AM, Richard Biener wrote: On Thu, 24 Sep 2020, Jason Merrill wrot

Re: [PATCH] c++: Fix printing of C++20 template parameter object [PR97014]

On 10/1/20 5:49 PM, Marek Polacek wrote: No one is interested in the mangled name of the C++20 template parameter object for a class NTTP. So instead of printing required for the satisfaction of ‘positive’ [with T = X<::_ZTAXtl5ratioLin1ELi2EEE>] let's print required for the satisfacti

Re: [PATCH] c++: Verify 'this' of NS member functions in constexpr [PR97230]

On 10/1/20 1:08 PM, Marek Polacek wrote: This PR points out that when we're invoking a non-static member function on a null instance during constant evaluation, we should reject. cxx_eval_call_expression calls cxx_bind_parameters_in_call which evaluates function arguments, but it won't detect pro

Re: [PATCH] c++: ICE in dependent_type_p with constrained auto [PR97052]

On 10/5/20 4:30 PM, Patrick Palka wrote: On Wed, 30 Sep 2020, Jason Merrill wrote: On 9/29/20 5:01 PM, Patrick Palka wrote: This patch fixes an "unguarded" call to coerce_template_parms in build_standard_check: processing_template_decl could be zero if we we get here during processing of the f

Re: [PATCH] c++: Distinguish btw. alignof and __alignof__ in cp_tree_equal [PR97273]

On 10/4/20 11:28 PM, Patrick Palka wrote: cp_tree_equal currently considers alignof the same as __alignof__, but these operators are semantically different ever since r8-7957. In the testcase below, this causes the second static_assert to fail on targets where alignof(double) != __alignof__(doub

Re: [PATCH] debug: Pass --gdwarf-N to assembler if fixed gas is detected during configure

On 10/6/20 11:54 AM, Mark Wielaard wrote: Hi, On Fri, 2020-09-18 at 17:21 +0200, Mark Wielaard wrote: On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote: Ok, here it is in patch form. I've briefly tested it, with the older binutils I have around (no --gdwarf-N support), with latest gas (--

Re: [PATCH] c++: typename in out-of-class member function definitions [PR97297]

On 10/5/20 7:07 PM, Marek Polacek wrote: I was notified that our P0634R3 (Down with typename) implementation has a flaw: when we have an out-of-class member function definition, we still required 'typename' for its parameters. For example here: template struct S { int simple(T::type);

Re: [PATCH] make handling of zero-length arrays in C++ pretty printer more robust (PR 97201)

On 9/25/20 2:58 PM, Martin Sebor wrote: The C and C++ representations of zero-length arrays are different: C uses a null upper bound of the type's domain while C++ uses SIZE_MAX.  This makes the middle end logic more complicated (and prone to mistakes) because it has to be prepared for both.  A r

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 9/28/20 6:01 PM, Martin Sebor wrote: On 9/25/20 11:17 PM, Jason Merrill wrote: On 9/22/20 4:05 PM, Martin Sebor wrote: The rebased and retested patches are attached. On 9/21/20 3:17 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html (I'm wo

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 10/7/20 10:42 AM, Martin Sebor wrote: On 10/7/20 8:26 AM, Jason Merrill wrote: On 9/28/20 6:01 PM, Martin Sebor wrote: On 9/25/20 11:17 PM, Jason Merrill wrote: On 9/22/20 4:05 PM, Martin Sebor wrote: The rebased and retested patches are attached. On 9/21/20 3:17 PM, Martin Sebor wrote: P

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 10/7/20 11:19 AM, Martin Sebor wrote: On 10/7/20 9:07 AM, Jason Merrill wrote: On 10/7/20 10:42 AM, Martin Sebor wrote: On 10/7/20 8:26 AM, Jason Merrill wrote: On 9/28/20 6:01 PM, Martin Sebor wrote: On 9/25/20 11:17 PM, Jason Merrill wrote: On 9/22/20 4:05 PM, Martin Sebor wrote: The r

Re: [PATCH v2] c++: Verify 'this' of NS member functions in constexpr [PR97230]

On 10/7/20 2:48 PM, Marek Polacek wrote: On Tue, Oct 06, 2020 at 01:06:37AM -0400, Jason Merrill via Gcc-patches wrote: On 10/1/20 1:08 PM, Marek Polacek wrote: @@ -2496,8 +2502,72 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree t, new_obj = NULL_TREE

Re: [PATCH] c++: Set the constraints of a class type sooner [PR96229]

On 9/29/20 10:26 AM, Patrick Palka wrote: In the testcase below, during processing (at parse time) of Y's base class X, convert_template_argument calls is_compatible_template_arg to check if the template argument Y is no more constrained than the parameter P. But at this point we haven't yet set

Re: [PATCH] c++: ICE in dependent_type_p with constrained auto [PR97052]

On 10/7/20 10:46 AM, Patrick Palka wrote: On Tue, 6 Oct 2020, Jason Merrill wrote: On 10/5/20 4:30 PM, Patrick Palka wrote: On Wed, 30 Sep 2020, Jason Merrill wrote: On 9/29/20 5:01 PM, Patrick Palka wrote: This patch fixes an "unguarded" call to coerce_template_parms in build_standard_chec

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 10/7/20 4:11 PM, Martin Sebor wrote: On 10/7/20 1:28 PM, Jason Merrill wrote: On 10/7/20 11:19 AM, Martin Sebor wrote: On 10/7/20 9:07 AM, Jason Merrill wrote: On 10/7/20 10:42 AM, Martin Sebor wrote: On 10/7/20 8:26 AM, Jason Merrill wrote: On 9/28/20 6:01 PM, Martin Sebor wrote: On 9/2

Re: [PATCH] c++: Fix P0846 (ADL and function templates) in template [PR97010]

On 9/10/20 6:15 PM, Marek Polacek wrote: To quickly recap, P0846 says that a name is also considered to refer to a template if it is an unqualified-id followed by a < and name lookup finds either one or more functions or finds nothing. In a template, when parsing a function call that has type-de

Re: libstdc++: Attempt to resolve PR83562

On 10/7/20 10:52 PM, Liu Hao via Gcc-patches wrote: [Please CC me as I am not subscribed to this list.] [This patch is only a draft and has not been tested at all.] Some details have been discussed in [1]. mingw-w64 has got an implementation [2] [3] for static libraries, but it takes a destru

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 10/8/20 3:18 PM, Martin Sebor wrote: On 10/7/20 3:01 PM, Jason Merrill wrote: On 10/7/20 4:11 PM, Martin Sebor wrote: ... For the various member functions, please include the comments with the definition as well as the in-class declaration. Only one access_ref member function is defined

[pushed] c++: Fix member alias template in C++17 and up. [PR96805]

Here we're trying to push into a::c in order to instantiate t, but were building a TYPENAME_TYPE for it because a isn't open yet. Don't do that when we know we're trying to enter the scope. Tested x86_64-pc-linux-gnu, applying to trunk and 10. gcc/cp/ChangeLog: PR c++/96805 PR c

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 10/9/20 10:51 AM, Martin Sebor wrote: On 10/8/20 1:40 PM, Jason Merrill wrote: On 10/8/20 3:18 PM, Martin Sebor wrote: On 10/7/20 3:01 PM, Jason Merrill wrote: On 10/7/20 4:11 PM, Martin Sebor wrote: ... For the various member functions, please include the comments with the definition as

Re: [PATCH] c++: Distinguish btw. alignof and __alignof__ in cp_tree_equal [PR97273]

On 10/9/20 4:48 AM, Jakub Jelinek wrote: On Tue, Oct 06, 2020 at 03:40:52PM -0400, Jason Merrill via Gcc-patches wrote: On 10/4/20 11:28 PM, Patrick Palka wrote: cp_tree_equal currently considers alignof the same as __alignof__, but these operators are semantically different ever since r8-7957

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

On 10/11/20 6:45 PM, Martin Sebor wrote: On 10/9/20 9:13 AM, Jason Merrill wrote: On 10/9/20 10:51 AM, Martin Sebor wrote: On 10/8/20 1:40 PM, Jason Merrill wrote: On 10/8/20 3:18 PM, Martin Sebor wrote: On 10/7/20 3:01 PM, Jason Merrill wrote: On 10/7/20 4:11 PM, Martin Sebor wrote: ... F

Re: [PATCH] c++: some missing-SFINAE fixes

On 9/13/22 07:45, Patrick Palka wrote: It looks like we aren't respecting SFINAE for: * an invalid/non-constant conditional explicit-specifier * a non-constant conditional noexcept-specifier * a non-constant argument to __integer_pack This patch fixes these issues in the usual way, by

Re: [PATCH] c++: some missing-SFINAE fixes

On 9/13/22 09:46, Patrick Palka wrote: On Tue, 13 Sep 2022, Jason Merrill wrote: On 9/13/22 07:45, Patrick Palka wrote: It looks like we aren't respecting SFINAE for: * an invalid/non-constant conditional explicit-specifier * a non-constant conditional noexcept-specifier * a non-c

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

On 9/12/22 04:05, Jakub Jelinek wrote: Hi! The following patch implements the compiler part of C++23 P1467R9 - Extended floating-point types and standard names compiler part by introducing _Float{16,32,64,128} as keywords and builtin types like they are implemented for C already since GCC 7. It

Re: [PATCH] Introduce -nolibstdc++ option

On 6/24/22 01:23, Alexandre Oliva via Gcc-patches wrote: On Jun 23, 2022, Alexandre Oliva wrote: Here's the patch. Regstrapped on x86_64-linux-gnu, also tested with a cross to aarch64-rtems6. Ok to install? Introduce -nostdlib++ option Uhh, I went ahead and installed this. The earlier

Re: [PATCH] Introduce -nolibstdc++ option

On 9/16/22 07:52, Jason Merrill wrote: On 6/24/22 01:23, Alexandre Oliva via Gcc-patches wrote: On Jun 23, 2022, Alexandre Oliva wrote: Here's the patch.  Regstrapped on x86_64-linux-gnu, also tested with a cross to aarch64-rtems6.  Ok to install? Introduce -nostdlib++ option Uhh, I went

Re: [PATCH] c++: constraint matching, TEMPLATE_ID_EXPR, current inst

On 9/15/22 11:58, Patrick Palka wrote: Here we're crashing during constraint matching for the instantiated hidden friends due to two issues with dependent substitution into a TEMPLATE_ID_EXPR naming a template from the current instantiation (as performed from maybe_substitute_reqs_for for C<3> wi

Re: [PATCH] c++: 'mutable' within constexpr [PR92505]

On 9/15/22 14:03, Patrick Palka wrote: This patch permits accessing 'mutable' members of local objects during constexpr evaluation (which other compilers seem to accept in C++14 mode, while we reject), while continuing to reject it for global objects (as in the last line of cpp0x/constexpr-mutabl

[pushed] c++: member fn in omp loc list [PR106858]

this->f names a member function, which isn't an addressable lvalue. Give a helpful error instead of crashing. The first hunk makes the error range cover the whole expression. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/106858 gcc/cp/ChangeLog: * parser.cc (cp_parser_

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

On 9/16/22 06:19, Thomas Neumann wrote: The __register_frame/__deregister_frame functions are used to register unwinding frames from JITed code in a sorted list. That list itself is protected by object_mutex, which leads to terrible performance in multi-threaded code and is somewhat expensive eve

Re: [PATCH] c++: Implement C++23 P1169R4 - static operator() [PR106651]

On 9/13/22 12:42, Jakub Jelinek wrote: Hi! The following patch attempts to implement C++23 P1169R4 - static operator() paper's compiler side (there is some small library side too not implemented yet). This allows static members as user operator() declarations and static specifier on lambdas wit

Re: [PATCH] c++: constraint matching, TEMPLATE_ID_EXPR, current inst

On 9/16/22 10:59, Patrick Palka wrote: On Fri, 16 Sep 2022, Jason Merrill wrote: On 9/15/22 11:58, Patrick Palka wrote: Here we're crashing during constraint matching for the instantiated hidden friends due to two issues with dependent substitution into a TEMPLATE_ID_EXPR naming a template fro

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

On 9/16/22 13:34, Jakub Jelinek wrote: On Fri, Sep 16, 2022 at 01:48:54PM +0200, Jason Merrill wrote: On 9/12/22 04:05, Jakub Jelinek wrote: The following patch implements the compiler part of C++23 P1467R9 - Extended floating-point types and standard names compiler part by introducing _Float{1

Re: [PATCH] c++: Implement C++23 P1169R4 - static operator() [PR106651]

On 9/17/22 02:42, Jakub Jelinek wrote: On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote: On 9/13/22 12:42, Jakub Jelinek wrote: The following patch attempts to implement C++23 P1169R4 - static operator() paper's compiler side (there is some small library side too not implemented ye

Re: [PATCH] c++: Implement __is_{nothrow_,}convertible [PR106784]

On 9/22/22 09:39, Marek Polacek wrote: To improve compile times, the C++ library could use compiler built-ins rather than implementing std::is_convertible (and _nothrow) as class templates. This patch adds the built-ins. We already have __is_constructible and __is_assignable, and the nothrow fo

Re: [PATCH] c++: ICE-on-invalid with designated initializer [PR106983]

On 9/20/22 17:05, Marek Polacek wrote: We ICE in the code added in r12-7117: type_build_dtor_call gets the error_mark_node because the type of 'prev' wasn't declared. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. PR c++/106983 gcc/cp/ChangeLog: * typeck2.

Re: [PATCH] Avoid depending on destructor order

On 9/19/22 12:20, Thomas Neumann wrote: In some scenarios (e.g., when mixing gcc and clang code), it can happen that frames are deregistered after the lookup structure has already been destroyed. That in itself would be fine, but it triggers an assert in __deregister_frame_info_bases that expects

Re: [PATCH] c++: Implement __is_{nothrow_,}convertible [PR106784]

On 9/23/22 10:34, Marek Polacek wrote: On Thu, Sep 22, 2022 at 06:14:44PM -0400, Jason Merrill wrote: On 9/22/22 09:39, Marek Polacek wrote: To improve compile times, the C++ library could use compiler built-ins rather than implementing std::is_convertible (and _nothrow) as class templates. Th

Re: [PATCH] c++: Instantiate less when evaluating __is_convertible

On 9/26/22 11:51, Patrick Palka wrote: On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote: Jon reported that evaluating __is_convertible in this test leads to instantiating char_traits::eq, which is invalid (because we are trying to call a member function on a char) and so we fail to comp

Re: [PATCH] c++: Don't quote nothrow in diagnostic

On 9/26/22 03:50, Richard Biener wrote: On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via Gcc-patches wrote: In Jason noticed that we quote "nothrow" in diagnostics even though it's not a keyword in C++. Just removing the

Re: [PATCH v2] c++: Instantiate less when evaluating __is_convertible

On 9/26/22 12:25, Marek Polacek wrote: On Mon, Sep 26, 2022 at 11:51:30AM -0400, Patrick Palka wrote: On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote: Jon reported that evaluating __is_convertible in this test leads to instantiating char_traits::eq, which is invalid (because we are tr

Re: [PATCH] c++: P2513R4, char8_t Compatibility and Portability Fix [PR106656]

On 9/23/22 21:16, Marek Polacek wrote: P0482R6, which added char8_t, didn't allow const char arr[] = u8"howdy"; because it said "Declarations of arrays of char may currently be initialized with UTF-8 string literals. Under this proposal, such initializations would become ill-formed." This c

Re: [PATCH v2] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On 9/20/22 14:19, Marek Polacek wrote: On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote: On 9/3/22 12:42, Marek Polacek wrote: This patch implements https://wg21.link/p2266, which, once again, changes the implicit move rules. Here's a brief summary of various changes in this area:

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

On 9/19/22 12:39, Jakub Jelinek wrote: On Sat, Sep 17, 2022 at 10:58:54AM +0200, Jason Merrill wrote: I thought it is fairly important because __float128 has been around in GCC for 19 years already. To be precise, I think e.g. for x86_64 GCC 3.4 introduced it, but mangling was implemented only

Re: [EXTERNAL] Re: [PING][PATCH] Add instruction level discriminator support.

On 9/8/22 20:45, Eugene Rozenfeld wrote: Jason, Thank for your suggestion. The patch is updated (attached). @@ -467,12 +471,19 @@ lto_location_cache::apply_location_cache () current_loc = set_block (current_loc, loc.block); else current_loc = LOCATION_LOCUS (

Re: [PATCH] Avoid depending on destructor order

On 9/23/22 10:12, Thomas Neumann wrote:     +static const bool in_shutdown = false; I'll let Jason or others decide if this is the right solution.  It seems that in_shutdown also could be declared outside the #ifdef and initialized as "false". sure, either is fine. Moving it outside the #if

Re: [PATCH] c++: Improve diagnostics about conflicting specifiers

On 9/19/22 03:24, Jakub Jelinek wrote: Hi! On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote: I wonder why we don't give an error when setting the conflicting_specifiers_p flag in cp_parser_set_storage_class? We should be able to give a better diagnostic at that point. I didn't h

Re: [PATCH] c++, v2: Implement C++23 P1169R4 - static operator() [PR106651]

On 9/19/22 08:25, Jakub Jelinek wrote: Hi! On Sat, Sep 17, 2022 at 01:30:08PM +0200, Jason Merrill wrote: Below is an updated patch on top of the https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601788.html patch. Ah, OK. I don't think you need to check for C++23 or CALL_EXPR at all,

Re: [PATCH] c++: Make __is_{,nothrow_}convertible SFINAE on access [PR107049]

On 9/27/22 06:35, Jonathan Wakely wrote: Tested powerpc64le-linux. OK for trunk? OK, thanks. -- >8 -- The is_convertible built-ins should return false if the conversion fails an access check, not report an error. PR c++/107049 gcc/cp/ChangeLog: * method.cc (is_convertible_

Re: [PATCH v2] c++: Don't quote nothrow in diagnostic

On 9/27/22 04:41, Richard Biener wrote: On Mon, Sep 26, 2022 at 9:54 PM Marek Polacek wrote: On Mon, Sep 26, 2022 at 12:34:04PM -0400, Jason Merrill wrote: On 9/26/22 03:50, Richard Biener wrote: On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via Gcc-patches wrote: In

Re: [PATCH 1/2] c++: introduce TRAIT_TYPE alongside TRAIT_EXPR

On 9/27/22 15:50, Patrick Palka wrote: We already have generic support for predicate-like traits that yield a boolean via TRAIT_EXPR, but we lack the same support for transform-like traits that yield a type. Such support would be useful for implementing efficient built-ins for std::decay and std

Re: [PATCH 2/2] c++: implement __remove_cv, __remove_reference and __remove_cvref

On 9/27/22 15:50, Patrick Palka wrote: This uses TRAIT_TYPE from the previous patch to implement efficient built-ins for std::remove_cv, std::remove_reference and std::remove_cvref. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK once the previous patch goes

Re: [PATCH v3] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On 9/27/22 16:26, Marek Polacek wrote: On Mon, Sep 26, 2022 at 01:29:35PM -0400, Jason Merrill wrote: On 9/20/22 14:19, Marek Polacek wrote: There's one FIXME in elision1.C:five, which we should compile but reject with "passing 'Mutt' as 'this' argument discards qualifiers". That looks bogus t

Re: [PATCH 1/2] c++: introduce TRAIT_TYPE alongside TRAIT_EXPR

On 9/28/22 12:36, Patrick Palka wrote: On Tue, 27 Sep 2022, Jason Merrill wrote: On 9/27/22 15:50, Patrick Palka wrote: We already have generic support for predicate-like traits that yield a boolean via TRAIT_EXPR, but we lack the same support for transform-like traits that yield a type. Such

[pushed] c++: reduce temporaries in ?:

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- When the sides of ?: are class prvalues, we wrap the COND_EXPR in a TARGET_EXPR so that both sides will initialize the same temporary. But in this case we were stripping the outer TARGET_EXPR and conditionally creating different temporaries

[pushed] c++: fix class-valued ?: extension

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- When the gimplifier encounters the same TARGET_EXPR twice, it evaluates TARGET_EXPR_INITIAL the first time and clears it so that the later evaluation is just the temporary. With this testcase, using the extension to treat an omitted middle

[pushed] c++: check DECL_INITIAL for constexpr

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- We were overlooking non-potentially-constant bits in variable initializer because we didn't walk into DECL_INITIAL. gcc/cp/ChangeLog: * constexpr.cc (potential_constant_expression_1): Look into DECL_INITIAL. Use location w

[pushed] c++: fix triviality of class with unsatisfied op=

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- cxx20_pair is trivially copyable because it has a trivial copy constructor and only a deleted copy assignment operator; the non-triviality of the unsatisfied copy assignment overload is not considered. gcc/cp/ChangeLog: * class.cc

Re: [PATCH RFC] c++: streamline process for adding new builtin trait

On 9/29/22 11:05, Patrick Palka wrote: Adding a new builtin trait currently involves some boilerplate (as can be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and CPTK_ enumerators and adding them to various switch statements across many files. The exact switch statements we n

[pushed] c++: reduce redundant TARGET_EXPR

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- An experiment led me to notice that in some cases we were ending up with TARGET_EXPR initialized by TARGET_EXPR, which isn't useful. The target_expr_needs_replace change won't make a difference in most cases, since cp_genericize_init will h

Re: [PATCH] c-family: ICE with [[gnu::nocf_check]] [PR106937]

On 9/29/22 18:49, Marek Polacek wrote: When getting the name of an attribute, we ought to use get_attribute_name, which handles both [[ ]] and __attribute__(()) forms. Failure to do so may result in an ICE, like here. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? How do we prin

Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support

On 9/29/22 11:55, Jakub Jelinek wrote: Hi! Here is more complete patch to add std::bfloat16_t support on x86, AArch64 and (only partially) on ARM 32-bit. No BFmode optabs are added by the patch, so for binops/unops it extends to SFmode first and then truncates back to BFmode. For {HF,SF,DF,XF,T

Re: [PATCH] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]

On 9/29/22 06:01, Jakub Jelinek wrote: Hi! The following testcase ICEs on x86 as well as ppc64le (the latter with -mabi=ieeelongdouble), because _Float64x there isn't mangled as DF64x but e or u9__ieee128 instead. Those are the mangling that should be used for the non-standard types with the sam

Re: [PATCH] arm, aarch64, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

On 9/30/22 13:13, Jakub Jelinek wrote: On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote: Note, there is one further problem on aarch64/arm, types with HFmode (_Float16 and __fp16) are there mangled as Dh (which is standard Itanium mangling: ::= Dh # IEEE 754r half

Re: [PATCH] c++: make some cp_trait_kind switch statements exhaustive

On 9/30/22 13:37, Patrick Palka wrote: On Fri, 30 Sep 2022, Patrick Palka wrote: This replaces the unreachable default case in some cp_trait_kind switches with an exhaustive listing of the _unexpected_ trait codes, so that when adding a new trait we'll get a -Wswitch diagnostic if we forget to

Re: [PATCH RFC] c++: streamline process for adding new builtin trait

On 9/30/22 11:14, Patrick Palka wrote: On Thu, 29 Sep 2022, Jason Merrill wrote: On 9/29/22 11:05, Patrick Palka wrote: Adding a new builtin trait currently involves some boilerplate (as can be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and CPTK_ enumerators and adding th

Re: [PATCH] c++, c: Implement C++23 P1774R8 - Portable assumptions [PR106654]

On 9/22/22 05:55, Jakub Jelinek wrote: Hi! The following patch implements C++23 P1774R8 - Portable assumptions paper, by introducing support for [[assume (cond)]]; attribute for C++. In addition to that the patch adds [[gnu::assume (cond)]]; and __attribute__((assume (cond))); support to both C

[PATCH RFC] c++: fix broken conversion in coroutines

You can't use CONVERT_EXPR to convert between two class types, and it was breaking copy elision. Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where susp_type is Loopy::handle_type. How is this supposed to work? gcc/cp/ChangeLog: * coroutines.cc (expand_one_await_expre

[pushed] c++: cast split_nonconstant_init return val to void

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- We were already converting the result of expand_vec_init_expr to void; we need to do the same for split_nonconstant_init. The test that I noticed this with no longer fails without it. gcc/cp/ChangeLog: * cp-gimplify.cc (cp_generic

<    1   2   3   4   5   6   7   8   9   10   >