[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; > > + /

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 det

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

d, Nov 17, 2021 at 10:06 PM will wray wrote: > > > > Thanks for the review Marek; > > I'll post the updated patch in a follow-on message and on bugzilla. > > > > On Mon, Nov 15, 2021 at 8:03 PM Marek Polacek wrote: > > > > > I also noticed the C++ FE rejects

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

[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, -Wbidi

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.

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

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

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

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_star

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

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

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

On Tue, Nov 09, 2021 at 12:12:10AM -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: > > > On 11/6/21 14:28, Marek Polacek wrote: > > > > On Sat, Nov 06, 2021 at 02:32:26AM +

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: > > <https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559162.html> > > but it didn't make it in.

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

[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 b/htdocs/projects/cxx

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

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

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

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__, doe

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_ass

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

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

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(); >

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

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

[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

used "iconv -f UTF-8 -t ASCII//TRANSLIT" to convert all quotes to ASCII ". Validated, pushed. commit 7220e26862b78df86d77a55f514d110c93d230c6 Author: Marek Polacek Date: Fri Jun 25 20:06:43 2021 -0400 cxx-dr-status.html: Add new DRs, update status of older ones diff --git a/

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

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

Re: [wwwdocs] New C++23 papers

On Tue, Jun 22, 2021 at 02:38:46PM -0400, Jason Merrill wrote: > On 6/22/21 1:14 PM, Marek Polacek wrote: > > P1847 has always been "implemented" as the paper says. > > P2186 needs a few libstdc++ changes that Jonathan already implemented. > > I figured these remova

[wwwdocs] Document new C++ features in C++23

It's time to start adding new C++ features. Pushed. commit e373348138d8d767067c0a79b3ddc6a70cbee3a4 Author: Marek Polacek Date: Tue Jun 22 13:19:37 2021 -0400 gcc-12/changes.html: Add if consteval diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index 42ded16d

[wwwdocs] New C++23 papers

P1847 has always been "implemented" as the paper says. P2186 needs a few libstdc++ changes that Jonathan already implemented. Pushed. commit 7b804041d34c344a190105e78c6058e2645bf7cb Author: Marek Polacek Date: Tue Jun 22 13:10:41 2021 -0400 cxx-status: Add more C++23 propo

Re: [PATCH v2] c++: Extend std::is_constant_evaluated in if warning [PR100995]

On Thu, Jun 10, 2021 at 10:27:44AM -0400, Jason Merrill wrote: > On 6/9/21 9:46 PM, Marek Polacek wrote: > > Jakub pointed me at > > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1938r3.html#compiler-warnings> > > which shows that our existing warning could

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

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 cp_parser_declarator > > in the ptr-operator case and as an effect, delayed parsing of noexcept > > didn

[PATCH] c++: Extend std::is_constant_evaluated in if warning [PR100995]

Jakub pointed me at which shows that our existing warning could be extended to handle more cases. This patch implements that. A minor annoyance was handling macros, in libstdc++ we have reference

<    4   5   6   7   8   9   10   11   12   13   >