Re: [PATCH v2] c++: Improve sorry for __builtin_has_attribute [PR98355]

On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches wrote: > On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via Gcc-patches wrote: > > __builtin_has_attribute doesn't work in templates yet (bug 92104), so > > in r11-471 I added a sorry. But that o

Re: [PATCH] c++: Improve sorry for __builtin_has_attribute [PR98355]

On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via Gcc-patches wrote: > __builtin_has_attribute doesn't work in templates yet (bug 92104), so > in r11-471 I added a sorry. But that only caught type-dependent > expressions and we also want to sorry on value-dependent ex

[PATCH] c++: Improve sorry for __builtin_has_attribute [PR98355]

__builtin_has_attribute doesn't work in templates yet (bug 92104), so in r11-471 I added a sorry. But that only caught type-dependent expressions and we also want to sorry on value-dependent expressions. This patch uses v_d_e_p rather than uses_template_parms because u_t_p sets p_t_d and then

[PATCH] c++: Fix infinite looping with invalid operator [PR96137]

My r11-86 adjusted cp_parser_class_name to do - scope = parser->scope; + scope = parser->scope ? parser->scope : parser->context->object_type; if (scope == error_mark_node) return error_mark_node; but that caused endless looping in cp_parser_type_specifier_seq (the while (true) loop)

Re: [PATCH] tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]

On Thu, Jan 28, 2021 at 11:38:34PM +0100, Eric Botcazou wrote: > > Aware. I don't have access to, e.g., a sparc box. But the test I've added > > uses -mstrict-align where possible to check that the issue is resolved. > > There are relatively fast SPARC64/Linux (gcc202) and SPARC/Solaris

Re: [PATCH] tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]

On Thu, Jan 28, 2021 at 11:02:36PM +0100, Eric Botcazou wrote: > > Bootstrapped/regtested on > > * x86_64-pc-linux-gnu > > * powerpc64le-unknown-linux-gnu > > * aarch64-linux-gnu > > ok for trunk? > > None of them is strict alignment though, isn't it? Aware. I don't have access to, e.g., a

Re: [PATCH] tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]

On Thu, Jan 28, 2021 at 03:18:55PM -0500, Jason Merrill via Gcc-patches wrote: > On 1/28/21 10:34 AM, Marek Polacek wrote: > > A year ago I submitted this patch: > > > > ~~ > > Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it > > gets "const d[0]" with TYPE_USER_ALIGN=0 but

[PATCH] tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]

A year ago I submitted this patch: ~~ Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1. When we strip_typedefs the element of the array "const d",

Re: [PATCH] c++: ICE with noexcept in class in member function [PR96623]

On Fri, Jan 22, 2021 at 04:44:42PM -0500, Jason Merrill wrote: > On 1/22/21 4:01 PM, Marek Polacek wrote: > > On Thu, Jan 21, 2021 at 09:47:35PM -0500, Jason Merrill via Gcc-patches > > wrote: > > > On 1/21/21 5:45 PM, Marek Polacek wrote: > > > > I discovered very strange code in

Re: [PATCH] c++: ICE with noexcept in class in member function [PR96623]

On Thu, Jan 21, 2021 at 09:47:35PM -0500, Jason Merrill via Gcc-patches wrote: > On 1/21/21 5:45 PM, Marek Polacek wrote: > > I discovered very strange code in inject_parm_decls: > > > > if (args && is_this_parameter (args)) > > { > > gcc_checking_assert (current_class_ptr ==

Re: [PATCH v3] c++: ICE when mangling operator name [PR98545]

On Thu, Jan 21, 2021 at 05:41:06PM -0500, Jason Merrill via Gcc-patches wrote: > On 1/21/21 2:44 PM, Marek Polacek wrote: > > @@ -3349,7 +3349,12 @@ write_expression (tree expr) > > else if (dependent_name (expr)) > > { > > tree name = dependent_name (expr); > > - gcc_assert

[PATCH] c++: ICE with noexcept in class in member function [PR96623]

I discovered very strange code in inject_parm_decls: if (args && is_this_parameter (args)) { gcc_checking_assert (current_class_ptr == NULL_TREE); current_class_ptr = NULL_TREE; We are tripping up on the assert because when we call inject_parm_decls, current_class_ptr is

Re: [PATCH] c++: Suppress this injection for static member functions [PR97399]

On Thu, Jan 21, 2021 at 11:22:24AM -0500, Patrick Palka via Gcc-patches wrote: > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to > the expression tmp::integral (because it's type-dependent, and also > current_class_ptr is set) within the trailing return type, and later >

Re: [PATCH v2] c++: ICE when mangling operator name [PR98545]

On Tue, Jan 19, 2021 at 05:38:20PM -0500, Marek Polacek via Gcc-patches wrote: > On Tue, Jan 19, 2021 at 03:47:47PM -0500, Jason Merrill via Gcc-patches wrote: > > On 1/13/21 6:39 PM, Marek Polacek wrote: > > > r11-6301 added some asserts in mangle.c, and now we trip over

Re: [PATCH v3] c++: ICE with delayed noexcept and attribute used [PR97966]

On Thu, Jan 21, 2021 at 01:55:24AM -0500, Jason Merrill wrote: > > + /* Now that we've gone through all the members, instantiate those > > + marked with attribute used. */ > > + for (tree : used) > > This doesn't need to be a reference. And I think we want this to happen > even later,

Re: [PATCH v2] c++: ICE with delayed noexcept and attribute used [PR97966]

On Tue, Jan 19, 2021 at 03:37:25PM -0500, Jason Merrill wrote: > On 1/12/21 9:13 PM, Marek Polacek wrote: > > Another ICE with delayed noexcept parsing, but a bit gnarlier. > > > > A function definition marked with __attribute__((used)) ought to be > > emitted even when it is not referenced in a

Re: [PATCH] c++: ICE when mangling operator name [PR98545]

On Tue, Jan 19, 2021 at 03:47:47PM -0500, Jason Merrill via Gcc-patches wrote: > On 1/13/21 6:39 PM, Marek Polacek wrote: > > r11-6301 added some asserts in mangle.c, and now we trip over one of > > them. In particular, it's the one asserting that we didn't get > > IDENTIFIER_ANY_OP_P when

Re: [PATCH v2] c++: Crash when deducing template arguments [PR98659]

On Tue, Jan 19, 2021 at 03:41:57PM -0500, Jason Merrill wrote: > On 1/13/21 1:38 PM, Marek Polacek wrote: > > maybe_instantiate_noexcept doesn't expect to see error_mark_node, so > > the new callsite I introduced in r11-6476 needs to be properly guarded. > > I'd rather fix

Re: [PATCH v2] c++: ICE with USING_DECL redeclaration [PR98687]

On Mon, Jan 18, 2021 at 05:18:46PM -0500, Jason Merrill wrote: > On 1/15/21 12:26 AM, Marek Polacek wrote: > > My recent patch that introduced push_using_decl_bindings didn't > > handle USING_DECL redeclaration, therefore things broke. This > > patch amends that. Note that I don't know if the

[PATCH] c++: ICE with USING_DECL redeclaration [PR98687]

My recent patch that introduced push_using_decl_bindings didn't handle USING_DECL redeclaration, therefore things broke. This patch amends that. Note that I don't know if the other parts of finish_nonmember_using_decl are needed (e.g. the binding->type setting) -- I couldn't trigger it by any of

[pushed] c++: Tweak g++.dg/template/pr98372.C.

This test was failing in C++11 because variable templates are only available in C++14. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: * g++.dg/template/pr98372.C: Only run in C++14 and up. --- gcc/testsuite/g++.dg/template/pr98372.C | 2 +- 1 file changed, 1

[PATCH] c++: ICE when mangling operator name [PR98545]

r11-6301 added some asserts in mangle.c, and now we trip over one of them. In particular, it's the one asserting that we didn't get IDENTIFIER_ANY_OP_P when mangling an expression with a dependent name. As this testcase shows, it's possible to get that, so turn the assert into an if and write

[PATCH] c++: Crash when deducing template arguments [PR98659]

maybe_instantiate_noexcept doesn't expect to see error_mark_node, so the new callsite I introduced in r11-6476 needs to be properly guarded. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: PR c++/98659 * pt.c (resolve_overloaded_unification): Don't

[PATCH] c++: Failure to lookup using-decl name [PR98231]

In r11-4690 we removed the call to finish_nonmember_using_decl in tsubst_expr/DECL_EXPR in the USING_DECL block. This was done not to perform name lookup twice for a non-dependent using-decl, which sounds sensible. However, finish_nonmember_using_decl also pushes the decl's bindings which we

[PATCH] c++: ICE with delayed noexcept and attribute used [PR97966]

Another ICE with delayed noexcept parsing, but a bit gnarlier. A function definition marked with __attribute__((used)) ought to be emitted even when it is not referenced in a TU. For a member function template marked with __attribute__((used)) this means that it will be instantiated: in

[PATCH] c++: ICE when late parsing noexcept/NSDMI [PR98333]

Since certain members of a class are a complete-class context [class.mem.general]p7, we delay their parsing untile the whole class has been parsed. For instance, NSDMIs and noexcept-specifiers. The order in which we perform this delayed parsing matters; we were first parsing NSDMIs and only they

[PATCH] c++: -Wmissing-field-initializers in unevaluated ctx [PR98620]

This PR wants us not to warn about missing field initializers when the code in question takes places in decltype and similar. Fixed thus. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: PR c++/98620 * typeck2.c (process_init_constructor_record):

[wwwdocs] Update C++ DR table with new DRs

I pushed this patch to update the DR table with a few new DRs. Also update some of the older ones to reflect that they're included in C++20. Marek commit 6be6626d59e1c492d5e05606e5a6902feb9e5bac Author: Marek Polacek Date: Mon Jan 11 17:18:45 2021 -0500 C++ DRs: Add new DRs, update

Re: [PATCH] c++: Add support for -std=c++2b

I think we should consider making this -std=c++23 right away this time, since we're on a three-year release schedule. Up to Jason though. Marek

[pushed] c++: Fix g++.dg/warn/Wmismatched-dealloc.C for C++11 [PR98566]

C++ sized deallocation only came in C++14, so this test wasn't working properly in C++11, which isn't tested by default. Fixed thus by constraining the dg-errors to C++14 only. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: PR testsuite/98566 *

[PATCH] c++: Fix thinko in auto return type checking [PR98441]

This fixes a thinko in my r11-2085 patch: when I said "But only give the !late_return_type errors when funcdecl_p, to accept e.g. auto (*fp)() = f; in C++11" I should've done this, otherwise we give bogus errors mentioning "function with trailing return type" when there is none.

[PATCH] c++: ICE with deferred noexcept when deducing targs [PR82099]

In this test we ICE in type_throw_all_p because it got a deferred noexcept which it shouldn't. Here's the story: In noexcept61.C, we call bar, so we perform overload resolution. When adding the (only) candidate, we need to deduce template arguments, so call fn_type_unification as usually. That

[pushed] c++: Remove dg-ice in constexpr-52830.C [PR52830]

It turned out that r11-5942 fixed this old PR, and it was detected by one of the few dg-ice tests -- exactly the point of them! Now the PR won't be opened until someone notices that it'd been fixed. The patch failed to remove the dg-ice though, so now it XPASSes. Fixing this now. Tested

[pushed] cody: Remove unused variable.

Tested x86_64-pc-linux-gnu, applying to trunk. libcody/ChangeLog: * buffer.cc (MessageBuffer::Lex): Remove unused variable. --- libcody/buffer.cc | 1 - 1 file changed, 1 deletion(-) diff --git a/libcody/buffer.cc b/libcody/buffer.cc index 52df3176c9a..3256c37399b 100644 ---

[pushed] c++: Add fixed test [PR91506]

Pre-r11-557 we issued a bogus error: parameter may not have variably modified type 'double [x]' but now we compile this, as we should. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: PR c++/91506 * g++.dg/init/array60.C: New test. ---

[pushed] c++: Add fixed test [PR68451]

I was about to add this test with dg-ice but it turned out it had already been fixed by the recent r11-3361! Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: PR c++/68451 * g++.dg/cpp0x/friend6.C: New test. --- gcc/testsuite/g++.dg/cpp0x/friend6.C | 23

[PATCH] c++: Fix printing of decltype(nullptr) [PR97517]

The C++ printer doesn't handle NULLPTR_TYPE, so we issue the ugly "'nullptr_type' not supported by...". Since NULLPTR_TYPE is decltype(nullptr), it seemed reasonable to handle it where we handle DECLTYPE_TYPE, that is, in the simple-type-specifier handler. Bootstrapped/regtested on

Re: [PATCH v2] c++: ICE with switch and scoped enum bit-fields [PR98043]

On Wed, Dec 02, 2020 at 09:50:33PM -0500, Jason Merrill wrote: > On 12/2/20 6:18 PM, Marek Polacek wrote: > > In this testcase we are crashing trying to gimplify a switch, because > > the types of the switch condition and case constants have different > > TYPE_PRECISIONs. > > > > This started

[PATCH] c-family: Fix hang with -Wsequence-point [PR98126]

verify_sequence_points uses verify_tree to recursively walk the subexpressions of an expression, and while recursing, it also keeps lists of expressions found after/before a sequence point. For a large expression, the list can grow significantly. And merge_tlist is at least N(n^2): for a list of

Re: [PATCH] c++: ICE with -fsanitize=vptr and constexpr dynamic_cast [PR98103]

On Wed, Dec 02, 2020 at 09:01:48PM -0500, Jason Merrill wrote: > On 12/2/20 6:18 PM, Marek Polacek wrote: > > -fsanitize=vptr initializes all vtable pointers to null so that it can > > catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs. That > > means that evaluating a vtable reference

Re: [PATCH RFA] vec: Simplify use with C++11 range-based 'for'.

On Thu, Dec 03, 2020 at 12:53:22PM -0500, Jason Merrill via Gcc-patches wrote: > It looks cleaner if we can use a vec* directly as a range for the C++11 > range-based 'for' loop, without needing to indirect from it, and also works > with null pointers. Nice. > The change in

[PATCH] c++: ICE with -fsanitize=vptr and constexpr dynamic_cast [PR98103]

-fsanitize=vptr initializes all vtable pointers to null so that it can catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs. That means that evaluating a vtable reference can produce a null pointer in this mode, so cxx_eval_dynamic_cast_fn should check that. Bootstrapped/regtested on

[PATCH] c++: ICE with switch and scoped enum bit-fields [PR98043]

In this testcase we are crashing trying to gimplify a switch, because the types of the switch condition and case constants have different TYPE_PRECISIONs. This started with my r5-3726 fix: SWITCH_STMT_TYPE is supposed to be the original type of the switch condition before any conversions, so in

Re: [PATCH] c++, v2: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

On Wed, Dec 02, 2020 at 01:13:26PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches wrote: > > Or simpler might be to always defer immediate evaluation of > > source_location::current() until genericize time. > > That works. > I

[PATCH] c++: Fix tsubst ICE with invalid code [PR97993, PR97187]

I had a strong sense of deja vu when looking into this, and no wonder, since this is almost identical to c++/95728. Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list instead of open coding it. While the latter could return an error node wrapped in a TREE_LIST, the former can

[PATCH] c++: Fix ICE with inline variable in template [PR97975]

In this test, we have static inline const int c = b; in a class template, and we call store_init_value as usual. There, the value is IMPLICIT_CONV_EXPR(b) which is is_nondependent_static_init_expression but isn't is_nondependent_constant_expression (they only differ in STRICT). We call

Re: Add pretty-printing support for __is_nothrow_{assignable, constructible}. [PR98054]

On Mon, Nov 30, 2020 at 01:19:32PM +0200, Ville Voutilainen via Gcc-patches wrote: > OK for trunk if full testsuite passes? Should we consider having some sort > of test that catches such omissions? IMHO this doesn't require a test. > 2020-11-30 Ville Voutilainen > > gcc/ > > PR

Re: [PATCH] c++: Reject identifier label in constexpr [PR97846]

On Fri, Nov 20, 2020 at 05:18:55PM -0500, Jason Merrill via Gcc-patches wrote: > On 11/16/20 9:58 PM, Marek Polacek wrote: > > [dcl.constexpr]/3 says that the function-body of a constexpr function > > shall not contain an identifier label, but we aren't enforcing that. > > > > This patch

Re: [PATCH] c++: Fix ICE-on-invalid with -Wvexing-parse [PR97881]

On Fri, Nov 20, 2020 at 05:23:56PM -0500, Jason Merrill wrote: > On 11/17/20 2:32 PM, Marek Polacek wrote: > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/warn/Wvexing-parse9.C > > @@ -0,0 +1,8 @@ > > +// PR c++/97881 > > +// { dg-do compile } > > + > > +void > > +cb () > > +{ > > + volatile

Re: [PATCH] c++: Add missing verify_type_context call [PR97904]

On Fri, Nov 20, 2020 at 07:27:54PM +, Richard Sandiford via Gcc-patches wrote: > When adding the verify_type_context target hook, I'd missed > a site that needs to check an array element type. > > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK for master > and GCC 10 branch? Not an

Re: [PATCH] unshare expressions in attribute arguments

On Fri, Nov 20, 2020 at 12:00:58PM -0700, Martin Sebor via Gcc-patches wrote: > To detect a subset of VLA misuses, the C front associates the bounds > of VLAs in function argument lists with the corresponding variables > by implicitly adding an instance of attribute access to each function >

Re: Modules doc

On Fri, Nov 20, 2020 at 10:19:55AM -0500, Nathan Sidwell wrote: > Here is an update c++ modules documentation patch. I'd be grateful for > review. Especially checking I'm not using too much implementor-speak > > nathan > -- > Nathan Sidwell > diff --git c/gcc/doc/cppopts.texi

[PATCH] c++: Fix wrong error with constexpr destructor [PR97427]

When I implemented the code to detect modifying const objects in constexpr contexts, we couldn't have constexpr destructors, so I didn't consider them. But now we can and that caused a bogus error in this testcase: [class.dtor]p5 says that "const and volatile semantics are not applied on an

[PATCH] c++: Fix crash with broken deduction from {} [PR97895]

Unfortunately, the otherwise beautiful for (constructor_elt : *CONSTRUCTOR_ELTS (init)) is not immune to an empty constructor, so we have to check CONSTRUCTOR_ELTS first. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: PR c++/97895 * pt.c

[PATCH] c++: Fix array new with value-initialization [PR97523]

Since my r11-3092 the following is rejected with -std=c++20: struct T { explicit T(); }; void fn(int n) { new T[1](); } with "would use explicit constructor 'T::T()'". It is because since that change we go into the P1009 block in build_new (array_p is false, but nelts is non-null and

Re: [PATCH] c++: Allow template lambdas without lambda-declarator [PR97839]

On Tue, Nov 17, 2020 at 01:05:20PM -0500, Marek Polacek via Gcc-patches wrote: > Our implementation of template lambdas incorrectly requires the optional > lambda-declarator. This was probably required by an early draft of > generic lambdas, but now the production is [expr.prim.lambd

[PATCH] c++: Fix ICE-on-invalid with -Wvexing-parse [PR97881]

This invalid (?) code broke my assumption that if decl_specifiers->type is null, there must be any type-specifiers. Turn the assert into an if to fix this crash. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: PR c++/97881 * parser.c

[PATCH] c++: Allow template lambdas without lambda-declarator [PR97839]

Our implementation of template lambdas incorrectly requires the optional lambda-declarator. This was probably required by an early draft of generic lambdas, but now the production is [expr.prim.lambda.general]: lambda-expression: lambda-introducer lambda-declarator [opt] compound-statement

[PATCH] c++: Reject identifier label in constexpr [PR97846]

[dcl.constexpr]/3 says that the function-body of a constexpr function shall not contain an identifier label, but we aren't enforcing that. This patch implements that. Of course, we can't reject artificial labels. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog:

Re: [PATCH v2] c++: Extend -Wrange-loop-construct for binding-to-temp [PR94695]

On Mon, Nov 16, 2020 at 05:02:14PM -0500, Jason Merrill via Gcc-patches wrote: > On 11/15/20 10:34 PM, Marek Polacek wrote: > > [ This year's end-of-stage1 I'm working virtually from American Samoa. ] > > > > This patch finishes the second half of -Wrange-loop-construct I promised > > to

Re: [PATCH] c: Reject _Atomic type * as last argument to __builtin_*_overflow [PR90628]

On Mon, Nov 16, 2020 at 10:17:19PM +0100, Jakub Jelinek via Gcc-patches wrote: > Hi! > > During the __builtin_clear_padding implementation, I've noticed we don't > diagnose _ATomic whatever * as last argument to __builtin_*_overflow. > As the storing by that builtin isn't atomic in any way, I

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On Mon, Nov 16, 2020 at 02:02:00PM -0500, Jason Merrill via Gcc-patches wrote: > On 11/16/20 12:42 PM, Martin Sebor wrote: > > On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: > > > This patch implements the long-desired -Wuninitialized warning for > > > m

[PATCH] c++: Extend -Wrange-loop-construct for binding-to-temp [PR94695]

[ This year's end-of-stage1 I'm working virtually from American Samoa. ] This patch finishes the second half of -Wrange-loop-construct I promised to implement: it warns when a loop variable in a range-based for-loop is initialized with a value of a different type resulting in a copy. For

[PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

This patch implements the long-desired -Wuninitialized warning for member initializer lists, so that the front end can detect bugs like struct A { int a; int b; A() : b(1), a(b) { } }; where the field 'b' is used uninitialized because the order of member initializers in the

Re: [PATCH] c++: Don't form a templated TARGET_EXPR in finish_compound_literal

On Thu, Nov 12, 2020 at 01:27:23PM -0500, Patrick Palka wrote: > The atom_cache in normalize_atom relies on the assumption that two > equivalent (templated) trees (in the sense of cp_tree_equal) must use > the same template parameters (according to find_template_parameters). > > This assumption

[PATCH] system: Add WARN_UNUSED_RESULT

I'd like to have the option of marking functions with __attribute__ ((__warn_unused_result__)), so this patch adds a macro. And use it for maybe_wrap_with_location, it's always a bug if the return value is not used, which happened to me and got me confused. Bootstrapped/regtested on

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On Tue, Nov 10, 2020 at 02:30:30PM -0500, Jason Merrill via Gcc-patches wrote: > On 11/10/20 2:28 PM, Marek Polacek wrote: > > On Tue, Nov 10, 2020 at 02:15:56PM -0500, Jason Merrill wrote: > > > On 11/10/20 1:59 PM, Marek Polacek wrote: > > > > On Tue, Nov 10, 2020 at 11:32:04AM -0500, Jason

[pushed] c++: Add 5 unfixed tests.

A couple of dg-ice tests. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: PR c++/52830 PR c++/88982 PR c++/90799 PR c++/87765 PR c++/89565 * g++.dg/cpp0x/constexpr-52830.C: New test. * g++.dg/cpp0x/vt-88982.C: New

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On Tue, Nov 10, 2020 at 02:15:56PM -0500, Jason Merrill wrote: > On 11/10/20 1:59 PM, Marek Polacek wrote: > > On Tue, Nov 10, 2020 at 11:32:04AM -0500, Jason Merrill wrote: > > > On 11/9/20 7:21 PM, Marek Polacek wrote: > > > > Currently, when a static_assert fails, we only say "static assertion

Re: RFC: Monitoring old PRs, new dg directives [v2]

On Tue, Nov 10, 2020 at 03:15:00PM +0100, Thomas Schwinge wrote: > Hi! > > On 2020-08-10T17:30:21-0400, Marek Polacek via Gcc-patches > wrote: > > This patch adds a new DejaGNU directive, dg-ice, as outlined in the > > proposal here: > > https://gcc.gnu.org/p

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On Tue, Nov 10, 2020 at 11:32:04AM -0500, Jason Merrill wrote: > On 11/9/20 7:21 PM, Marek Polacek wrote: > > Currently, when a static_assert fails, we only say "static assertion > > failed". > > It would be more useful if we could also print the expression that > > evaluated to false; this is

[PATCH] c++: Improve static_assert diagnostic [PR97518]

Currently, when a static_assert fails, we only say "static assertion failed". It would be more useful if we could also print the expression that evaluated to false; this is especially useful when the condition uses template parameters. Consider the motivating example, in which we have this line:

Re: [PATCH v2] c++: DR 1914 - Allow duplicate standard attributes.

On Fri, Nov 06, 2020 at 03:01:56PM -0500, Jason Merrill via Gcc-patches wrote: > On 11/6/20 2:34 PM, Marek Polacek wrote: > > On Fri, Nov 06, 2020 at 02:23:10PM -0500, Jason Merrill via Gcc-patches > > wrote: > > > On 11/6/20 2:06 PM, Marek Polacek wrote: > > > > Following Joseph's change for C

[PATCH] c++: Fix -Wvexing-parse ICE with omitted int [PR97762]

For declarations like long f(); decl_specifiers->type will be NULL, but I neglected to handle this case, therefore we ICE. So handle this case by pretending we've seen 'int', which is good enough for -Wvexing-parse's purposes. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

Re: [r11-4813 Regression] FAIL: c-c++-common/Wimplicit-fallthrough-20.c -std=gnu++98 (test for warnings, line 36) on Linux/x86_64

On Sat, Nov 07, 2020 at 10:15:14AM -0800, sunil.k.pandey via Gcc-patches wrote: > On Linux/x86_64, > > 8b7a9a249a63e066cff6e95db05a3158b4cc56cc is the first bad commit > commit 8b7a9a249a63e066cff6e95db05a3158b4cc56cc > Author: Martin Uecker > Date: Sat Nov 7 00:48:33 2020 +0100 > > C

Re: [PATCH] c++: DR 1914 - Allow duplicate standard attributes.

On Fri, Nov 06, 2020 at 02:23:10PM -0500, Jason Merrill via Gcc-patches wrote: > On 11/6/20 2:06 PM, Marek Polacek wrote: > > Following Joseph's change for C to allow duplicate C2x standard attributes > > , > > this patch does a

[PATCH] c++: DR 1914 - Allow duplicate standard attributes.

Following Joseph's change for C to allow duplicate C2x standard attributes , this patch does a similar thing for C++. This is DR 1914, to be resolved by , which is not part of the standard yet, but has a wide support so look like

[PATCH] c++: Small tweak to can_convert_eh [PR81660]

While messing with check_handlers_1, I spotted this bug report which complains that we don't warn about the case when we have two duplicated handlers of type int. can_convert_eh implements [except.handle] and that says: A handler is a match for an exception object of type E if - The handler is

Re: [PATCH] c++: Add -Wexceptions warning option [PR97675]

On Thu, Nov 05, 2020 at 06:13:41PM -0500, David Malcolm via Gcc-patches wrote: > On Thu, 2020-11-05 at 11:03 -0500, Marek Polacek via Gcc-patches wrote: > > This PR asks that we add a warning option for an existing (very old) > > warning, so that it can be disabled selectively

[PATCH] c++: Fix decltype(auto) deduction with rvalue ref [PR78209]

Here's a small deficiency in decltype(auto). [dcl.type.auto.deduct]/5: If the placeholder-type-specifier is of the form decltype(auto), [...] the type deduced for T is determined [...] as though E had been the operand of the decltype. So: int & = 0; decltype(auto) j = i; // should behave

[PATCH] c++: Add -Wexceptions warning option [PR97675]

This PR asks that we add a warning option for an existing (very old) warning, so that it can be disabled selectively. clang++ uses -Wexceptions for this, so I added this new option rather than using e.g. -Wnoexcept. gcc/c-family/ChangeLog: PR c++/97675 * c.opt (Wexceptions): New

Re: [PATCH v4] c++: Implement -Wvexing-parse [PR25814]

On Fri, Oct 30, 2020 at 04:33:48PM -0400, Jason Merrill wrote: > On 10/29/20 11:00 PM, Marek Polacek wrote: > > Gotcha. Now we do most of the work in warn_about_ambiguous_parse. > > Thanks, just a few tweaks left. > > --- a/gcc/cp/decl.c > > +++ b/gcc/cp/decl.c > > @@ -4378,6 +4378,9 @@

Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742]

On Sat, Oct 31, 2020 at 10:09:32AM +, Iain Sandoe wrote: > Hi Marek, > > Marek Polacek via Gcc-patches wrote: > > > On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote: > >> On 10/28/20 2:00 PM, Marek Polacek wrote: > >>> On Tue, Oct 27,

Re: [PATCH] c++: Don't try to parse a function declaration as deduction guide [PR97663]

On Mon, Nov 02, 2020 at 08:13:09PM +0100, Jakub Jelinek via Gcc-patches wrote: > Hi! > > While these function declarations have NULL decl_specifiers->type, > they have still type specifiers specified from which the default int > in the return type is added, so we shouldn't try to parse those as >

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On Thu, Oct 29, 2020 at 02:25:33PM -0400, Jason Merrill via Gcc-patches wrote: > On 10/29/20 2:11 PM, Marek Polacek wrote: > > On Thu, Oct 29, 2020 at 11:17:37AM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 10/28/20 7:40 PM, Marek Polacek wrote: > > > > On Wed, Oct 28, 2020 at

[PATCH] c++: Tweaks for value_dependent_expression_p.

We may not call value_dependent_expression_p on expressions that are not potential constant expressions, otherwise value_d could crash, as I saw recently (in C++98). So beef up the checking in i_d_e_p. This revealed a curious issue: when we have __PRETTY_FUNCTION__ in a template function, we set

[PATCH] c++: Disable -Winit-list-lifetime in unevaluated operand [PR97632]

Jon suggested turning this warning off when we're not actually evaluating the operand. This patch does that. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: PR c++/97632 * init.c (build_new_1): Disable -Winit-list-lifetime for an unevaluated

Re: [PATCH v2] c++: Deducing type from initializer_list [PR93107]

On Wed, Oct 28, 2020 at 03:18:18PM -0400, Jason Merrill via Gcc-patches wrote: > On 10/16/20 11:31 AM, Marek Polacek wrote: > > In this testcase we weren't able to deduce b's type: > > > >template void Task() { } > >auto b = { }; > > > > because resolve_nondeduced_context doesn't

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On Thu, Oct 29, 2020 at 11:17:37AM -0400, Jason Merrill via Gcc-patches wrote: > On 10/28/20 7:40 PM, Marek Polacek wrote: > > On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote: > > > On 10/28/20 1:58 PM, Marek Polacek wrote: > > > > On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason

Re: [PATCH v2] c++: Implement CWG 625: Use of auto as template-arg [PR97479]

On Wed, Oct 28, 2020 at 02:34:15PM -0400, Jason Merrill via Gcc-patches wrote: > On 10/28/20 2:02 PM, Marek Polacek wrote: > > This patch implements CWG 625 which prohibits using auto in a template > > argument. A few tests used this construction. We could perhaps only > > give an error in

Re: [PATCH] c++: Deprecate arithmetic convs on different enums [PR97573]

On Wed, Oct 28, 2020 at 02:43:30PM -0400, Jason Merrill wrote: > On 10/28/20 2:01 PM, Marek Polacek wrote: > > I noticed that C++20 P1120R0 deprecated certain arithmetic conversions > > as outlined in [depr.arith.conv.enum], but we don't warn about them. In > > particular, "If one operand is of

Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742]

On Wed, Oct 28, 2020 at 05:48:08PM -0400, Jason Merrill wrote: > On 10/28/20 5:29 PM, Marek Polacek wrote: > > On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote: > > > On 10/28/20 2:00 PM, Marek Polacek wrote: > > > > On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote: > > >

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote: > On 10/28/20 1:58 PM, Marek Polacek wrote: > > On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 10/24/20 7:40 PM, Marek Polacek wrote: > > > > On Fri, Oct 23, 2020 at 09:33:38PM -0400, Jason

Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742]

On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote: > On 10/28/20 2:00 PM, Marek Polacek wrote: > > On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote: > > > On 10/24/20 6:52 PM, Marek Polacek wrote: > > > > Here, in r11-155, I changed the call to uses_template_parms to > > >

[PATCH] c++: Improve the MVP -Wparentheses diagnostic.

I noticed that declarator->parenthesized is, for this warning, only set to the opening paren. But we can easily make it a range and generate a nicer diagnostic. Moreover, we can then offer a fix-it hint. TL;DR: This patch changes mvp3.C:8:7: warning: unnecessary parentheses in declaration of

[PATCH] c++: GCC accepts junk before fold-expression [PR86773]

Here we accept a bogus expression before a left fold: Recall that a fold expression looks like: fold-expression: ( cast-expression fold-operator ... ) ( ... fold-operator cast-expression ) ( cast-expression fold-operator ... fold-operator cast-expression ) but here we have (

[PATCH] c++: Implement CWG 625: Use of auto as template-arg [PR97479]

This patch implements CWG 625 which prohibits using auto in a template argument. A few tests used this construction. We could perhaps only give an error in C++20, but not in C++17 with -fconcepts. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: DR 625

[PATCH] c++: Deprecate arithmetic convs on different enums [PR97573]

I noticed that C++20 P1120R0 deprecated certain arithmetic conversions as outlined in [depr.arith.conv.enum], but we don't warn about them. In particular, "If one operand is of enumeration type and the other operand is of a different enumeration type or a floating-point type, this behavior is

Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742]

On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote: > On 10/24/20 6:52 PM, Marek Polacek wrote: > > Here, in r11-155, I changed the call to uses_template_parms to > > type_dependent_expression_p_push to avoid a crash in C++98 in > > value_dependent_expression_p on a non-constant

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via Gcc-patches wrote: > On 10/24/20 7:40 PM, Marek Polacek wrote: > > On Fri, Oct 23, 2020 at 09:33:38PM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 10/23/20 3:01 PM, Marek Polacek wrote: > > > > This patch implements the

<    3   4   5   6   7   8   9   10   11   >