[PATCH] c++: Handle auto(x) in parameter-declaration-clause [PR103401]

In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid, so void f(decltype(auto(0))); should be just as void f(int); but currently, everytime we see 'auto' in a parameter-declaration-clause, we try to synthesize_implicit_template_parm for it, creating a new template

Re: [PATCH RFA (fold/symtab)] c++: constexpr, fold, weak redecl, fp/0 [PR103310]

On Tue, Nov 30, 2021 at 09:09:41PM -0500, Jason Merrill via Gcc-patches wrote: > For PR61825, honza changed tree_single_nonzero_warnv_p to prevent a later > declaration from marking a function as weak after we've determined that it > wasn't weak before. But we shouldn't do that for speculative

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On Tue, Nov 30, 2021 at 04:00:01PM +0100, Stephan Bergmann wrote: > On 30/11/2021 14:26, Marek Polacek wrote: > > On Tue, Nov 30, 2021 at 09:38:57AM +0100, Stephan Bergmann wrote: > > > On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote: > > > > On Mon, No

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On Tue, Nov 30, 2021 at 09:38:57AM +0100, Stephan Bergmann wrote: > On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote: > > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote: > > > Ping, can we conclude on the name? IMHO, -Wbidirectional is just fine,

Re: [PATCH][RFC] middle-end/46476 - resurrect -Wunreachable-code

On Wed, Nov 24, 2021 at 04:21:31PM +0100, Richard Biener via Gcc-patches wrote: > This resurrects -Wunreachable-code and implements a warning for > trivially unreachable code as of CFG construction. Most problematic > with this is the C/C++ frontend added 'return 0;' stmt in main > which the

[PATCH v2] c++: Fix missing NSDMI diagnostic in C++98 [PR103347]

On Tue, Nov 23, 2021 at 02:42:12PM -0500, Jason Merrill wrote: > On 11/22/21 17:17, Marek Polacek wrote: > > Here the problem is that we aren't detecting a NSDMI in C++98: > > > > struct A { > >void *x = NULL; > > }; > > > > because maybe_warn_cpp0x uses input_location and that happens to

[wwwdocs] Update C++ DR table

This patch updates the C++ DR table. Several older DRs are now in the standard, and we have a few new ones. Pushed. --- htdocs/projects/cxx-dr-status.html | 232 - 1 file changed, 158 insertions(+), 74 deletions(-) diff --git a/htdocs/projects/cxx-dr-status.html

[pushed] c++: Add static in g++.dg/warn/Waddress-5.C

While reviewing some other changes I noticed that this test talks about 'sf' being static, but it wasn't actually marked as such. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: * g++.dg/warn/Waddress-5.C: Make sf static. ---

[wwwdocs] Document new C++ features in GCC 12

I've reviewed all the C++ patches that have gone into GCC 12, and documented the ones that seemed most interesting/relevant to our users. Additionally, I've also added links to the proposals/PRs/git commits so that it's easier to find out more. I've also updated our C++ DR table. Validates,

Re: [PATCH] libcpp: Use [[likely]] conditionally

On Tue, Nov 23, 2021 at 04:26:19PM +0100, Christophe LYON via Gcc-patches wrote: > Hi! > > On 23/11/2021 01:26, Jeff Law via Gcc-patches wrote: > > > > > > On 11/22/2021 10:22 AM, Marek Polacek via Gcc-patches wrote: > > > Let's hide [[likely]]

Re: [PATCH] handle member references in -Waddress [PR96507]

On Mon, Nov 22, 2021 at 04:00:56PM -0700, Martin Sebor via Gcc-patches wrote: > While going through old -Waddress bug reports to close after > the recent improvements to the warning I came across PR 96507 > that points out that member references aren't handled. Since > testing the address of a

[PATCH] c++: Fix missing NSDMI diagnostic in C++98 [PR103347]

Here the problem is that we aren't detecting a NSDMI in C++98: struct A { void *x = NULL; }; because maybe_warn_cpp0x uses input_location and that happens to point to NULL which comes from a system header. Jakub suggested changing the location to the '=', thereby avoiding the system header

[PATCH] libcpp: Use [[likely]] conditionally

Let's hide [[likely]] behind a macro, to suppress warnings if the compiler doesn't support it. Co-authored-by: Jonathan Wakely Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR preprocessor/103355 libcpp/ChangeLog: * lex.c: Use ATTR_LIKELY instead of [[likely]].

[wwwdocs] Document some new C++ features in GCC 12

Pushed. --- htdocs/gcc-12/changes.html | 7 +++ 1 file changed, 7 insertions(+) diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index 5f0214bd..43fc5bc0 100644 --- a/htdocs/gcc-12/changes.html +++ b/htdocs/gcc-12/changes.html @@ -166,6 +166,11 @@ a work-in-progress.

[PATCH] c++: -Wuninitialized for mem-inits and empty classes [PR19808]

This fixes a bogus -Wuninitialized warning: there's nothing to initialize in empty classes, so don't add them into our uninitialized set. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/19808 gcc/cp/ChangeLog: * init.c (emit_mem_initializers): Don't add

[pushed] c++: Fix cpp0x/lambda/lambda-nested9.C with C++11

Unfortunately dejagnu doesn't honor #if/#endif, so this test was failing with -std=c++11: FAIL: g++.dg/cpp0x/lambda/lambda-nested9.C -std=c++11 (test for errors, line 37) Fixed thus. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: *

Re: [PATCH v2] c++: Implement -Wuninitialized for mem-initializers (redux) [PR19808]

On Thu, Nov 18, 2021 at 05:10:47PM -0500, Jason Merrill wrote: > On 11/8/21 18:41, Marek Polacek wrote: > > @@ -1311,13 +1462,25 @@ emit_mem_initializers (tree mem_inits) > > if (!COMPLETE_TYPE_P (current_class_type)) > > return; > > + /* Keep a set holding fields that are not

Re: [PATCH] c++: Implement C++23 P0849R8 - auto(x) [PR103049]

On Thu, Nov 18, 2021 at 05:36:45PM -0500, Jason Merrill wrote: > On 11/4/21 16:26, Marek Polacek wrote: > > This patch implements P0849R8 which allows auto in a functional cast, > > the result of which is a prvalue. > > > > [expr.type.conv]/1 says that the type is determined by placeholder type >

Re: [PATCH] c++: designated init of char array by string constant [PR55227]

On Wed, Nov 17, 2021 at 10:23:58PM -0500, will wray wrote: > V2 Patch > https://gcc.gnu.org/bugzilla/attachment.cgi?id=51828 Can you please post the v2 here on the mailing list? It will be easier for us to reply. Preferably with the subject adjusted to say [PATCH v2] ... > On Wed, Nov 17,

Re: [PATCH 2/2] libcpp: capture and underline ranges in -Wbidi-chars= [PR103026]

On Wed, Nov 17, 2021 at 05:45:15PM -0500, David Malcolm wrote: > This patch converts the bidi::vec to use a struct so that we can > capture location_t values for the bidirectional control characters. Thanks for these improvements. I noticed a few nits, but nothing that needs to be fixed

Re: [PATCH] libcpp: Fix up handling of block comments in -fdirectives-only mode [PR103130]

On Wed, Nov 17, 2021 at 10:22:32AM +0100, Jakub Jelinek wrote: > Hi! > > Normal preprocessing, -fdirectives-only preprocessing before the Nathan's > rewrite, and all other compilers I've tried on godbolt treat even \*/ > as end of a block comment, but the new -fdirectives-only handling doesn't. >

Re: [PATCH] handle folded nonconstant array bounds [PR101702]

On Tue, Nov 16, 2021 at 05:32:00PM -0700, Martin Sebor via Gcc-patches wrote: > -Warray-parameter and -Wvla-parameter assume that array bounds > in function parameters are either constant integers or variable, > but not something in between like a cast of a constant that's > not recognized as an

Re: [PATCH v3] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On Tue, Nov 16, 2021 at 09:28:21PM -0500, David Malcolm wrote: > On Tue, 2021-11-16 at 19:37 -0500, Marek Polacek wrote: > > Sorry for a dumb question, but is this what you have in mind? > > > > /* LRE > >    PDF */ > > /* FSI > >    PDI */ > > and check that we warn for these? > > I mean

[PATCH v3] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On Tue, Nov 16, 2021 at 06:00:58PM -0500, David Malcolm wrote: > > On Mon, Nov 15, 2021 at 06:15:40PM -0500, David Malcolm wrote: > > > > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote: > > > > > Ping, can we conclude on the name? IMHO, -Wbidirectional is just > > > > > fine, > >

Re: [PATCH] Fix spelling of ones' complement.

On Tue, Nov 16, 2021 at 01:09:15PM -0800, Mike Stump via Gcc-patches wrote: > On Nov 15, 2021, at 5:48 PM, Marek Polacek via Gcc-patches > wrote: > > > > Nitpicking time. It's spelled "ones' complement" rather than "one's > > complement". I d

[PATCH v2] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On Mon, Nov 15, 2021 at 06:15:40PM -0500, David Malcolm wrote: > > On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote: > > > Ping, can we conclude on the name? IMHO, -Wbidirectional is just fine, > > > but changing the name is a trivial operation. > > > > Here's a patch with a

Re: [PATCH RFC] c-family: don't cache large vecs

On Tue, Nov 16, 2021 at 11:53:14AM -0500, Jason Merrill via Gcc-patches wrote: > Patrick observed recently that an element of the vector cache could be > arbitrarily large. Let's only cache relatively small vecs. > > This has no effect on compiling the libstdc++ stdc++.h, presumably because >

Re: [PATCH] Fix spelling of ones' complement.

On Tue, Nov 16, 2021 at 02:01:47AM +, Koning, Paul via Gcc-patches wrote: > > > > On Nov 15, 2021, at 8:48 PM, Marek Polacek via Gcc-patches > > wrote: > > > > Nitpicking time. It's spelled "ones' complement" rather than "one's > > com

[PATCH] Fix spelling of ones' complement.

Nitpicking time. It's spelled "ones' complement" rather than "one's complement". I didn't go into config/. Ok for trunk? gcc/ChangeLog: * doc/implement-c.texi: Fix spelling. * doc/md.texi: Likewise. * expmed.c (emit_store_flag_int): Likewise. * optabs.c

Re: [PATCH] c++: designated init of char array by string constant [PR55227]

Hi, thanks for the patch and sorry for the delay in reviewing. On Sat, Nov 06, 2021 at 08:17:23PM -0400, Will Wray via Gcc-patches wrote: > This patch aims to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55227. > > There are two underlying bugs in the designated initialization of char array

[PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote: > Ping, can we conclude on the name? IMHO, -Wbidirectional is just fine, > but changing the name is a trivial operation. Here's a patch with a better name (suggested by Jonathan W.). Otherwise no changes. Bootstrapped/regtested

Re: [PATCH v2] implement -Winfinite-recursion [PR88232]

On Thu, Nov 11, 2021 at 11:21:01AM -0700, Martin Sebor wrote: > On 11/10/21 2:27 PM, Marek Polacek wrote: > > On Tue, Nov 09, 2021 at 09:28:43PM -0700, Martin Sebor via Gcc-patches > > wrote: > > > The attached patch adds support to the middle end for detecting > > > infinitely recursive calls.

Re: [PATCH] implement -Winfinite-recursion [PR88232]

On Tue, Nov 09, 2021 at 09:28:43PM -0700, Martin Sebor via Gcc-patches wrote: > The attached patch adds support to the middle end for detecting > infinitely recursive calls. The warning is controlled by the new > -Winfinite-recursion option. The option name is the same as > Clang's. > > I

[PATCH v8] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Tue, Nov 09, 2021 at 02:17:14PM -0500, Marek Polacek wrote: > On Tue, Nov 09, 2021 at 12:27:28PM -0500, Jason Merrill wrote: > > On 11/9/21 10:55, Marek Polacek wrote: > > > On Tue, Nov 09, 2021 at 08:09:10AM +0100, Bernhard Reutner-Fischer wrote: > > > > On Tue, 9 Nov 2021 00:12:10 -0500 > > >

Re: [PATCH v7] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Tue, Nov 09, 2021 at 08:57:48PM +0100, Bernhard Reutner-Fischer wrote: > On Tue, 9 Nov 2021 20:47:02 +0100 > Bernhard Reutner-Fischer wrote: > > > On Tue, 9 Nov 2021 14:17:14 -0500 > > Marek Polacek wrote: > > > > > + if (!valid_p (vendor_start, vendor_len) > > > + || !valid_p

[PATCH v7] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Tue, Nov 09, 2021 at 12:27:28PM -0500, Jason Merrill wrote: > On 11/9/21 10:55, Marek Polacek wrote: > > On Tue, Nov 09, 2021 at 08:09:10AM +0100, Bernhard Reutner-Fischer wrote: > > > On Tue, 9 Nov 2021 00:12:10 -0500 > > > Jason Merrill wrote: > > > > > > > On 11/8/21 20:41, Marek Polacek

Re: Merge IPA and late local modref flags

On Tue, Nov 09, 2021 at 05:32:42PM +0100, Jan Hubicka via Gcc-patches wrote: > > > + } > > > + if (!(flags & EAF_UNUSED)) > > > + lags |= past; > >    ^ > > > > > > Broke bootstrap. > Martin just fixed it. Sorry for that. > Diff complained about 8 spaces instead of tab

Re: [PATCH v6] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Tue, Nov 09, 2021 at 08:09:10AM +0100, Bernhard Reutner-Fischer wrote: > On Tue, 9 Nov 2021 00:12:10 -0500 > Jason Merrill wrote: > > > On 11/8/21 20:41, Marek Polacek wrote: > > > On Sat, Nov 06, 2021 at 03:29:57PM -0400, Jason Merrill wrote: > > > > + for (auto opt : v) > > > +{ > >

Re: [PATCH v6] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

0100, Bernhard Reutner-Fischer > > > > wrote: > > > > > On 6 November 2021 01:21:43 CET, Marek Polacek via Gcc-patches > > > > > wrote: > > > > > > > > > > > > > > > > > Thanks, so like this? I'm includ

Re: [wwwdocs] Document feature test macro for C++ constexpr dynamic alloc

On Tue, Nov 09, 2021 at 02:04:09PM +, Jonathan Wakely wrote: > OK for wwwdocs? Sure, thanks. > --- > htdocs/projects/cxx-status.html | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html > index

[PATCH v6] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Sat, Nov 06, 2021 at 03:29:57PM -0400, Jason Merrill wrote: > On 11/6/21 14:28, Marek Polacek wrote: > > On Sat, Nov 06, 2021 at 02:32:26AM +0100, Bernhard Reutner-Fischer wrote: > > > On 6 November 2021 01:21:43 CET, Marek Polacek via Gcc-patches > > > wrote: >

[PATCH v2] c++: Implement -Wuninitialized for mem-initializers (redux) [PR19808]

On Sun, Nov 07, 2021 at 12:45:24AM -0400, Jason Merrill wrote: > On 11/5/21 19:22, Marek Polacek wrote: > > 2021 update: Last year I posted a version of this patch: > > > > but it didn't make it in. The main objection seemed to

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

On Sun, Nov 07, 2021 at 04:48:46PM -0700, Martin Sebor wrote: > On 11/5/21 5:22 PM, Marek Polacek via Gcc-patches wrote: > > 2021 update: Last year I posted a version of this patch: > > <https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559162.html> > > but it d

[PATCH] c++: Skip unnamed bit-fields more

As Jason noticed in , we shouldn't require an initializer for an unnamed bit-field, because, as [class.bit] says, they cannot be initialized. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog:

Re: [PATCH v5] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Sat, Nov 06, 2021 at 02:32:26AM +0100, Bernhard Reutner-Fischer wrote: > On 6 November 2021 01:21:43 CET, Marek Polacek via Gcc-patches > wrote: > > > > >Thanks, so like this? I'm including an incremental diff so that it's > >clear what changed: > > &g

[PATCH v5] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Fri, Nov 05, 2021 at 02:48:31PM -0400, Jason Merrill wrote: > On 9/28/21 16:20, Marek Polacek wrote: > > On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote: > > > On 9/20/21 18:59, Marek Polacek via Gcc-patches wrote: > > > > + ha

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

2021 update: Last year I posted a version of this patch: but it didn't make it in. The main objection seemed to be that the patch tried to do too much, and overlapped with the ME uninitialized warnings. Since the patch used

[PATCH] c++: Implement C++23 P0849R8 - auto(x) [PR103049]

This patch implements P0849R8 which allows auto in a functional cast, the result of which is a prvalue. [expr.type.conv]/1 says that the type is determined by placeholder type deduction. We only accept 'auto', not 'decltype(auto)' -- that the type shall be auto comes from [dcl.type.auto.deduct].

[pushed] testsuite: Fix g++.dg/opt/pr102970.C

This test uses a generic lambda, only available since C++14, so don't run it in earlier modes. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: * g++.dg/opt/pr102970.C: Only run in C++14 and up. --- gcc/testsuite/g++.dg/opt/pr102970.C | 2 +- 1 file changed, 1

Re: [PATCH] attribs: Allow optional second arg for attr deprecated [PR102049]

On Mon, Nov 01, 2021 at 05:15:03PM -0600, Martin Sebor wrote: > On 10/11/21 9:17 AM, Marek Polacek via Gcc-patches wrote: > > Any thoughts? > > I'm a little unsure. Clang just uses the replacement string > as the text of the fix-it note as is, so it does nothing to > help

Re: [PATCH v2] libcpp: Implement -Wbidirectional for CVE-2021-42574 [PR103026]

On Tue, Nov 02, 2021 at 01:20:03PM -0600, Martin Sebor wrote: > On 11/2/21 11:18 AM, Marek Polacek via Gcc-patches wrote: > > On Mon, Nov 01, 2021 at 10:10:40PM +, Joseph Myers wrote: > > > On Mon, 1 Nov 2021, Marek Polacek via Gcc-patches wrote: > > > > >

Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]

On Tue, Nov 02, 2021 at 12:51:16PM -0600, Martin Sebor via Gcc-patches wrote: > On 10/4/21 4:39 PM, Eric Gallager wrote: > > On Mon, Oct 4, 2021 at 2:43 PM Martin Sebor via Gcc-patches > > wrote: > > > > > > While resolving the recent -Waddress enhancement request (PR > > > PR102103) I came

[PATCH v2] libcpp: Implement -Wbidirectional for CVE-2021-42574 [PR103026]

On Mon, Nov 01, 2021 at 10:10:40PM +, Joseph Myers wrote: > On Mon, 1 Nov 2021, Marek Polacek via Gcc-patches wrote: > > > + /* We've read a bidi char, update the current vector as necessary. */ > > + void on_char (kind k, bool ucn_p) > >

Re: [PATCH v4] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

Ping. On Mon, Oct 11, 2021 at 11:17:11AM -0400, Marek Polacek wrote: > Ping. > > On Tue, Sep 28, 2021 at 04:20:46PM -0400, Marek Polacek wrote: > > On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote: > > > On 9/20/21 18:59, Marek Polacek via Gcc-patc

[PATCH v2] c++: P2360R0: Extend init-stmt to allow alias-decl [PR102617]

On Thu, Oct 21, 2021 at 04:56:57PM -0400, Jason Merrill wrote: > On 10/21/21 16:26, Marek Polacek wrote: > > The following patch implements C++23 P2360R0. This proposal merely > > extends init-statement to contain alias-declaration. init-statement > > is used in if/for/switch. The unsightly

[PATCH] c++: P2360R0: Extend init-stmt to allow alias-decl [PR102617]

The following patch implements C++23 P2360R0. This proposal merely extends init-statement to contain alias-declaration. init-statement is used in if/for/switch. The unsightly duplication of the new code seems to be necessary to handle for ( init-statement condition[opt] ; expression[opt] )

Re: (!HELP NEEDED) Where is the doc for the format strings in gcc (for example, %q+D, ...)

On Wed, Oct 20, 2021 at 03:49:09PM +, Qing Zhao via Gcc-patches wrote: > Hi, > > In GCC, there are many utility routines for reporting error, warning, or > information, for example: > > warning (0, "weak declaration of %q+D not supported", decl); > warning_at (stmtloc,

Re: [PATCH] attribs: Allow optional second arg for attr deprecated [PR102049]

Any thoughts? On Thu, Sep 23, 2021 at 12:16:36PM -0400, Marek Polacek via Gcc-patches wrote: > Clang implements something we don't have: > > __attribute__((deprecated("message", "replacement"))); > > which seems pretty neat so I wrote this patch to a

Re: [PATCH v4] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

Ping. On Tue, Sep 28, 2021 at 04:20:46PM -0400, Marek Polacek wrote: > On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote: > > On 9/20/21 18:59, Marek Polacek via Gcc-patches wrote: > > > +void > > > +handle_ignored_attributes_option (vec *v) > &g

[wwwdocs] Update cxx-status with October 2021 WG21 plenary

Pushed. Jakub already added the feature test macros. commit 78f03a4a633950743a416f5b9e7f721db7892090 Author: Marek Polacek Date: Tue Oct 5 12:57:19 2021 -0400 cxx-status: Add papers from the October 2021 WG21 plenary diff --git a/htdocs/projects/cxx-status.html

Re: [PATCH] c++: Implement C++23 P2334R1 - #elifdef/#elifndef

On Tue, Oct 05, 2021 at 10:35:12AM +0200, Jakub Jelinek wrote: > Hi! > > This patch implements C++23 P2334R1, which is easy because Joseph has done > all the hard work for C2X already. > Unlike the C N2645 paper, the C++ P2334R1 contains one important addition > (but not in the normative text): >

[PATCH v2] c-family: Implement -Warray-compare [PR97573]

On Fri, Oct 01, 2021 at 11:15:45PM +0200, Jakub Jelinek wrote: > On Fri, Oct 01, 2021 at 04:11:08PM -0400, Marek Polacek via Gcc-patches wrote: > > + auto_diagnostic_group d; > > + if (warning_at (location, OPT_Warray_compare, > > + "compa

Re: [PATCH] c++: Implement C++20 -Wdeprecated-array-compare [PR97573]

On Fri, Oct 01, 2021 at 09:30:41AM -0400, Jason Merrill wrote: > On 9/30/21 17:56, Marek Polacek wrote: > > On Thu, Sep 30, 2021 at 03:34:24PM -0400, Jason Merrill wrote: > > > On 9/30/21 10:50, Marek Polacek wrote: > > > > This patch addresses one of my leftovers from GCC 11. C++20 introduced >

[PATCH] c-family: Implement -Warray-compare [PR97573]

This patch addresses one of my leftovers from GCC 11. C++20 introduced [depr.array.comp]: "Equality and relational comparisons between two operands of array type are deprecated." so this patch adds -Warray-compare. Since the code in question is dubious (the comparison doesn't actually compare

Re: [PATCH] c++: Implement C++20 -Wdeprecated-array-compare [PR97573]

On Fri, Oct 01, 2021 at 09:16:53AM -0600, Martin Sebor wrote: > On 9/30/21 8:50 AM, Marek Polacek via Gcc-patches wrote: > > This patch addresses one of my leftovers from GCC 11. C++20 introduced > > [depr.array.comp]: > > "Equality and relational comparisons between

Re: [PATCH] c++: Implement C++20 -Wdeprecated-array-compare [PR97573]

On Thu, Sep 30, 2021 at 03:34:24PM -0400, Jason Merrill wrote: > On 9/30/21 10:50, Marek Polacek wrote: > > This patch addresses one of my leftovers from GCC 11. C++20 introduced > > [depr.array.comp]: > > "Equality and relational comparisons between two operands of array type are > >

[PATCH] c++: Implement C++20 -Wdeprecated-array-compare [PR97573]

This patch addresses one of my leftovers from GCC 11. C++20 introduced [depr.array.comp]: "Equality and relational comparisons between two operands of array type are deprecated." so this patch adds -Wdeprecated-array-compare (enabled by default in C++20). Bootstrapped/regtested on

[PATCH v4] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Thu, Sep 23, 2021 at 02:25:16PM -0400, Jason Merrill wrote: > On 9/20/21 18:59, Marek Polacek via Gcc-patches wrote: > > +void > > +handle_ignored_attributes_option (vec *v) > > +{ > > + if (v == nullptr) > > +return; > > + > > + for (auto o

[PATCH] attribs: Allow optional second arg for attr deprecated [PR102049]

Clang implements something we don't have: __attribute__((deprecated("message", "replacement"))); which seems pretty neat so I wrote this patch to add it to gcc. It doesn't allow the optional second argument in the standard [[]] form so as not to clash with possible future standard additions. I

Re: [PATCH v3] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Mon, Sep 20, 2021 at 09:08:09PM +0200, Jakub Jelinek wrote: > On Mon, Sep 20, 2021 at 02:37:03PM -0400, Marek Polacek wrote: > > > So, wouldn't be this better specified as > > > Wno-attributes= > > > Common Joined RejectNegative > > > (not sure if RejectNegative is actually needed for an option

Re: [PATCH v2] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Mon, Sep 20, 2021 at 02:37:03PM -0400, Marek Polacek wrote: > > > +/* { dg-additional-options "-Wno-attributes=yoyodyne::attr_new" } */ > > > +/* { dg-additional-options "-Wno-attributes=c4::__attr__" } */ > > > > When writing __attr__, does that imply we won't warn about both > > c4::attr and

Re: [PATCH] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

On Mon, Sep 20, 2021 at 07:38:59PM +0200, Jakub Jelinek wrote: > On Mon, Sep 20, 2021 at 01:06:58PM -0400, Marek Polacek via Gcc-patches wrote: > > Not a review, just a few nits: > > I think it would be useful to clarify that -Wno-attributes=list doesn't > actually imply -Wno-

[PATCH] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

It is desirable for -Wattributes to warn about e.g. [[deprecate]] void g(); // typo, should warn However, -Wattributes also warns about vendor-specific attributes (that's because lookup_scoped_attribute_spec -> find_attribute_namespace finds nothing), which, with -Werror, causes grief. We don't

Re: [PATCH RFA] tree: Change error_operand_p to an inline function

On Thu, Sep 02, 2021 at 10:41:52AM -0400, Jason Merrill via Gcc-patches wrote: > I've thought for a while that many of the macros in tree.h and such should > become inline functions. This one in particular was confusing Coverity; the > null check in the macro made it think that all code guarded

[PATCH] c++: Fix ICE with nullptr comparison (GCC 11) [PR101592]

On trunk, PR101592 was fixed by r12-2537, but that change shouldn't be backported to GCC 11. In the PR Jakub suggested this fix, so here it is, after the usual testing. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 11? PR c++/101592 gcc/ChangeLog: * fold-const.c

[pushed] c++: Add test for fixed PR [PR101592]

Fixed by my c++/99701 patch. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/101592 gcc/testsuite/ChangeLog: * g++.dg/warn/Wlogical-op-3.C: New test. --- gcc/testsuite/g++.dg/warn/Wlogical-op-3.C | 12 1 file changed, 12 insertions(+) create mode 100644

Re: [pushed] c++: preserve location through constexpr

On Mon, Aug 30, 2021 at 05:25:01PM -0400, Jason Merrill via Gcc-patches wrote: > While working on the patch for PR101460, I noticed that we were losing the > expression location when folding class prvalue expressions. The final patch > doesn't fold class prvalues, but this still seems a

Re: [PATCH] c++: aggregate CTAD and brace elision [PR101344]

On Mon, Aug 16, 2021 at 03:06:08PM -0400, Patrick Palka via Gcc-patches wrote: > During aggregate CTAD, collect_ctor_idx_types always recurses into a > sub-CONSTRUCTOR, regardless of whether the corresponding pair of braces > was elided in the original initializer. This causes us to reject some >

Re: [PATCH v2] c++: Reject ordered comparison of null pointers [PR99701]

Ping for the non-libstdc++ parts. On Mon, Jul 19, 2021 at 02:46:22PM -0400, Marek Polacek wrote: > On Sat, Jul 17, 2021 at 02:50:28PM -0700, Jason Merrill wrote: > > On 7/16/21 6:34 PM, Jakub Jelinek wrote: > > > On Fri, Jul 16, 2021 at 05:36:13PM -0400, Marek Polacek via Gcc-pa

[PATCH] include: Fix -Wundef warnings in ansidecl.h

This quashes -Wundef warnings in ansidecl.h when compiled in C or C++. In C, __cpp_constexpr and __cplusplus aren't defined so we evaluate them to 0; conversely, __STDC_VERSION__ is not defined in C++. This has caused grief when -Wundef is used with -Werror. I've also tested -traditional-cpp.

Re: [PATCH v2] c++: Reject ordered comparison of null pointers [PR99701]

On Sat, Jul 17, 2021 at 02:50:28PM -0700, Jason Merrill wrote: > On 7/16/21 6:34 PM, Jakub Jelinek wrote: > > On Fri, Jul 16, 2021 at 05:36:13PM -0400, Marek Polacek via Gcc-patches > > wrote: > > > When implementing DR 1512 in r11-467 I neglected to reject ordered >

[pushed] c++: Add test for DR 2126

Tested x86_64-pc-linux-gnu, applying to trunk. DR 2126 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-temp2.C: New test. --- gcc/testsuite/g++.dg/cpp0x/constexpr-temp2.C | 6 ++ 1 file changed, 6 insertions(+) create mode 100644

[PATCH] c++: Reject ordered comparison of null pointers [PR99701]

When implementing DR 1512 in r11-467 I neglected to reject ordered comparison of two null pointers, like nullptr < nullptr. This patch fixes that omission. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? DR 1512 PR c++/99701 gcc/cp/ChangeLog: *

Re: [PATCH] c++: Allow constexpr references to non-static vars [PR100976]

On Fri, Jul 16, 2021 at 12:53:05PM -0400, Jason Merrill wrote: > On 7/15/21 5:14 PM, Marek Polacek wrote: > > The combination of DR 2481 and DR 2126 should allow us to do > > > >void f() > >{ > > constexpr const int = 42; > > static_assert(r == 42); > >} > > > > because

[PATCH] c++: Don't hide narrowing errors in system headers

Jonathan pointed me at this issue where constexpr unsigned f() { constexpr int n = -1; return unsigned{n}; } is accepted in system headers, despite the narrowing conversion from a constant. I suspect that whereas narrowing warnings should be disabled, ill-formed narrowing of constants should

[PATCH] c++: Allow constexpr references to non-static vars [PR100976]

The combination of DR 2481 and DR 2126 should allow us to do void f() { constexpr const int = 42; static_assert(r == 42); } because [expr.const]/4.7 now says that "a temporary object of non-volatile const-qualified literal type whose lifetime is extended to that of a variable that

Re: [PATCH] c++: constexpr array reference and value-initialization [PR101371]

On Wed, Jul 14, 2021 at 12:15:48AM -0400, Jason Merrill wrote: > On 7/13/21 8:15 PM, Marek Polacek wrote: > > This PR gave me a hard time: I saw multiple issues starting with > > different revisions. But ultimately the root cause seems to be > > the following, and the attached patch fixes all

[PATCH] c++: constexpr array reference and value-initialization [PR101371]

This PR gave me a hard time: I saw multiple issues starting with different revisions. But ultimately the root cause seems to be the following, and the attached patch fixes all issues I've found here. In cxx_eval_array_reference we create a new constexpr context for the CP_AGGREGATE_TYPE_P case,

Re: [PATCH] c++: permit deduction guides at class scope [PR79501]

On Fri, Jul 09, 2021 at 04:18:34PM -0400, Patrick Palka via Gcc-patches wrote: > > > > --- a/gcc/cp/name-lookup.c > > > > +++ b/gcc/cp/name-lookup.c > > > > @@ -7110,9 +7110,14 @@ lookup_qualified_name (tree scope, tree name, > > > > LOOK_want want, bool complain) > > > > else if (cxx_dialect

Re: [PATCH v2] c++: Fix noexcept with unevaluated operand [PR101087]

On Thu, Jul 08, 2021 at 05:34:24PM -0400, Jason Merrill wrote: > On 7/8/21 4:26 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > OK for trunk and 11, at least. I lean toward putting it on older release > branches as well, but it doesn't seem urgent.

Re: [PATCH v2] c++: Fix noexcept with unevaluated operand [PR101087]

On Thu, Jul 08, 2021 at 09:35:02AM -0400, Marek Polacek wrote: > On Thu, Jul 08, 2021 at 09:30:27AM -0400, Jason Merrill wrote: > > On 7/7/21 9:40 PM, Marek Polacek wrote: > > > It sounds plausible that this assert > > > > > >int f(); > > >static_assert(noexcept(sizeof(f(; > > > > >

Re: [PATCH] c++: Fix noexcept with unevaluated operand [PR101087]

On Thu, Jul 08, 2021 at 09:30:27AM -0400, Jason Merrill wrote: > On 7/7/21 9:40 PM, Marek Polacek wrote: > > It sounds plausible that this assert > > > >int f(); > >static_assert(noexcept(sizeof(f(; > > > > should pass: sizeof produces a std::size_t and its operand is not > >

Re: PING 2 [PATCH] correct handling of variable offset minus constant in -Warray-bounds (PR 100137)

On Wed, Jul 07, 2021 at 02:38:11PM -0600, Martin Sebor via Gcc-patches wrote: > On 7/7/21 1:38 AM, Richard Biener wrote: > > On Tue, Jul 6, 2021 at 5:47 PM Martin Sebor via Gcc-patches > > wrote: > > > > > > Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573349.html > > > > + if

[PATCH] c++: Fix noexcept with unevaluated operand [PR101087]

It sounds plausible that this assert int f(); static_assert(noexcept(sizeof(f(; should pass: sizeof produces a std::size_t and its operand is not evaluated, so it can't throw. noexcept should only evaluate to false for potentially evaluated operands. Therefore I think that

Re: [PATCH] c++: DR2397 - auto specifier for * and & to arrays [PR100975]

On Tue, Jun 29, 2021 at 03:50:27PM -0400, Jason Merrill wrote: > On 6/29/21 3:25 PM, Marek Polacek wrote: > > --- a/gcc/testsuite/g++.dg/cpp0x/auto3.C > > +++ b/gcc/testsuite/g++.dg/cpp0x/auto3.C > > @@ -10,7 +10,7 @@ auto x; // { dg-error "auto" } > > auto i = 42, j =

[PATCH] c++: DR2397 - auto specifier for * and & to arrays [PR100975]

This patch implements DR2397, which removes the restriction in [dcl.array]p4 that the array element type may not be a placeholder type. We don't need to worry about decltype(auto) here, so this allows code like int a[3]; auto (*p)[3] = auto ()[3] = a; However, note that auto (&)[2] =

[wwwdocs] Update C++ DR table

It's been a minute since I've updated our C++ DR table, so this patch adds news DRs. I've also written a script that check each DR's status against the upstream document. That revealed that many entries in our table were out of sync, so I've gone through all of them and fixed them. I've also

Re: [PATCH v2] c++: Failure to delay noexcept parsing with ptr-operator [PR100752]

On Thu, Jun 10, 2021 at 10:31:33PM -0400, Jason Merrill wrote: > On 6/10/21 5:19 PM, Marek Polacek wrote: > > On Thu, Jun 10, 2021 at 03:09:29PM -0400, Jason Merrill wrote: > > > On 6/8/21 8:25 PM, Marek Polacek wrote: > > > > We weren't passing 'flags' to the recursive call to

Re: [PATCH] c: Fix C cast error-recovery [PR101171]

On Thu, Jun 24, 2021 at 12:11:23PM +0200, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs during error-recovery, as build_c_cast calls > note_integer_operands on error_mark_node and that wraps it into > C_MAYBE_CONST_EXPR which is unexpected and causes ICE later on. > Seems most other

Re: [PATCH] c: Fix up c_parser_has_attribute_expression [PR101176]

On Thu, Jun 24, 2021 at 12:20:56PM +0200, Jakub Jelinek wrote: > Hi! > > This function keeps src_range member of the result uninitialized, which at > least under valgrind can show up later when those uninitialized location_t's > can make it into the IL or location_t hash tables. > > Fixed

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