Re: [PATCH] c++: Extend -Wpessimizing-move to other contexts

On Tue, Aug 16, 2022 at 03:23:18PM -0400, Jason Merrill wrote: > On 8/2/22 16:04, Marek Polacek wrote: > > In my recent patch which enhanced -Wpessimizing-move so that it warns > > about class prvalues too I said that I'd like to extend it so that it > > warns in more contexts where a std::move can

Re: add more C++ name hints

On Fri, Aug 05, 2022 at 09:35:33PM +0200, Ulrich Drepper via Gcc-patches wrote: > How about adding a few more names from the std namespace to get appropriate > hints? This patch compiles and the appropriate messages are printed. Is > there a problem with just adding more or even at some point all

Re: [PATCH v2] c++: Extend -Wredundant-move for const-qual objects [PR90428]

On Mon, Aug 15, 2022 at 03:43:38PM -0400, Jason Merrill wrote: > On 8/8/22 13:27, Marek Polacek wrote: > > This is to warn about this: > > > > T f5(const T t) > > { > >return std::move(t); // { dg-warning "redundant move" } > > } > > > > where OR fails because there's no T(const T&&) (or it's

[pushed] c++: Add new std::move test [PR67906]

As discussed in 67906, let's make sure we don't warn about a std::move when initializing when there's a T(const T&&) ctor. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/67906 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/Wredundant-move11.C: New test. --- .../g++.dg/cpp0x/Wre

[PATCH v2] c++: Implement -Wself-move warning [PR81159]

On Mon, Aug 15, 2022 at 03:54:05PM -0400, Jason Merrill wrote: > On 8/9/22 09:37, Marek Polacek wrote: > > + /* We're looking for *std::move ((T &) &arg), or > > + *std::move ((T &) (T *) r) if the argument it a reference. */ > > + if (!REFERENCE_REF_P (rhs) > > + || TREE_CODE (TREE_OPE

[PATCH v3] c++: Implement -Wself-move warning [PR81159]

On Thu, Aug 18, 2022 at 08:33:47PM -0400, Jason Merrill wrote: > On 8/18/22 13:19, Marek Polacek wrote: > > On Mon, Aug 15, 2022 at 03:54:05PM -0400, Jason Merrill wrote: > > > On 8/9/22 09:37, Marek Polacek wrote: > > > > + /* We're looking for *std::move ((T &) &arg), or > > > > + *std::move

[PATCH] testsuite: Add test for r11-4123

r11-4123 came without a test but I happened upon a nice test case that got fixed by that revision. So I think it'd be good to add it. The ICE was: phi-1.C: In constructor 'ElementManager::ElementManager()': phi-1.C:28:1: error: missing definition 28 | ElementManager::ElementManager() : array_

[PATCH v2] testsuite: Add test for r11-4123

On Mon, Aug 22, 2022 at 10:16:23AM -0700, Andrew Pinski wrote: > On Mon, Aug 22, 2022 at 9:58 AM Marek Polacek via Gcc-patches > wrote: > > > > r11-4123 came without a test but I happened upon a nice test case that > > got fixed by that revision. So I think it'd be

Re: [PATCH] c++: Extend -Wpessimizing-move to other contexts

On Mon, Aug 22, 2022 at 01:48:34PM +0200, Stephan Bergmann wrote: > On 16/08/2022 14:27, Marek Polacek via Gcc-patches wrote: > > Ping. (The other std::move patches depend on this one.) > > <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8d22c7cb8b1a6f9b67c54a798dd5504244614e

[PATCH] c++: Quash bogus -Wredundant-move warning

This patch fixes a pretty stoopid thinko. When I added code to warn about pessimizing std::move in initializations like T t{std::move(T())}; I also added code to unwrap the expression from { }. But when we have return {std::move(t)}; we cannot warn about a redundant std::move because the

[PATCH v4] c++: Implement -Wself-move warning [PR81159]

On Sat, Aug 20, 2022 at 05:31:52PM -0400, Jason Merrill wrote: > On 8/19/22 15:34, Marek Polacek wrote: > > On Thu, Aug 18, 2022 at 08:33:47PM -0400, Jason Merrill wrote: > > > On 8/18/22 13:19, Marek Polacek wrote: > > > > On Mon, Aug 15, 2022 at 03:54:05PM -0400, Jason Merrill wrote: > > > > > On

[PATCH v2] c: Implement C23 nullptr (N3042)

On Mon, Aug 15, 2022 at 05:48:34PM +, Joseph Myers wrote: > On Sat, 13 Aug 2022, Marek Polacek via Gcc-patches wrote: > > > This patch also defines nullptr_t in . I'm uncertain about > > the __STDC_VERSION__ version I should be checking. Also, I'm

Re: [PATCH] c: Implement C23 nullptr (N3042)

On Mon, Aug 15, 2022 at 04:03:13PM -0400, Jason Merrill wrote: > On 8/13/22 14:35, Marek Polacek wrote: > > This patch implements the C23 nullptr literal: > > , which is > > intended to replace the problematic definition of NULL which migh

Re: [PATCH v4] c++: Implement -Wself-move warning [PR81159]

On Tue, Aug 23, 2022 at 05:27:00PM -0400, Jason Merrill wrote: > On 8/23/22 09:39, Marek Polacek wrote: > > + tree arg = CALL_EXPR_ARG (fn, 0); > > + extract_op (arg); > > + if (TREE_CODE (arg) == ADDR_EXPR) > > +arg = TREE_OPERAND (arg, 0); > > + tree type = TREE_TYPE (lhs); > > + lhs = m

[PATCH v3] c: Implement C23 nullptr (N3042)

On Thu, Aug 25, 2022 at 05:28:09PM +, Joseph Myers wrote: > On Wed, 24 Aug 2022, Marek Polacek via Gcc-patches wrote: > > > Ah, okay. I had just copied what we do in C++ in null_ptr_cst_p and the > > rest of the patch worked under that assumption. I've added some

Re: [PATCH v4] c++: Implement -Wself-move warning [PR81159]

On Thu, Aug 25, 2022 at 09:25:43AM -0400, Jason Merrill wrote: > On 8/24/22 17:30, Marek Polacek wrote: > > On Tue, Aug 23, 2022 at 05:27:00PM -0400, Jason Merrill wrote: > > > On 8/23/22 09:39, Marek Polacek wrote: > > > > + tree arg = CALL_EXPR_ARG (fn, 0); > > > > + extract_op (arg); > > > > +

Re: [PATCH v3] c: Implement C23 nullptr (N3042)

On Thu, Aug 25, 2022 at 09:12:07PM +, Joseph Myers wrote: > On Thu, 25 Aug 2022, Marek Polacek via Gcc-patches wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > This version is OK. Thanks a lot. I've gone ahead and updated GCC 1

[PATCH v5] c++: Implement -Wself-move warning [PR81159]

On Thu, Aug 25, 2022 at 08:52:58PM -0400, Jason Merrill wrote: > On 8/25/22 17:49, Marek Polacek wrote: > > On Thu, Aug 25, 2022 at 09:25:43AM -0400, Jason Merrill wrote: > > > On 8/24/22 17:30, Marek Polacek wrote: > > > > On Tue, Aug 23, 2022 at 05:27:00PM -0400, Jason Merrill wrote: > > > > > On

[PATCH] c++: Fix C++11 attribute propagation [PR106712]

When we have [[noreturn]] int fn1 [[nodiscard]](), fn2(); "noreturn" should apply to both fn1 and fn2 but "nodiscard" only to fn1: [dcl.pre]/3: "The attribute-specifier-seq appertains to each of the entities declared by the declarators of the init-declarator-list." [dcl.spec.general]: "The attr

[PATCH v2] c++: Fix C++11 attribute propagation [PR106712]

On Mon, Aug 29, 2022 at 01:32:29PM -0400, Jason Merrill wrote: > On 8/26/22 19:01, Marek Polacek wrote: > > When we have > > > >[[noreturn]] int fn1 [[nodiscard]](), fn2(); > > > > "noreturn" should apply to both fn1 and fn2 but "nodiscard" only to fn1: > > [dcl.pre]/3: "The attribute-specifi

[PATCH] c++: __has_builtin gives the wrong answer [PR106759]

We've supported __is_nothrow_constructible since r11-4386, but names_builtin_p didn't know about it, so it gave the wrong answer for #if __has_builtin(__is_nothrow_constructible) ... #endif I've tested all C++-only built-ins and only two were missing. Bootstrapped/regtested on x86_64-pc-linux-

Re: C++: add -std={c,gnu}++{current,future}

On Wed, Jul 13, 2022 at 03:29:04PM -0400, Nathan Sidwell via Gcc-patches wrote: > Inspired by a user question. Jason, thoughts? FWIW, this makes sense. I mean, how could I be against a patch quoting Macbeth?! > Since C++ is such a moving target, Microsoft have /std:c++latest > (AFAICT clang do

Re: C++: add -std={c,gnu}++{current,future}

On Tue, Aug 30, 2022 at 09:22:14AM -0400, Jason Merrill via Gcc-patches wrote: > On 7/13/22 15:29, Nathan Sidwell wrote: > > Inspired by a user question.  Jason, thoughts? > > > > Since C++ is such a moving target, Microsoft have /std:c++latest > > (AFAICT clang does not), to select the currently

Re: -Wformat-overflow handling for %b and %B directives in C2X standard

On Mon, Aug 15, 2022 at 07:42:39PM +0300, Frolov Daniil wrote: > вт, 12 апр. 2022 г. в 00:56, Marek Polacek : > > > > > On Thu, Apr 07, 2022 at 02:10:48AM +0500, Frolov Daniil wrote: > > > Hello! Thanks for your feedback. I've tried to take into account your > > > comments. New patch applied to th

Re: [PATCH] c/c++: new warning: -Wxor-used-as-pow [PR90885]

This looks good to me, one thing though: On Thu, Aug 11, 2022 at 09:38:12PM -0400, David Malcolm via Gcc-patches wrote: > --- a/gcc/c-family/c.opt > +++ b/gcc/c-family/c.opt > @@ -1439,6 +1439,10 @@ Wwrite-strings > C ObjC C++ ObjC++ Var(warn_write_strings) Warning > In C++, nonzero means warn a

[pushed] c++: Remove unused declaration

This declaration was added in r260905 but the function was never defined. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * cp-tree.h (maybe_strip_ref_conversion): Remove. --- gcc/cp/cp-tree.h | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/cp/cp-tree.h b/gcc/cp/

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

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: r125211: Introduced moving from certain lvalues when returning them r171071: CWG 1148, enable move from value parameter on return r212099: CWG

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

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: > > > > r125211: Introduced

[PATCH] c++: __builtin_shufflevector with value-dep expr [PR105353]

Here we issue an error from c_build_shufflevector while parsing a template because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs (except the first two arguments). It checks if any of the arguments are type-dependent, if so, we leave the processing for later, but it should al

[PATCH] c++: ICE with temporary of class type in DMI [PR100252]

Consider struct A { int x; int y = x; }; struct B { int x = 0; int y = A{x}.y; // #1 }; where for #1 we end up with {.x=(&)->x, .y=(&)->x} that is, two PLACEHOLDER_EXPRs for different types on the same level in a {}. This crashes because our CONSTRUCTOR_PLACEHOLDER_B

[PATCH] c++: enum in generic lambda at global scope [PR105398]

We crash compiling this test since r11-7993 which changed lookup_template_class_1 so that we only call tsubst_enum when !uses_template_parms (current_nonlambda_scope ()) But here current_nonlambda_scope () is the global NAMESPACE_DECL ::, which doesn't have a type, therefore is considered type-

Re: [PATCH] c++: enum in generic lambda at global scope [PR105398]

On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote: > On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote: > > > We crash compiling this test since r11-7993 which changed > > lookup_template_class_1 so that we only call tsubst_enum when > > &g

Re: [PATCH RFA] c-family: attribute ((aligned, mode)) [PR100545]

On Wed, Apr 27, 2022 at 11:19:57AM -0400, Jason Merrill via Gcc-patches wrote: > The problem here was that handle_mode_attribute clobbered the changes of any > previous attribute, only copying type qualifiers to the new type. And > common_handle_aligned_attribute had previously set up the typedef,

Re: [PATCH] c++: enum in generic lambda at global scope [PR105398]

On Wed, Apr 27, 2022 at 11:47:02AM -0400, Jason Merrill wrote: > On 4/27/22 08:59, Marek Polacek wrote: > > On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote: > > > On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote: > > > > > > > We c

[PATCH v2] c++: ICE with temporary of class type in DMI [PR100252]

On Wed, Apr 27, 2022 at 11:00:46AM -0400, Patrick Palka wrote: > On Tue, 26 Apr 2022, Marek Polacek wrote: > > > Consider > > > > struct A { > > int x; > > int y = x; > > }; > > > > struct B { > > int x = 0; > > int y = A{x}.y; // #1 > > }; > > > > where for #1 we end up

[PATCH] c++: global-namespace-qualified var after class def [PR90107]

Here we wrongly reject the definition of "::N::a" struct A; namespace N { extern A a; } struct A {} ::N::a; because our code to diagnose a missing ; after a class definition doesn't realize that :: can follow a class definition. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/1

Re: [PATCH v2] c++: ICE with temporary of class type in DMI [PR100252]

On Thu, Apr 28, 2022 at 10:12:04AM -0400, Patrick Palka wrote: > On Wed, 27 Apr 2022, Marek Polacek wrote: > > > On Wed, Apr 27, 2022 at 11:00:46AM -0400, Patrick Palka wrote: > > > On Tue, 26 Apr 2022, Marek Polacek wrote: > > > > > > > Consider > > > > > > > > struct A { > > > > int x; >

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

This was fixed by r12-6329-g4f6bc28fc7dd86. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/71424 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist-array15.C: New test. --- gcc/testsuite/g++.dg/cpp0x/initlist-array15.C | 13 + 1 file changed, 13 insertions(+)

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

This was finally fixed for GCC 11 by r11-434. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/78244 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/Wnarrowing20.C: New test. --- gcc/testsuite/g++.dg/cpp0x/Wnarrowing20.C | 26 +++ 1 file changed, 26 insertions(

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

This was fixed by r269078. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/83596 gcc/testsuite/ChangeLog: * g++.dg/cpp1z/nontype5.C: New test. --- gcc/testsuite/g++.dg/cpp1z/nontype5.C | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 gcc/testsuite/g+

[PATCH] c++: pedwarn for empty unnamed enum in decl [PR67048]

[dcl.dcl]/5 says that enum { }; is ill-formed, and since r197742 we issue a pedwarn. However, the pedwarn also fires for enum { } x; which is well-formed. So only warn when {} is followed by a ;. This should be correct since you can't have "enum {}, " -- that produces "expected unqualif

[PATCH] c++: fix ICE on invalid attributes [PR96637]

This patch fixes crashes with invalid attributes. Arguably it could make sense to assert seen_error() too. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk = GCC 13? PR c++/96637 gcc/ChangeLog: * attribs.cc (decl_attributes): Check error_mark_node. gcc/cp/ChangeLog:

[PATCH] c++: wrong parse with functors [PR64679]

Consider struct F { F(int) {} F operator()(int) const { return *this; } }; and F(i)(0)(0); where we're supposed to first call the constructor and then invoke the operator() twice. However, we parse this as an init-declarator: "(i)" looks like a perfectly valid declarator, then we

[PATCH] c++: parse error with >= in template argument list [PR105436]

This patch fixes an oversight whereby we treated >= as the end of a template argument. This causes problems in C++14, because in cp_parser_template_argument we go different ways for C++14 and C++17: /* It must be a non-type argument. In C++17 any constant-expression is allowed. */ if (

Re: [PATCH] c++: parse error with >= in template argument list [PR105436]

On Tue, May 03, 2022 at 04:46:11PM -0400, Jason Merrill wrote: > On 5/3/22 16:43, Jakub Jelinek wrote: > > On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote: > > > On 5/2/22 12:19, Marek Polacek wrote: > > > > This patch fixes an oversight whereby we treated >= as the end of > > > > a t

Re: [PATCH] c++: wrong parse with functors [PR64679]

On Tue, May 03, 2022 at 04:43:05PM -0400, Jason Merrill via Gcc-patches wrote: > On 5/2/22 12:18, Marek Polacek wrote: > > Consider > > > >struct F { > > F(int) {} > > F operator()(int) const { return *this; } > >}; > > > > and > > > >F(i)(0)(0); > > > > where we're suppos

[PATCH] c++: wrong error with MVP and pushdecl [PR64679]

This patch fixes the second half of 64679. Here we issue a wrong "redefinition of 'int x'" for the following: struct Bar { Bar(int, int, int); }; int x = 1; Bar bar(int(x), int(x), int{x}); // #1 cp_parser_parameter_declaration_list does pushdecl every time it sees a named parameter

Re: [PATCH] c++: wrong error with MVP and pushdecl [PR64679]

On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote: > On 5/4/22 16:03, Marek Polacek wrote: > > This patch fixes the second half of 64679. Here we issue a wrong > > "redefinition of 'int x'" for the following: > > > >struct Bar { > > Bar(int, int, int); > >}; > > > >i

Re: [PATCH] Come up with {,UN}LIKELY macros.

On Thu, May 05, 2022 at 02:31:05PM +0200, Martin Liška wrote: > Some parts of the compiler already define: > #define likely(cond) __builtin_expect ((cond), 1) > > So the patch should unify it. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? >

Re: [PATCH] testsuite: Update Wconversion testcase check type.

On Thu, May 05, 2022 at 06:33:20PM +0800, jiawei wrote: > Some compiler target like arm-linux\riscv\power\s390x\xtensa-gcc handle > char as unsigned char, then there are no warnings occur and got FAIL cases. > Just change the type char into explicit signed char to keep the feature > consistency. >

[PATCH v2] c++: wrong error with MVP and pushdecl [PR64679]

On Wed, May 04, 2022 at 09:29:46PM -0400, Jason Merrill wrote: > On 5/4/22 19:20, Marek Polacek wrote: > > On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote: > > > On 5/4/22 16:03, Marek Polacek wrote: > > > > This patch fixes the second half of 64679. Here we issue a wrong > > > > "re

Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491]

On Fri, May 06, 2022 at 11:56:30AM -0400, Jason Merrill via Gcc-patches wrote: > On 5/6/22 11:22, Patrick Palka wrote: > > Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p > > in C++11/14 is rejecting the marked sub-aggregate initializer (of type S) > > > >W w = {.D.2445

[PATCH v3] c++: ICE with temporary of class type in DMI [PR100252]

On Tue, May 03, 2022 at 04:59:38PM -0400, Jason Merrill wrote: > Does this testcase still work with this patch? > > struct A { > const A* p = this; > }; > > struct B { > A a = A{}; > }; > > constexpr B b; > static_assert (b.a.p == &b.a); Ouch, no. Thanks for catching this, it would have be

[PATCH] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

This PR complains that we emit the "enumeration value not handled in switch" warning even though the enumerator was marked with the [[maybe_unused]] attribute. The first snag was that I couldn't just check TREE_USED, because the enumerator could have been used earlier in the function, which doesn'

[PATCH v2] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

Corrected version that avoids an uninitialized warning: This PR complains that we emit the "enumeration value not handled in switch" warning even though the enumerator was marked with the [[maybe_unused]] attribute. The first snag was that I couldn't just check TREE_USED, because the enumerator c

[PATCH] c++: Implement P2324R2, labels at the end of compound-stmts [PR103539]

This patch implements C++23 , which allows labels at the end of a compound statement. Its C FE counterpart was already implemented in r11-4813. In cp_parser_statement I rely on in_compound to determine whether we're in a compound-statement, so that the patch doesn't ac

[PATCH] c++: ICE with constexpr dtor on ARM [PR105529]

When compiling this test on ARM with -O, we ICE in cxx_eval_store_expression while evaluating a CALL_EXPR allocator::~allocator (&D.4529). Its body has this store: = this The RHS is evaluated into &D.4529 of type allocator *. The object, , is of type void *. Their types don't match so we go

Re: [PATCH v2] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

On Tue, May 10, 2022 at 08:58:46AM -0400, Jason Merrill wrote: > On 5/7/22 18:26, Marek Polacek wrote: > > Corrected version that avoids an uninitialized warning: > > > > This PR complains that we emit the "enumeration value not handled in > > switch" warning even though the enumerator was marked

Re: [PATCH] testsuite: Update Wconversion testcase check type.

On Tue, May 10, 2022 at 02:58:49PM -0700, Palmer Dabbelt wrote: > On Thu, 05 May 2022 11:45:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > > On Thu, May 05, 2022 at 06:33:20PM +0800, jiawei wrote: > > > Some compiler target like arm-linux\riscv\power\s390x\xtensa-gcc handle > > > char as unsigned

[PATCH v4] c++: ICE with temporary of class type in DMI [PR100252]

On Sat, May 07, 2022 at 06:02:13PM -0400, Jason Merrill wrote: > On 5/7/22 15:11, Marek Polacek wrote: > > On Tue, May 03, 2022 at 04:59:38PM -0400, Jason Merrill wrote: > > > Does this testcase still work with this patch? > > > > > > struct A { > > >const A* p = this; > > > }; > > > > > > st

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

This was fixed by r258755: PR c++/81311 - wrong C++17 overload resolution. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/81952 gcc/testsuite/ChangeLog: * g++.dg/overload/conv-op4.C: New test. --- gcc/testsuite/g++.dg/overload/conv-op4.C | 22 ++ 1 fi

[PATCH v5] c++: ICE with temporary of class type in DMI [PR100252]

On Sat, May 14, 2022 at 11:13:28PM -0400, Jason Merrill wrote: > On 5/13/22 19:41, Marek Polacek wrote: > > --- a/gcc/cp/typeck2.cc > > +++ b/gcc/cp/typeck2.cc > > @@ -1371,6 +1371,70 @@ digest_init_flags (tree type, tree init, int flags, > > tsubst_flags_t complain) > > return digest_init_r (

[PATCH] c++: suppress -Waddress warnings with *_cast [PR105569]

dynamic_cast can legally return nullptr, so I don't think it's helpful for -Waddress to warn for if (dynamic_cast(&ref)) // ... More generally, it's likely not useful to warn for the artificial POINTER_PLUS_EXPRs created by build_base_path. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok

[PATCH] c: use CONST_DECL for enumerators in TYPE_VALUES

The C and C++ FEs differ in TYPE_VALUES for an enum type: an entry in the list in the C++ FE has a CONST_DECL in the TREE_VALUE, but the C FE has only the numerical value of the CONST_DECL there. This has caused me some trouble in my PR105497 patch. Using a CONST_DECL is preferable because a CONS

Re: [PATCH] c: use CONST_DECL for enumerators in TYPE_VALUES

On Tue, May 17, 2022 at 09:35:14PM +, Joseph Myers wrote: > On Tue, 17 May 2022, Marek Polacek via Gcc-patches wrote: > > > The C and C++ FEs differ in TYPE_VALUES for an enum type: an entry in > > the list in the C++ FE has a CONST_DECL in the TREE_VALUE, but the C F

Re: [PATCH] c: use CONST_DECL for enumerators in TYPE_VALUES

On Tue, May 17, 2022 at 02:59:00PM -0700, Ian Lance Taylor wrote: > On Tue, May 17, 2022 at 2:46 PM Marek Polacek wrote: > > > > On Tue, May 17, 2022 at 09:35:14PM +, Joseph Myers wrote: > > > On Tue, 17 May 2022, Marek Polacek via Gcc-patches wrote: > > > &g

[PATCH v3] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

On Tue, May 10, 2022 at 09:54:12AM -0400, Marek Polacek wrote: > On Tue, May 10, 2022 at 08:58:46AM -0400, Jason Merrill wrote: > > On 5/7/22 18:26, Marek Polacek wrote: > > > Corrected version that avoids an uninitialized warning: > > > > > > This PR complains that we emit the "enumeration value

[PATCH] c: Implement new -Wenum-int-mismatch warning [PR105131]

In C, an enumerated type is compatible with char, a signed integer type, or an unsigned integer type (6.7.2.2/5). Therefore this code compiles: enum E { l = -1, z = 0, g = 1 }; int foo(void); enum E foo(void) { return z; } if the underlying type of 'enum E' is 'int' (if not, we emit an err

[PATCH] c++: fix SIGFPE with -Wclass-memaccess [PR105634]

Here we crash because we attempt to % by 0. Thus fixed. While at it, I've moved the -Wclass-memaccess tests into warn/. I've checked that the # of expected passes is the same before/after the move. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/105634 gcc/cp/ChangeL

[PATCH v2] c: Implement new -Wenum-int-mismatch warning [PR105131]

On Wed, May 18, 2022 at 11:14:25AM +0100, Pedro Alves wrote: > On 2022-05-18 00:56, Marek Polacek via Gcc-patches wrote: > > > +In C, an enumerated type is compatible with @code{char}, a signed > > +integer type, or an unsigned integer type. However, since the choice > >

[PATCH v3] c: Implement new -Wenum-int-mismatch warning [PR105131]

On Wed, May 18, 2022 at 08:58:02PM +, Joseph Myers wrote: > On Wed, 18 May 2022, Marek Polacek via Gcc-patches wrote: > > > diff --git a/gcc/testsuite/gcc.dg/Wenum-int-mismatch-1.c > > b/gcc/testsuite/gcc.dg/Wenum-int-mismatch-1.c > > new file mode 100644 > >

Re: [PATCH v5] c++: ICE with temporary of class type in DMI [PR100252]

Ping. On Mon, May 16, 2022 at 11:36:27AM -0400, Marek Polacek wrote: > On Sat, May 14, 2022 at 11:13:28PM -0400, Jason Merrill wrote: > > On 5/13/22 19:41, Marek Polacek wrote: > > > --- a/gcc/cp/typeck2.cc > > > +++ b/gcc/cp/typeck2.cc > > > @@ -1371,6 +1371,70 @@ digest_init_flags (tree type, tr

Re: [PATCH] c++: fix ICE on invalid attributes [PR96637]

Ping. On Fri, Apr 29, 2022 at 10:12:33AM -0400, Marek Polacek via Gcc-patches wrote: > This patch fixes crashes with invalid attributes. Arguably it could > make sense to assert seen_error() too. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk = GCC 13? > >

Re: [PATCH] c++: fix ICE on invalid attributes [PR96637]

On Tue, May 24, 2022 at 05:29:56PM +0530, Prathamesh Kulkarni wrote: > On Fri, 29 Apr 2022 at 19:44, Marek Polacek via Gcc-patches > wrote: > > > > This patch fixes crashes with invalid attributes. Arguably it could > > make sense to assert seen_error() too. > >

Re: [PATCH] c: Improve build_component_ref diagnostics [PR91134]

On Tue, May 24, 2022 at 09:25:57AM +0200, Jakub Jelinek wrote: > Hi! > > On the following testcase (the first dg-error line) we emit a weird > diagnostics and even fixit on pointerpointer->member > where pointerpointer is pointer to pointer to struct and we say > 'pointerpointer' is a pointer; did

Re: [PATCH v5] c++: ICE with temporary of class type in DMI [PR100252]

On Tue, May 24, 2022 at 08:36:39AM -0400, Jason Merrill wrote: > On 5/16/22 11:36, Marek Polacek wrote: > > +static tree > > +replace_placeholders_for_class_temp_r (tree *tp, int *, void *data) > > +{ > > + tree t = *tp; > > + tree full_expr = *static_cast(data); > > + > > + /* We're looking for

[wwwdocs] Add C status page

I thought it'd be nice to have a table that documents our C support status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++. We have https://gcc.gnu.org/c99status.html, but that's C99 only. So here's a patch to add just that. For C99, I used c99status.html but added paper number

Re: [PATCH v5] c++: ICE with temporary of class type in DMI [PR100252]

On Tue, May 24, 2022 at 04:01:37PM -0400, Jason Merrill wrote: > On 5/24/22 09:55, Marek Polacek wrote: > > On Tue, May 24, 2022 at 08:36:39AM -0400, Jason Merrill wrote: > > > On 5/16/22 11:36, Marek Polacek wrote: > > > > +static tree > > > > +replace_placeholders_for_class_temp_r (tree *tp, int

Re: [wwwdocs] Add C status page

On Tue, May 24, 2022 at 06:11:09PM +, Joseph Myers wrote: > On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote: > > > I thought it'd be nice to have a table that documents our C support > > status, like we have https://gcc.gnu.org/projects/cxx-status.html for

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++: 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 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 @@ cxx_init_

[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

[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 &&i = 0; decltype(auto) j = i; // should behave l

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++: 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 of

[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

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 si

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 Pars

[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? gcc/

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 to

[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] 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 esp

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

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

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 Merri

[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 x86_64-pc-linu

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 un

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

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