Re: [C++ Patch/RFC] PR 80145

OK. On Thu, Mar 23, 2017 at 3:07 PM, Paolo Carlini wrote: > Hi, > > this ICE on invalid code isn't a regression, thus a patch probably doesn't > qualify for Stage 4, but IMHO I made good progress on it and I'm sending > what I have now anyway... The ICE happens during

Re: [PATCH 1/2] C++ template type diff printing

On Mon, May 8, 2017 at 7:36 AM, Nathan Sidwell wrote: I agree with most of Nathan's comments, but > 'tree' sounds implementor-speaky, Perhaps > '-fdiagnostic-expand-template-args' or something? I like "tree" here; I read it as referring to the formatting of the abstract tree

Re: [C++ PATCH] namespace bindings

On Fri, May 5, 2017 at 4:07 PM, Nathan Sidwell wrote: > This cleanup patch kills IDENTIFIER_NAMESPACE_VALUE and replaces > {get,set}_namespace_binding with get_namespace_value and set_global_value > respectively. I'd prefer to stick with the _binding naming, as "value" is more

Re: [C++ Patch] PR 80186 ("ICE on C++ code with invalid constructor...")

OK. On Mon, May 8, 2017 at 7:25 AM, Paolo Carlini wrote: > Hi, > > in order to avoid this error recovery issue I think we want to check the > return value of grok_ctor_properties, as we do in decl.c, for its only other > use. Tested x86_64-linux. > > Thanks, Paolo. > >

Re: {PATCH] New C++ warning -Wcatch-value

On Sun, May 7, 2017 at 8:05 PM, Martin Sebor wrote: > On 05/07/2017 02:03 PM, Volker Reichelt wrote: >> >> On 2 May, Martin Sebor wrote: >>> >>> On 05/01/2017 02:38 AM, Volker Reichelt wrote: Hi, catching exceptions by value is a bad thing, as it may cause

Re: [PATCH] c++: Fix wrong conversion error with non-viable overload [PR94124]

On 3/10/20 7:38 PM, Marek Polacek wrote: This is a bad interaction between sharing a constructor for an array and stripping its trailing zero-initializers. Here we reuse a ctor and then strip its 0s. This breaks overload resolution in this test: D can be initialized from {} but not from {0},

[pushed] c++: Fix ICE with omitted template args [PR93956].

reshape_init only wants to work on BRACE_ENCLOSED_INITIALIZER_P, i.e. raw initializer lists, and here was getting a CONSTRUCTOR that had already been processed for type A. maybe_aggr_guide should also use that test. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog 2020-03-10

[pushed] c++: Fix deferred noexcept on constructor [PR93901].

My change in r10-4394 to only update clones when we actually instantiate a deferred noexcept-spec broke this because deferred parsing updates the primary function but not the clones. For GCC 10, let's just revert it. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog 2020-03-10

Re: [PATCH] c++: Fix wrong conversion error with non-viable overload [PR94124]

On 3/11/20 6:28 PM, Jakub Jelinek wrote: On Wed, Mar 11, 2020 at 04:02:51PM -0400, Jason Merrill via Gcc-patches wrote: We should certainly avoid copying if they're the same. The code above for only copying the bits that aren't going to be thrown away seems pretty straightforward, might

Re: ODR violation in ranges

On Wed, Mar 11, 2020 at 11:05 AM Nathan Sidwell wrote: > On 3/11/20 6:56 AM, Tam S. B. wrote: > > IIUC using lambda in inline variable initializer is not ODR violation. > This is covered in CWG 2300 ( > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1510r0.html#2300 > ). > > ah, thanks

Re: [PATCH] c++: Redundant -Wdeprecated-declarations warning in build_over_call (PR 67960)

On 3/12/20 3:28 PM, Patrick Palka wrote: In build_over_call, we are emitting a redundant -Wdeprecated-declarations warning about the deprecated callee function, first from mark_used and again from build_addr_func <- decay_conversion <- cp_build_addr_expr <- mark_used. It seems this warning

[pushed] c++: Fix ICE-after-error on partial spec [92068]

Here the template arguments for the partial specialization are valid arguments for the template, but not for a partial specialization, because 'd' can never be deduced to anything other than an empty pack. Tested x86_64-pc-linux-gnu, applying to 8/9/10. gcc/cp/ChangeLog 2020-03-14 Jason Merrill

[pushed] c++: Fix CTAD with multiple-arg ctor template [93248].

When cp_unevaluated_operand is set, tsubst_decl thinks that if it sees a PARM_DECL that isn't already in local_specializations, we're in a decltype in a trailing return type or some such, and so we only want a substitution for a single PARM_DECL. In this case, we want the whole chain, so make

[pushed] c++: Find parameter pack in typedef in lambda [92909].

find_parameter_packs_r doesn't look through typedefs, which is normally correct, but that means we need to handle their declarations specially. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog 2020-03-14 Jason Merrill PR c++/92909 * pt.c

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/11/20 12:57 PM, Martin Sebor wrote: On 3/9/20 6:08 PM, Jason Merrill wrote: On 3/9/20 5:39 PM, Martin Sebor wrote: On 3/9/20 1:40 PM, Jason Merrill wrote: On 3/9/20 12:31 PM, Martin Sebor wrote: On 2/28/20 1:24 PM, Jason Merrill wrote: On 2/28/20 12:45 PM, Martin Sebor wrote: On

Re: [PATCH] c++: Fix wrong conversion error with non-viable overload [PR94124]

On 3/11/20 11:44 AM, Marek Polacek wrote: On Wed, Mar 11, 2020 at 07:52:15AM +0100, Jakub Jelinek via Gcc-patches wrote: On Tue, Mar 10, 2020 at 07:38:17PM -0400, Marek Polacek via Gcc-patches wrote: --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -6062,6 +6062,13 @@ reshape_init_array_1 (tree

Re: [PATCH v2] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

On 3/11/20 1:59 PM, Marek Polacek wrote: On Tue, Mar 10, 2020 at 03:46:03PM -0400, Jason Merrill wrote: On 3/9/20 4:34 PM, Marek Polacek wrote: On Mon, Mar 09, 2020 at 04:25:00PM -0400, Marek Polacek wrote: On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote: On 3/9/20 9:40 AM,

Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures

On 3/9/20 6:23 PM, Patrick Palka wrote: This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend which controls how deeply we replay errors when diagnosing a constraint satisfaction failure. The default is -fconcepts-diagnostics-depth=1 which diagnoses only the topmost

[pushed] c++: Fix ICE with concepts and aliases [PR93907].

The problem here was that we were checking satisfaction once with 'e', a typedef of 'void', and another time with 'void' directly, and treated them as different for hashing based on the assumption that canonicalize_type_argument would have already removed a typedef that wasn't a complex dependent

Re: [PATCH v2] c++: Fix ICE-on-invalid with lambda template [PR94507]

On 4/8/20 9:44 AM, Marek Polacek wrote: On Wed, Apr 08, 2020 at 08:55:08AM -0400, Jason Merrill via Gcc-patches wrote: On 4/6/20 9:05 PM, Marek Polacek wrote: While reducing something else I noticed that we ICE on the following invalid code. In tsubst_lambda_expr, tsubst_template_decl has

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On 4/9/20 1:05 AM, Martin Liška wrote: Hi. We've got one another sneaky test-case (thank you Marc ;) ): $ cat pr94314-array.C #include #include int count = 0; __attribute__((malloc, noinline)) void* operator new[](unsigned long sz) {   ++count;   return ::operator new(sz); } void

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/8/20 7:49 PM, Patrick Palka wrote: When evaluating the initializer of 'a' in the following example struct A { A *p = this; }; constexpr A foo() { return {}; } constexpr A a = foo(); the PLACEHOLDER_EXPR for 'this' in the aggregate initializer returned by foo gets resolved to the

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/8/20 1:23 PM, Martin Sebor wrote: On 4/7/20 3:36 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote: On 4/7/20 1:50 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote: Among the numerous regressions

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/9/20 3:24 PM, Martin Sebor wrote: On 4/9/20 1:03 PM, Jason Merrill wrote: On 4/8/20 1:23 PM, Martin Sebor wrote: On 4/7/20 3:36 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote: On 4/7/20 1:50 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/7/20 2:50 PM, Martin Sebor wrote: Among the numerous regressions introduced by the change committed to GCC 9 to allow string literals as template arguments is a failure to recognize the C++ nullptr and GCC's __null constants as pointers. For one, I didn't realize that nullptr, being a null

[pushed] c++: constexpr static data member instantiation [PR94523]

Here due to my recent change to store_init_value we were expanding the initializer of aw knowing that we were initializing aw. When cxx_eval_call_expression finished the constructor, it wanted to look up the value of aw to set TREE_READONLY on it, but we haven't set DECL_INITIAL yet, so

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/9/20 4:23 PM, Martin Sebor wrote: On 4/9/20 1:32 PM, Jason Merrill wrote: On 4/9/20 3:24 PM, Martin Sebor wrote: On 4/9/20 1:03 PM, Jason Merrill wrote: On 4/8/20 1:23 PM, Martin Sebor wrote: On 4/7/20 3:36 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor

Re: [PATCH] c++: Fix wrong paren-init of aggregates interference [PR93790]

On 4/8/20 5:52 PM, Marek Polacek wrote: This PR points out that we are rejecting valid code in C++20. The problem is that we were surreptitiously transforming T& t(e) into T& t{e} which is wrong, because the type of e had a conversion function to T, while aggregate initialization of t

Re: [PATCH] c++: "'decltype_type' not supported" in diagnostic [PR85278]

On 4/14/20 11:46 AM, Patrick Palka wrote: This fixes a garbled concepts diagnostic by moving the handling of DECLTYPE_TYPE from pp_cxx_type_specifier_seq to cxx_pretty_printer::simple_type_specifier, a move which also seems to be more consistent with the language grammar. This patch also fixes

Re: [PATCH] c++: Fix pasto in structured binding diagnostics [PR94571]

On 4/15/20 4:12 AM, Jakub Jelinek wrote: Hi! This snippet has been copied from the non-structured binding declaration parsing later in the function, and while for non-structured bindings it can be followed by comma or semicolon, structured bindings may be only followed by semicolon. Fixed

Re: [PATCH] c++: Error recovery with errenous DECL_INITIAL [PR94475]

On 4/15/20 4:43 PM, Patrick Palka wrote: Oops, consider the typo in the subject line fixed. Also ... On Wed, 15 Apr 2020, Patrick Palka wrote: Here we're ICE'ing in do_narrow during error-recovery, because ocp_convert returns error_mark_node after it attempts to reduce a const decl to its

Re: [PATCH] c++: Non-type-dependent variadic lambda init-capture [PR94483]

On 4/16/20 1:53 PM, Patrick Palka wrote: In this PR (which I think is misclassified as ice-on-invalid instead of ice-on-valid), we're ICEing on a use of an 'int... a' template parameter pack as part of the variadic lambda init-capture [...z=a]. The unexpected thing about this variadic

Re: [PATCH] c++: Hard error with tentative parse of declaration [PR88754]

On 4/16/20 7:33 PM, Patrick Palka wrote: In the testcase for this PR, we try to parse the statement A(value<0>()); first tentatively as a declaration (with a parenthesized declarator), and during this tentative parse we end up issuing a hard error from cp_parser_check_template_parameters

Re: [PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515]

On 4/17/20 6:08 AM, Kyrylo Tkachov wrote: Hi Szabolcs, -Original Message- From: Szabolcs Nagy Sent: 09 April 2020 15:20 To: gcc-patches@gcc.gnu.org Cc: Richard Earnshaw ; Richard Sandiford ; Kyrylo Tkachov Subject: [PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515] On

Re: [PATCH] c++: spec_hasher::equal and PARM_DECLs [PR94632]

On 4/17/20 1:35 PM, Patrick Palka wrote: In the testcase below, during specialization of c::d, we build two identical specializations of the parameter type b -- one when substituting into c::d's TYPE_ARG_TYPES and another when substituting into c::d's DECL_ARGUMENTS. We don't reuse the first

Re: [PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515]

On 4/17/20 1:55 PM, Szabolcs Nagy wrote: The 04/17/2020 12:50, Jason Merrill wrote: On 4/17/20 6:08 AM, Kyrylo Tkachov wrote: Hi Szabolcs, -Original Message- From: Szabolcs Nagy Sent: 09 April 2020 15:20 To: gcc-patches@gcc.gnu.org Cc: Richard Earnshaw ; Richard Sandiford ; Kyrylo

Re: [PATCH] c++: Abbreviated function template return type [PR92187]

On 4/17/20 9:40 AM, Patrick Palka wrote: When updating an auto return type of an abbreviated function template in splice_late_return_type, we should also propagate PLACEHOLDER_TYPE_CONSTRAINTS (and cv-qualifiers) of the original auto node. Bootstrapped and regtested on x86_64-pc-linux-gnu, does

[pushed] c++: ICE on invalid concept placeholder [PR94481].

Here the 'decltype' is missing '(auto)', so open_paren was NULL, and trying to get its location is a SEGV. Using matching_parens avoids that problem. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog 2020-04-07 Jason Merrill PR c++/94481 * parser.c

Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]

On 4/7/20 1:40 PM, Patrick Palka wrote: On Mon, 6 Apr 2020, Jason Merrill wrote: On 4/6/20 11:45 AM, Patrick Palka wrote: On Wed, 1 Apr 2020, Jason Merrill wrote: On 4/1/20 6:29 PM, Jason Merrill wrote: On 3/31/20 3:50 PM, Patrick Palka wrote: On Tue, 31 Mar 2020, Jason Merrill wrote: On

Re: [PATCH v3] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

Ok. On Mon, Apr 6, 2020, 11:57 AM Marek Polacek wrote: > On Mon, Apr 06, 2020 at 10:47:49AM -0400, Jason Merrill via Gcc-patches > wrote: > > On 4/4/20 1:56 PM, Marek Polacek wrote: > > > On Fri, Apr 03, 2020 at 10:39:49PM -0400, Jason Merrill via > Gcc-patches wrote: &

Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

On 4/4/20 1:56 PM, Marek Polacek wrote: On Fri, Apr 03, 2020 at 10:39:49PM -0400, Jason Merrill via Gcc-patches wrote: On 4/3/20 9:08 PM, Marek Polacek wrote: On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches wrote: On 3/30/20 4:28 PM, Marek Polacek wrote: Here we crash

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

On Mon, Apr 6, 2020 at 5:27 AM Richard Biener via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Sat, Apr 4, 2020 at 1:53 PM Jan Hubicka wrote: > > > > Hi, > > thinking a bit of the problem, I guess we could match in addition to > > DECL_CONTEXT the whole inline stack of both statements and

[pushed] c++: requires-expression and tentative parse [PR94480]

The problem here was that cp_parser_requires_expression committing to a tentative parse confused cp_parser_decltype_expr, which needs to still be tentative. The only reason to commit here is to get syntax errors within the requires-expression, which we can still do when the commit is firewalled

Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]

On 4/6/20 11:45 AM, Patrick Palka wrote: On Wed, 1 Apr 2020, Jason Merrill wrote: On 4/1/20 6:29 PM, Jason Merrill wrote: On 3/31/20 3:50 PM, Patrick Palka wrote: On Tue, 31 Mar 2020, Jason Merrill wrote: On 3/30/20 6:46 PM, Patrick Palka wrote: On Mon, 30 Mar 2020, Jason Merrill wrote:

Re: [PATCH] c++: Fix usage of CONSTRUCTOR_PLACEHOLDER_BOUNDARY inside array initializers [90996]

On 4/6/20 3:07 PM, Patrick Palka wrote: This PR reports that since the introduction of the CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to resolve PLACEHOLDER_EXPRs inside array initializers that refer to some inner constructor. In the testcase in the PR, we have as the

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/12/20 9:43 AM, Patrick Palka wrote: On Sat, 11 Apr 2020, Jason Merrill wrote: On 4/10/20 5:47 PM, Patrick Palka wrote: On Fri, 10 Apr 2020, Jason Merrill wrote: On 4/10/20 2:15 PM, Patrick Palka wrote: On Fri, 10 Apr 2020, Patrick Palka wrote: On Fri, 10 Apr 2020, Jason Merrill

Re: [PATCH] c++: Infinite diagnostic loop with decltype([]{}) [PR94521]

On 4/12/20 9:48 AM, Patrick Palka wrote: We are hitting a recursive loop when printing the signature of a function containing a decltype([]{}) type. The loop is dump_function_decl -> dump_substitution -> dump_template_bindings -> dump_type

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/13/20 2:49 PM, Patrick Palka wrote: On Mon, 13 Apr 2020, Jason Merrill wrote: On 4/12/20 9:43 AM, Patrick Palka wrote: On Sat, 11 Apr 2020, Jason Merrill wrote: On 4/10/20 5:47 PM, Patrick Palka wrote: On Fri, 10 Apr 2020, Jason Merrill wrote: On 4/10/20 2:15 PM, Patrick Palka wrote:

Re: [PATCH] c++: Improve redeclared parameter name diagnostic [PR94588]

On 4/13/20 7:43 PM, Marek Polacek wrote: While reviewing [basic.scope.param] I noticed we don't show the location of the previous declaration when giving an error about "A parameter name shall not be redeclared in the outermost block of the function definition". Bootstrapped/regtested on

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/12/20 5:49 PM, Martin Sebor wrote: On 4/10/20 8:52 AM, Jason Merrill wrote: On 4/9/20 4:23 PM, Martin Sebor wrote: On 4/9/20 1:32 PM, Jason Merrill wrote: On 4/9/20 3:24 PM, Martin Sebor wrote: On 4/9/20 1:03 PM, Jason Merrill wrote: On 4/8/20 1:23 PM, Martin Sebor wrote: On 4/7/20

Re: [PATCH] c++: More self-modifying constexpr init [PR94470]

On 4/13/20 9:18 AM, Patrick Palka wrote: In this PR we're incorrectly rejecting a self-modifying constexpr initializer as a consequence of the fix for PR78572. It looks like however that the fix for PR78572 is obsoleted by the fix for PR89336: the testcase from the former PR successfully

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/14/20 12:29 AM, Patrick Palka wrote: On Mon, 13 Apr 2020, Jason Merrill wrote: On 4/13/20 2:49 PM, Patrick Palka wrote: On Mon, 13 Apr 2020, Jason Merrill wrote: On 4/12/20 9:43 AM, Patrick Palka wrote: On Sat, 11 Apr 2020, Jason Merrill wrote: On 4/10/20 5:47 PM, Patrick Palka

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/14/20 9:01 AM, Patrick Palka wrote: On Tue, 14 Apr 2020, Patrick Palka wrote: On Mon, 13 Apr 2020, Jason Merrill wrote: On 4/13/20 2:49 PM, Patrick Palka wrote: On Mon, 13 Apr 2020, Jason Merrill wrote: On 4/12/20 9:43 AM, Patrick Palka wrote: On Sat, 11 Apr 2020, Jason Merrill

Re: [PATCH] c++: Fix bogus -Wparentheses warning with fold-expression [PR94505]

On 4/19/20 12:59 PM, Marek Polacek wrote: We issue bogus -Wparentheses warnings (3 of them!) for this fold expression: ((B && true) || ...) Firstly, issuing a warning for a compiler-generated expression is wrong and secondly, B && true must be wrapped in ( ) otherwise you'll get error:

Re: [PATCH] c++: Fix crash with template spec in different namespace [PR94255]

On 4/18/20 10:49 AM, Marek Polacek wrote: This is an ICE on invalid, because we're specializing S::foo in the wrong namespace. cp_parser_class_specifier_1 parses S::foo in M and then it tries to push the nested-name-specifier of foo, which is S. By that, we're breaking the assumption of

Re: [PATCH] c++: Detect long double -> double narrowing [PR94590]

On 4/20/20 12:25 PM, Marek Polacek wrote: This PR points out that we don't detect long double -> double narrowing when long double happens to have the same precision as double; on x86_64 this can be achieved by -mlong-double-64. [dcl.init.list]#7.2 specifically says "from long double to double

Re: [PATCH] c++: Recursive unification with packs and explicit targs [PR94628]

On 4/19/20 12:55 PM, Patrick Palka wrote: This PR seems to be similar to PR c++/43382, except that the recursive call to the variadic function with trailing return type in this testcase is additionally given some explicit template arguments. In the first testcase below, when resolving the

Re: [PATCH v2] c++: Fix ICE with { } as template argument [PR94592]

On 4/20/20 4:44 PM, Marek Polacek wrote: On Mon, Apr 20, 2020 at 11:51:59AM -0400, Jason Merrill wrote: On 4/17/20 4:28 PM, Marek Polacek wrote: As an extension (there should be a CWG about this though), we support braced-init-list as a template argument, but convert_nontype_argument had

Re: [PATCH] testsuite: Extend C++ struct-layout-1.exp testing to test C++14 vs. C++17 interoperability of structs with empty bases [PR94383]

On 4/21/20 5:57 AM, Jakub Jelinek wrote: Hi! Jonathan reported an ABI incompatibility between C++14 and C++17 in passing some aggregates with empty bases on aarch64 (and apparently on arm too). The following patch adds 3000 (by default) tests for such interoperability, using the

Re: [PATCH] c++: Dependent conversion operator in concept [PR94597]

On 4/21/20 9:55 AM, Patrick Palka wrote: When building the parameter mapping for an atomic constraint, find_template_parameters does not spot the template parameter within the conversion-type-id of a dependent conversion operator, which later leads to an ICE during substitution when looking up

Re: [PATCH] c++: Fix ICE with { } as template argument [PR94592]

On 4/17/20 4:28 PM, Marek Polacek wrote: As an extension (there should be a CWG about this though), we support braced-init-list as a template argument, but convert_nontype_argument had trouble digesting them. We ICEd because of the double coercion we perform for template arguments:

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/10/20 2:15 PM, Patrick Palka wrote: On Fri, 10 Apr 2020, Patrick Palka wrote: On Fri, 10 Apr 2020, Jason Merrill wrote: On 4/10/20 1:04 PM, Patrick Palka wrote: On Thu, 9 Apr 2020, Patrick Palka wrote: On Thu, 9 Apr 2020, Jason Merrill wrote: On 4/8/20 7:49 PM, Patrick Palka wrote:

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/10/20 1:04 PM, Patrick Palka wrote: On Thu, 9 Apr 2020, Patrick Palka wrote: On Thu, 9 Apr 2020, Jason Merrill wrote: On 4/8/20 7:49 PM, Patrick Palka wrote: When evaluating the initializer of 'a' in the following example struct A { A *p = this; }; constexpr A foo() { return

Re: [PATCH] c++: make __is_constructible work with paren-init of aggrs [PR94149]

On 4/9/20 5:00 PM, Marek Polacek wrote: In C++20 this is well-formed: using T = int[2]; T t(1, 2); which means that std::is_constructible_v should be true. But constructible_expr immediately returned the error_mark_node when it saw a list with more than one element. To give accurate

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/10/20 5:47 PM, Patrick Palka wrote: On Fri, 10 Apr 2020, Jason Merrill wrote: On 4/10/20 2:15 PM, Patrick Palka wrote: On Fri, 10 Apr 2020, Patrick Palka wrote: On Fri, 10 Apr 2020, Jason Merrill wrote: On 4/10/20 1:04 PM, Patrick Palka wrote: On Thu, 9 Apr 2020, Patrick Palka wrote:

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/15/20 1:30 PM, Martin Sebor wrote: On 4/13/20 8:43 PM, Jason Merrill wrote: On 4/12/20 5:49 PM, Martin Sebor wrote: On 4/10/20 8:52 AM, Jason Merrill wrote: On 4/9/20 4:23 PM, Martin Sebor wrote: On 4/9/20 1:32 PM, Jason Merrill wrote: On 4/9/20 3:24 PM, Martin Sebor wrote: On 4/9/20

[pushed] c++: Fix ICE with implicit operator== [PR94462]

duplicate_decls assumed that any TREE_ARTIFICIAL function at namespace scope was a built-in function, but now in C++20 it's possible to have an implicitly declared hidden friend operator==. We just need to move the assert into the if condition. Tested x86_64-pc-linux-gnu, applying to trunk.

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On 4/8/20 4:47 AM, Richard Biener wrote: On Tue, Apr 7, 2020 at 5:01 PM Martin Liška wrote: Hi. The patch allows DCE to remove only replaceable operators new and delete. That's achieved by proper mark up of all these operators in C++ FE. The patch also brings all tests we've collected so far

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On 4/8/20 9:32 AM, Jakub Jelinek wrote: On Wed, Apr 08, 2020 at 09:20:07AM -0400, Jason Merrill via Gcc-patches wrote: On 4/8/20 4:47 AM, Richard Biener wrote: On Tue, Apr 7, 2020 at 5:01 PM Martin Liška wrote: Hi. The patch allows DCE to remove only replaceable operators new and delete

Re: [PATCH] c++: ICE with defaulted comparison operator [PR94478]

On 4/7/20 3:14 PM, Marek Polacek wrote: Here we ICE because early_check_defaulted_comparison passed a null ctx to same_type_p. The attached test is ill-formed according to [class.compare.default]/1, so fixed by detecting this case early. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for

Re: [PATCH] c++: Fix ICE-on-invalid with lambda template [PR94507]

On 4/6/20 9:05 PM, Marek Polacek wrote: While reducing something else I noticed that we ICE on the following invalid code. In tsubst_lambda_expr, tsubst_template_decl has already reported an error and returned the error_mark_node, so make sure we don't ICE on that. I'm using a goto here

Re: [PATCH] c++: Further fix for -fsanitize=vptr [PR94325]

On 4/6/20 6:43 PM, Jakub Jelinek wrote: Hi! For -fsanitize=vptr, we insert a NULL store into the vptr instead of just adding a CLOBBER of this. build_clobber_this makes the CLOBBER conditional on in_charge (implicit) parameter whenever CLASSTYPE_VBASECLASSES, but when adding this

Re: [PATCH] c++: Fix usage of CONSTRUCTOR_PLACEHOLDER_BOUNDARY inside array initializers [90996]

On 4/6/20 6:22 PM, Patrick Palka wrote: On Mon, 6 Apr 2020, Jason Merrill wrote: On 4/6/20 3:07 PM, Patrick Palka wrote: This PR reports that since the introduction of the CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to resolve PLACEHOLDER_EXPRs inside array initializers

Re: [PATCH] c++: Fix parsing of invalid enum specifiers [PR90995]

On 3/14/20 4:06 AM, Jakub Jelinek wrote: Hi! The testcase shows some accepts-invalid (the ones without alignas) and ice-on-invalid-code (the ones with alignas) cases. If the enum doesn't have an underlying type and is not a definition, the caller retries to parse it as elaborated type

Re: [PATCH] c++: Refrain from using replace_placeholders in constexpr evaluation [PR94205]

On 4/3/20 4:07 PM, Patrick Palka wrote: On Fri, 3 Apr 2020, Jason Merrill wrote: On 4/2/20 7:40 PM, Patrick Palka wrote: + /* Prefer the outermost matching object, but don't cross + CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors. */ + if (ctx->ctor && !CONSTRUCTOR_PLACEHOLDER_BOUNDARY

Re: [PATCH] debug: Improve debug info of c++14 deduced return type [PR94459]

On 4/3/20 6:47 PM, Jakub Jelinek wrote: Hi! On the following testcase, in gdb ptype S::m1 prints long as return type, but all the other methods show void instead. PR53756 added code to add_type_attribute if the return type is auto/decltype(auto), but we actually should look through references,

Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

On 4/3/20 9:08 PM, Marek Polacek wrote: On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches wrote: On 3/30/20 4:28 PM, Marek Polacek wrote: Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't expect null indexes for a constructor: /* ??? Here's

Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94219]

On 4/3/20 4:57 PM, Patrick Palka wrote: On Fri, 3 Apr 2020, Patrick Palka wrote: On Fri, 3 Apr 2020, Jason Merrill wrote: On 4/2/20 2:19 PM, Patrick Palka wrote: On Thu, 2 Apr 2020, Patrick Palka wrote: This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression do not

Re: [PATCH v2] c++: Fix further protected_set_expr_location related -fcompare-debug issues [PR94441]

On 4/3/20 4:12 PM, Jakub Jelinek wrote: On Fri, Apr 03, 2020 at 03:02:58PM -0400, Jason Merrill via Gcc-patches wrote: Or do we want a further wrapper, perhaps C++ FE only, that would do this protected_set_expr_location_if_unset (stmt, locus)? That sounds good to me. So like

[pushed] c++: Fix reuse of class constants [PR94453]

The testcase hit an ICE trying to expand a TARGET_EXPR temporary cached from the other lambda-expression. This patch fixes this in two ways: 1) Avoid reusing a TARGET_EXPR from another function. 2) Avoid ending up with a TARGET_EXPR at all; the use of 'p' had become >>, which doesn't make any

[pushed] c++: Mangling of dependent conversions [PR91377]

We skip over other conversion codes when mangling expressions, we should do the same with IMPLICIT_CONV_EXPR. Tested x86_64-pc-linux-gnu, applying to trunk/9/8. gcc/cp/ChangeLog 2020-04-04 Jason Merrill PR c++/91377 * mangle.c (write_expression): Skip IMPLICIT_CONV_EXPR. ---

[pushed] c++: Fix invalid pointer-to-member in requires [PR67825]

A recent change to cmcstl2 led to two tests failing due to this bug: our valid expression checking in the context of a requires-expression wasn't catching that an expression of member function type can only appear as the function operand of a call expression. Fixed by using convert_to_void to do

Re: [PATCH v2] debug: Improve debug info of c++14 deduced return type [PR94459]

On 4/4/20 3:54 AM, Jakub Jelinek wrote: On Sat, Apr 04, 2020 at 12:08:38AM -0400, Jason Merrill wrote: http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a decl-specifier. http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a template argument can be deduced. Looks

Re: [PATCH] c++: C++20 DR 2237, disallow simple-template-id in cdtor.

On 4/4/20 7:30 PM, Marek Polacek wrote: This patch implements DR 2237 which says that a simple-template-id is no longer valid as the declarator-id of a constructor or destructor; see . It is not explicitly stated but out-of-line destructors with a

Re: [PATCH] c++: Fix a -fcompare-debug issue with DEBUG_BEGIN_STMT stmts in STATEMENT_LISTs [PR94272]

On 3/24/20 3:58 AM, Jakub Jelinek wrote: + for (i = tsi_start (stmt); !tsi_end_p (i); tsi_next ()) + { + tree t = tsi_stmt (i); + if (TREE_CODE (t) != DEBUG_BEGIN_STMT && nondebug_stmts < 2) + nondebug_stmts++; + cp_walk_tree

Re: [PATCH] c++: Remove redundant calls to type_dependent_expression_p

On 3/25/20 8:52 AM, Patrick Palka wrote: This simplifies conditions that test both value_dependent_expression_p and type_dependent_expression_p, since the former predicate now subsumes the latter. Tested on x86_64-pc-linux-gnu, does this look OK? I'm still a bit uneasy about testing

Re: [PATCH] c++: requires-expression outside of a template is misevaluated [PR94252]

On 3/25/20 12:17 PM, Patrick Palka wrote: This PR reports that the requires-expression in auto f = [] { }; static_assert(requires { f(); }); erroneously evaluates to false. The way we end up evaluating to false goes as follows. During the parsing of the requires-expression, we call

Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]

On 3/22/20 9:21 PM, Patrick Palka wrote: This patch relaxes an assertion in tsubst_default_argument that exposes a latent bug in how we substitute an array type into a cv-qualified wildcard function parameter type. Concretely, the latent bug is that given the function template template void

Re: [PATCH] c++: requires-expression outside of a template is misevaluated [PR94252]

On 3/26/20 5:24 PM, Patrick Palka wrote: On Wed, 25 Mar 2020, Jason Merrill wrote: On 3/25/20 12:17 PM, Patrick Palka wrote: This PR reports that the requires-expression in auto f = [] { }; static_assert(requires { f(); }); erroneously evaluates to false. The way we end up

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/26/20 2:58 PM, Martin Sebor wrote: On 3/25/20 11:36 PM, Jason Merrill wrote: On 3/23/20 12:50 PM, Martin Sebor wrote: On 3/23/20 8:49 AM, Jason Merrill wrote: On 3/21/20 5:59 PM, Martin Sebor wrote: +  /* Diagnose class/struct/union mismatches.  IS_DECLARATION is false + for

Re: [PATCH] c++: Diagnose when "requires" is used instead of "requires requires" [PR94306]

On 3/26/20 5:28 PM, Patrick Palka wrote: This adds support to detect and recover from the case where an opening brace immediately follows the start of a requires-clause. So rather than emitting the error error: expected primary-expression before '{' token followed by a slew of irrevelant

Re: [PATCH v6] c++: DR1710, template keyword in a typename-specifier [PR94057]

On 3/26/20 3:44 PM, Marek Polacek wrote: On Thu, Mar 26, 2020 at 01:43:28AM -0400, Jason Merrill wrote: I think you want to check all typedefs like in e.g. find_parameter_packs_r; if the name is a typedef, it's only suitable if alias_template_specialization_p. ..this: Since

Re: [PATCH] avoid modifying type in attribute access handler [PR94098]

On 3/16/20 4:41 PM, Martin Sebor wrote: The recent fix to avoid modifying in place the type argument in handle_access_attribute (PR 92721) was incomplete and didn't fully resolve the problem (an ICE in the C++ front-end).  The attached patch removes the remaining modification that causes the

Re: [PATCH] c++: Fix up user_provided_p [PR81349]

On 3/25/20 3:29 PM, Jakub Jelinek wrote: Hi! The standard says: "A function is user-provided if it is user-declared and not explicitly defaulted or deleted on its first declaration." I don't see anything about function templates having different rules here, but user_provided_p does return true

Re: [PATCH v5] c++: DR1710, template keyword in a typename-specifier [PR94057]

On 3/25/20 5:36 PM, Marek Polacek wrote: On Wed, Mar 25, 2020 at 12:00:24AM -0400, Jason Merrill wrote: On 3/24/20 11:45 AM, Marek Polacek wrote: On Mon, Mar 23, 2020 at 10:41:28AM -0400, Jason Merrill wrote: On 3/20/20 7:02 PM, Marek Polacek wrote: On Fri, Mar 20, 2020 at 02:12:49PM -0400,

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/23/20 12:50 PM, Martin Sebor wrote: On 3/23/20 8:49 AM, Jason Merrill wrote: On 3/21/20 5:59 PM, Martin Sebor wrote: +  /* Diagnose class/struct/union mismatches.  IS_DECLARATION is false + for alias definition.  */ +  bool decl_class = (is_declaration + &&

Re: [PATCH] c++: Diagnose when "requires" is used instead of "requires requires" [PR94306]

On 3/26/20 6:36 PM, Patrick Palka wrote: On Thu, 26 Mar 2020, Jason Merrill wrote: On 3/26/20 5:28 PM, Patrick Palka wrote: This adds support to detect and recover from the case where an opening brace immediately follows the start of a requires-clause. So rather than emitting the error

Re: [PATCH] c++: template keyword accepted before destructor names [PR94336]

On 3/26/20 6:31 PM, Marek Polacek wrote: This came up on the C++ core list recently. We don't diagnose the case when 'template' is followed by a destructor name which is not permitted by [temp.names]/5. OK. PR c++/94336 - template keyword accepted before destructor names. *

Re: [PATCH] avoid modifying type in attribute access handler [PR94098]

On 3/26/20 4:57 PM, Martin Sebor wrote: On 3/25/20 3:56 PM, Jason Merrill wrote: On 3/16/20 4:41 PM, Martin Sebor wrote: The recent fix to avoid modifying in place the type argument in handle_access_attribute (PR 92721) was incomplete and didn't fully resolve the problem (an ICE in the C++

Re: [PATCH] c++: Diagnose when "requires" is used instead of "requires requires" [PR94306]

On 3/26/20 11:49 PM, Patrick Palka wrote: On Thu, 26 Mar 2020, Jason Merrill wrote: On 3/26/20 6:36 PM, Patrick Palka wrote: On Thu, 26 Mar 2020, Jason Merrill wrote: On 3/26/20 5:28 PM, Patrick Palka wrote: This adds support to detect and recover from the case where an opening brace

  1   2   3   4   5   6   7   8   9   10   >