Re: [PATCH] c++: ICE with noexcept and canonical types [PR101715]

On Sat, Jan 15, 2022 at 09:24:05AM -0500, Patrick Palka wrote: > On Fri, 14 Jan 2022, Marek Polacek via Gcc-patches wrote: > > > This is a "canonical types differ for identical types" ICE, which started > > with r11-4682. It's a bit tricky to explain. Consid

[PATCH] preprocessor: -Wbidi-chars and UCNs [PR104030]

Stephan Bergmann reported that our -Wbidi-chars breaks the build of LibreOffice because we warn about UCNs even when their usage is correct: LibreOffice constructs strings piecewise, as in: aText = u"\u202D" + aText; and warning about that is overzealous. Since no editor (AFAIK) interprets UCN

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

This was fixed by r12-6025 and is sufficiently different from noexcept71.C that I think we should add it. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/102338 gcc/testsuite/ChangeLog: * g++.dg/cpp1y/noexcept2.C: New test. --- gcc/testsuite/g++.dg/cpp1y/noexcept2.C | 20

[PATCH v2] c++: ICE with noexcept and canonical types [PR101715]

On Thu, Jan 20, 2022 at 03:23:24PM -0500, Jason Merrill wrote: > On 1/18/22 11:05, Marek Polacek wrote: > > On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote: > > > On 1/14/22 19:22, Marek Polacek wrote: > > > > This is a "canonical types differ for identical types" ICE, which > > > >

[PATCH v3] c++: ICE with noexcept and canonical types [PR101715]

On Fri, Jan 21, 2022 at 09:27:17AM -0500, Jason Merrill wrote: > On 1/20/22 20:03, Marek Polacek wrote: > > @@ -2815,12 +2816,23 @@ fixup_deferred_exception_variants (tree type, tree > > raises) > > cp_cv_quals var_quals = TYPE_QUALS (variant); > > cp_ref_qualifier rqual = type_mem

Re: [PATCH] c++: Fix non-portable default argument of make_auto_1 [PR104197]

On Mon, Jan 24, 2022 at 10:27:40AM -0500, Patrick Palka via Gcc-patches wrote: > Avoid using the macro current_template_depth, which expands to an > expression in terms of __FUNCTION__, within the signature of a function. > Clang warns about this and MSVC rejects it. > > Bootstrapped and regtested

[PATCH v2] preprocessor: -Wbidi-chars and UCNs [PR104030]

Here's an updated version of the patch which uses EnumSet (great to have it, thanks Jakub!) rather than hardcoding strings. With this patch we accept -Wbidi-chars=none,ucn as well as -Wbidi-chars=ucn. I think that's OK. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Stepha

[PATCH] warn-access: Prevent -Wuse-after-free on ARM [PR104213]

Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors return, as mandated by the EABI. To be entirely correct, it only requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel like changing that now and possibly running into issues later on. This patch uses suppress_w

Re: [PATCH] warn-access: Prevent -Wuse-after-free on ARM [PR104213]

On Tue, Jan 25, 2022 at 05:35:20PM -0700, Martin Sebor wrote: > On 1/25/22 16:33, Marek Polacek via Gcc-patches wrote: > > Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors > > return, as mandated by the EABI. To be entirely correct, it only > >

[PATCH v2] warn-access: Prevent -Wuse-after-free on ARM [PR104213]

On Wed, Jan 26, 2022 at 09:39:46AM -0700, Martin Sebor wrote: > On 1/26/22 08:24, Jason Merrill via Gcc-patches wrote: > > On 1/25/22 18:33, Marek Polacek wrote: > > > Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors > > > return, as mandated by the EABI.  To be entirely correc

[PATCH] c++: new-expr of array of deduced class tmpl [PR101988]

In r12-1933 I attempted to implement DR2397 aka allowing int a[3]; auto (&r)[3] = a; by removing the type_uses_auto check in create_array_type_for_decl. That may have gone too far, because it also allows arrays of CLASS_PLACEHOLDER_TEMPLATE and it looks like [dcl.type.class.deduct] prohibits

[PATCH] c++: ICE with auto[] and VLA [PR102414]

Here we ICE in unify_array_domain when we're trying to deduce the type of an array, as in auto(*p)[i] = (int(*)[i])0; but unify_array_domain doesn't arbitrarily complex bounds. Another test is, e.g., auto (*b)[0/0] = &a; where the type of the array is <<< Unknown tree: template_type_par

Re: [PATCH v2] preprocessor: -Wbidi-chars and UCNs [PR104030]

On Fri, Jan 28, 2022 at 02:53:16PM +0100, Martin Liška wrote: > On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote: > > |@@ -7820,6 +7820,10 @@ bidi contexts. @option{-Wbidi-chars=none} turns the > > warning off. @option{-Wbidi-chars=any} warns about any use of bidirection

Re: [PATCH v2] preprocessor: -Wbidi-chars and UCNs [PR104030]

On Fri, Jan 28, 2022 at 04:08:18PM +0100, Martin Liška wrote: > On 1/28/22 15:59, Marek Polacek wrote: > > On Fri, Jan 28, 2022 at 02:53:16PM +0100, Martin Liška wrote: > > > On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote: > > > > |@@ -7820,6 +7820,10 @@ bidi

[PATCH v2] c++: ICE with auto[] and VLA [PR102414]

On Thu, Jan 27, 2022 at 10:17:00PM -0500, Jason Merrill wrote: > On 1/27/22 20:02, Marek Polacek wrote: > > @@ -11159,8 +11159,16 @@ create_array_type_for_decl (tree name, tree type, > > tree size, location_t loc) > > /* Figure out the index type for the array. */ > > if (size) > > -i

Re: [PATCH v2] preprocessor: -Wbidi-chars and UCNs [PR104030]

in Liška wrote: > > > > > On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote: > > > > > > |@@ -7820,6 +7820,10 @@ bidi contexts. @option{-Wbidi-chars=none} > > > > > > turns the warning off. @option{-Wbidi-chars=any} warns about an

[PATCH] c++: Reject union std::initializer_list [PR102434]

Weird things are going to happen if you define your std::initializer_list as a union. In this case, we crash in output_constructor_regular_field. Let's not allow such a definition in the first place. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/102434 gcc/cp/Chan

Re: [PATCH] Speed up fixincludes.

On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote: > On 2/3/22 19:44, Andreas Schwab wrote: > > On Feb 03 2022, Martin Liška wrote: > > > > > +cd $LIB > > > +echo "$all_dirs" | xargs mkdir -p > > > +cd .. > > > + > > > > $LIB always contains slashes. > > > > And what is the problem?

Re: [PATCH] Speed up fixincludes.

On Fri, Feb 04, 2022 at 10:26:07AM +0100, Martin Liška wrote: > On 2/3/22 22:51, Jakub Jelinek wrote: > > On Thu, Feb 03, 2022 at 04:29:39PM -0500, Marek Polacek wrote: > > > On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote: > > > > On 2/3/22 19:44, Andreas Schwab wrote: > > > > > On Fe

[PATCH] configure: Implement --enable-host-pie

This patch implements the --enable-host-pie configure option which makes the compiler executables PIE. This can be used to enhance protection against ROP attacks, and can be viewed as part of a wider trend to harden binaries. It is similar to the option --enable-host-shared, except that --e-h-s w

[PATCH] configure: Implement --enable-host-bind-now

As promised in the --enable-host-pie patch, this patch adds another configure option, --enable-host-bind-now, which adds -z now when linking the compiler executables in order to extend hardening. BIND_NOW with RELRO allows the GOT to be marked RO; this prevents GOT modification attacks. This opti

[PATCH] c++: ->template and implicit typedef [PR104608]

Here we have a forward declaration of Parameter for which we create an implicit typedef, which is a TYPE_DECL. Then, when looking it up at template definition time, cp_parser_template_id gets (since r12-6754) this TYPE_DECL which it can't handle. This patch defers lookup for implicit typedefs, a

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

Fixed with r10-1280. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/70077 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept76.C: New test. --- gcc/testsuite/g++.dg/cpp0x/noexcept76.C | 17 + 1 file changed, 17 insertions(+) create mode 100644 gcc/testsuit

[pushed] c++: Add new test [PR79493]

A nice side effect of r12-1822 was improving the diagnostic we emit for the following test. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/79493 gcc/testsuite/ChangeLog: * g++.dg/diagnostic/undeclared1.C: New test. --- gcc/testsuite/g++.dg/diagnostic/undeclared1.C | 7 ++

[PATCH v2] configure: Implement --enable-host-pie

On Thu, Feb 10, 2022 at 09:10:17PM +, Joseph Myers wrote: > Some general observations: Thanks for the comment and sorry for the delay (I was on vacation). > * There are various toplevel GCC subdirectories that are built for the > host (possibly in addition to the target in some cases) but a

[PATCH] c++: ICE with attribute on enumerator [PR104667]

When processing a template, the enumerators we build don't have a type yet. But is_late_template_attribute is not prepared to see a _DECL without a type, so we crash on enum tree_code code = TREE_CODE (type); (I found that we don't give the "is deprecated" warning for the enumerator 'f' in the

[PATCH] c++: Lost deprecated/unavailable attr in class tmpl [PR104682]

[ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose it. ] When looking into the other PR I noticed that we fail to give a warning for a deprecated enumerator when the enum is in a class template. This only happens when the attribute doesn't have an argument. The reason is t

Re: [PATCH] c++: Lost deprecated/unavailable attr in class tmpl [PR104682]

On Mon, Feb 28, 2022 at 12:13:36PM -0400, Jason Merrill wrote: > On 2/25/22 17:59, Marek Polacek wrote: > > [ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose > > it. ] > > > > When looking into the other PR I noticed that we fail to give a warning > > for a deprecated enum

Re: [PATCH] c++: ICE with attribute on enumerator [PR104667]

On Mon, Feb 28, 2022 at 12:16:47PM -0400, Jason Merrill wrote: > On 2/25/22 17:59, Marek Polacek wrote: > > When processing a template, the enumerators we build don't have a type > > yet. But is_late_template_attribute is not prepared to see a _DECL > > without a type, so we crash on > > > >e

Re: [PATCH] c++: Lost deprecated/unavailable attr in class tmpl [PR104682]

On Mon, Feb 28, 2022 at 04:30:01PM +, Iain Sandoe wrote: > > > > On 28 Feb 2022, at 16:13, Jason Merrill wrote: > > > > On 2/25/22 17:59, Marek Polacek wrote: > >> [ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose > >> it. ] > >> When looking into the other PR I not

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 IN

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

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

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

[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: * g++.dg/cpp0x/lambda/lambda

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

[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. Se

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

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

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 ref

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

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

[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. --- gcc/testsuite/g++.dg/warn/Waddress-5.

[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 b/

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

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

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

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

[PATCH] c++: ICE with auto(0) in requires-expression [PR103408]

Here we ICE on int f() requires (auto(0)); in do_auto_deduction when handling the auto: we're in a non-templated requires-expression which are parsed under processing_template_decl == 1 and empty current_template_parms, so 'current_template_args ()' will crash. This code is invalid as per "C++

[PATCH] c++: ICE with unnamed tparm and concept [PR103408]

Here we crash when issuing the "constraint C has type T, not bool" error, because pp_cxx_parameter_mapping wasn't prepared to see an anonymous template parameter. With this patch we print error: constraint 'auto() [with = 0]' has type '', not 'bool' The "" is what this patch adds. Bootstrappe

[PATCH] c++: Fix for decltype(auto) and parenthesized expr [PR103403]

In r11-4758, I tried to fix this problem: int &&i = 0; decltype(auto) j = i; // should behave like int &&j = i; error wherein do_auto_deduction was getting confused with a REFERENCE_REF_P and it didn't realize its operand was a name, not an expression, and deduced the wrong type. Unfortunate

[PATCH] c++: Fix bogus error with __integer_pack [PR94490]

Here we issue a bogus: error: '(0 ? fake_tuple_size_v : fake_tuple_size_v)' is not a constant expression because cxx_constant_value in expand_integer_pack gets *(0 ? VIEW_CONVERT_EXPR(fake_tuple_size_v) : VIEW_CONVERT_EXPR(fake_tuple_size_v)) which is a REFERENCE_REF_P and we evaluate its oper

[PATCH v2] c++: ICE with auto(0) in requires-expression [PR103408]

On Wed, Dec 01, 2021 at 12:17:47PM -0500, Patrick Palka wrote: > On Wed, Dec 1, 2021 at 10:26 AM Marek Polacek via Gcc-patches > wrote: > > > > Here we ICE on > > > > int f() requires (auto(0)); > > > > in do_auto_deduction when handling the a

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

On Wed, Dec 01, 2021 at 11:24:58PM -0500, Jason Merrill wrote: > On 12/1/21 10:16, Marek Polacek wrote: > > 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

[PATCH v2] c++: Fix for decltype(auto) and parenthesized expr [PR103403]

On Wed, Dec 01, 2021 at 11:16:27PM -0500, Jason Merrill wrote: > On 12/1/21 10:16, Marek Polacek wrote: > > In r11-4758, I tried to fix this problem: > > > >int &&i = 0; > >decltype(auto) j = i; // should behave like int &&j = i; error > > > > wherein do_auto_deduction was getting confuse

Re: [PATCH] libcpp: Fix up handling of deferred pragmas [PR102432]

On Fri, Dec 03, 2021 at 11:27:27AM +0100, Jakub Jelinek wrote: > Hi! > > The https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557903.html > change broke the following testcases. The problem is when a pragma > namespace allows expansion (i.e. p->is_nspace && p->allow_expansion), > e.g. the

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

On Thu, Dec 02, 2021 at 12:56:38PM -0500, Jason Merrill wrote: > On 12/2/21 10:27, Marek Polacek wrote: > > On Wed, Dec 01, 2021 at 11:24:58PM -0500, Jason Merrill wrote: > > > On 12/1/21 10:16, Marek Polacek wrote: > > > > In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid, > >

[PATCH] c++: Fix for decltype and bit-fields [PR95009]

Here, decltype deduces the wrong type for certain expressions involving bit-fields. Unlike in C, in C++ bit-field width is explicitly not part of the type, so I think decltype should never deduce to 'int:N'. The problem isn't that we're not calling unlowered_expr_type--we are--it's that is_bitfie

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

This was fixed by r11-86. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/93614 gcc/testsuite/ChangeLog: * g++.dg/template/lookup18.C: New test. --- gcc/testsuite/g++.dg/template/lookup18.C | 17 + 1 file changed, 17 insertions(+) create mode 100644 gcc/t

Re: [PATCH] Fix C++/93809 and C++/83469: typenames and unions

On Tue, Dec 07, 2021 at 09:59:42AM -0800, apinski--- via Gcc-patches wrote: > From: Andrew Pinski > > There are a few issues here with typenames and unions (and even struct > keywords with unions). First in cp_parser_check_class_key, > we need to allow typenames to name union types and union key

[pushed] c++: Fix decltype-bitfield1.C on i?86

This test was failing on i?86 because of: warning: width of 'A::l' exceeds its type so change the type to 'long long' and make the test run only on arches where sizeof(long long) == 8 to avoid failing like this again. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog:

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

On Mon, Dec 06, 2021 at 04:44:06PM -0500, Jason Merrill wrote: > Please also make this change to cp_parser_sizeof_operand, and add tests > involving sizeof/alignof in array bounds. OK with that change. Turns out we reject sizeof(auto(4)) because cp_parser_type_id_1 errors "invalid use of auto".

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

On Wed, Dec 08, 2021 at 09:15:05AM -0500, Jason Merrill wrote: > On 12/7/21 19:25, Marek Polacek wrote: > > On Mon, Dec 06, 2021 at 04:44:06PM -0500, Jason Merrill wrote: > > > Please also make this change to cp_parser_sizeof_operand, and add tests > > > involving sizeof/alignof in array bounds. O

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

On Wed, Dec 08, 2021 at 03:09:00PM -0500, Jason Merrill wrote: > On 12/8/21 13:32, Marek Polacek wrote: > > On Wed, Dec 08, 2021 at 09:15:05AM -0500, Jason Merrill wrote: > > > On 12/7/21 19:25, Marek Polacek wrote: > > > > On Mon, Dec 06, 2021 at 04:44:06PM -0500, Jason Merrill wrote: > > > > > Pl

Re: [PATCH] c++: remove COMPOUND_EXPR_OVERLOADED flag

On Fri, Dec 10, 2021 at 10:48:00AM -0500, Patrick Palka via Gcc-patches wrote: > This flag is never set because non-dependent COMPOUND_EXPRs are fully > resolved into a CALL_EXPR at template definition time (in > build_x_compound_expr) ever since r6-5772. > > Bootstrapped and regtested on x86_64-p

[pushed] c++: Add test for C++23 auto(x)

I was curious if our auto(x) works in contexts like bit-field width and similar. It appears that it does. Might be worth adding a test for it. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: * g++.dg/cpp23/auto-fncast10.C: New test. --- gcc/testsuite/g++.dg/cpp

[PATCH] c++: Allow constexpr decltype(auto) [PR102229]

My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says "If the placeholder-type-specifier is of the form type-constraint[opt] decltype(auto), T shall be the placeholder alone." But this made us reject 'constexpr decltype(auto)', which, after clarification from CWG, should be valid.

[PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote: > On 10/11/22 16:00, Marek Polacek wrote: > > Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr > > while processing the default argument in this test. > > Hmm, why are we calling cxx_eval_vec_init during parsing of

Re: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote: > On 10/12/22 12:27, Marek Polacek wrote: > > On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote: > > > On 10/11/22 16:00, Marek Polacek wrote: > > > > Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr > >

Re: [PATCH] c++: Implement excess precision support for C++ [PR107097, PR323]

On Tue, Oct 11, 2022 at 03:33:23PM +0200, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following patch implements excess precision support for C++. > Like for C, it uses EXCESS_PRECISION_EXPR tree to say that its operand > is evaluated in excess precision and what the semantic type of the >

Re: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On Wed, Oct 12, 2022 at 01:12:57PM -0400, Marek Polacek wrote: > On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote: > > On 10/12/22 12:27, Marek Polacek wrote: > > > On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote: > > > > On 10/11/22 16:00, Marek Polacek wrote: > > > > >

[wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

As I promised in , I'd like to update our GCC 13 porting_to.html with the following note. Does this look OK to commit? Thanks, diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html index 84a00f21..243ed29d 1

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, Oct 12, 2022 at 09:50:36PM +0100, Jonathan Wakely wrote: > On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > > > As I promised in > > , > > I'd like to update our GCC 13 porting_to.html with the following note. > > >

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, Oct 12, 2022 at 11:38:01PM +0100, Jonathan Wakely wrote: > On Wed, 12 Oct 2022 at 23:24, Marek Polacek wrote: > > > > On Wed, Oct 12, 2022 at 09:50:36PM +0100, Jonathan Wakely wrote: > > > On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > > > > > > > As I promised in > > > >

Re: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On Wed, Oct 12, 2022 at 02:23:40PM -0400, Marek Polacek wrote: > On Wed, Oct 12, 2022 at 01:12:57PM -0400, Marek Polacek wrote: > > On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote: > > > On 10/12/22 12:27, Marek Polacek wrote: > > > > On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Me

[PATCH] c++: Mitigate -Wuseless-cast with classes [PR85043]

-Wuseless-cast (not part of -Wall/-Wextra) warns here: struct S { }; void g (S&&); void f (S&& arg) { g (S(arg)); // warning: useless cast to type 'struct S' } which is wrong: the code will not compile without the cast because "arg" is an lvalue which cannot bind to S&&. I'd like t

[PATCH v2] c++: Mitigate -Wuseless-cast with classes [PR85043]

On Wed, Oct 19, 2022 at 09:27:27AM -0400, Jason Merrill wrote: > On 10/18/22 13:38, Marek Polacek wrote: > > -Wuseless-cast (not part of -Wall/-Wextra) warns here: > > > >struct S { }; > >void g (S&&); > >void f (S&& arg) > >{ > > g (S(arg)); // warning: useless cast to type '

Re: [PATCH v2] c++: Mitigate -Wuseless-cast with classes [PR85043]

On Wed, Oct 19, 2022 at 02:37:23PM -0400, Jason Merrill wrote: > On 10/19/22 12:38, Marek Polacek wrote: > > On Wed, Oct 19, 2022 at 09:27:27AM -0400, Jason Merrill wrote: > > > On 10/18/22 13:38, Marek Polacek wrote: > > > > -Wuseless-cast (not part of -Wall/-Wextra) warns here: > > > > > > > >

[PATCH] c++: Implement -Wdangling-reference [PR106393]

This patch implements a new experimental warning (enabled by -Wextra) to detect references bound to temporaries whose lifetime has ended. The primary motivation is the Note in : Capturing the result of std::max by reference produces a dangling re

[PATCH] c++: ICE with invalid structured bindings [PR107276]

This test ICEs in C++23 because we reach the new code in do_auto_deduction: 30468 if (cxx_dialect >= cxx23 30469 && context == adc_return_type 30470 && (!AUTO_IS_DECLTYPE (auto_node) 30471 || !unparenthesized_id_or_class_member_access_p (init)) 30472 && (r = treat_lva

[PATCH v2] c++: ICE with invalid structured bindings [PR107276]

On Mon, Oct 24, 2022 at 10:31:50AM -0400, Jason Merrill wrote: > On 10/21/22 19:29, Marek Polacek wrote: > > This test ICEs in C++23 because we reach the new code in do_auto_deduction: > > > > 30468 if (cxx_dialect >= cxx23 > > 30469 && context == adc_return_type > > 30470 && (!AUTO_

Re: [PATCH] c++: Implement -Wdangling-reference [PR106393]

On Tue, Oct 25, 2022 at 12:34:50PM +0100, Jonathan Wakely wrote: > On Mon, 24 Oct 2022 at 18:30, Jason Merrill wrote: > > > > On 10/21/22 19:28, Marek Polacek wrote: > > > When testing a previous version of the patch, there were many FAILs in > > > libstdc++'s 22_locale/; all of them because the wa

[PATCH v2] c++: Implement -Wdangling-reference [PR106393]

On Mon, Oct 24, 2022 at 01:30:42PM -0400, Jason Merrill wrote: > On 10/21/22 19:28, Marek Polacek wrote: > > This patch implements a new experimental warning (enabled by -Wextra) to > > detect references bound to temporaries whose lifetime has ended. The > > Great! > > > primary motivation is th

Re: [PATCH] c++: Implement -Wdangling-reference [PR106393]

On Tue, Oct 25, 2022 at 12:50:36PM +0100, Jonathan Wakely wrote: > On Sat, 22 Oct 2022 at 00:28, Marek Polacek wrote: > > I've run the testsuite/bootstrap with the warning enabled by default. > > There were just a few FAILs: > > * g++.dg/warn/Wdangling-pointer-2.C > > * 20_util/any/misc/any_cast.cc

Re: [PATCH] c++: Implement -Wdangling-reference [PR106393]

On Tue, Oct 25, 2022 at 11:39:31AM -0400, Jason Merrill wrote: > On 10/25/22 09:14, Marek Polacek wrote: > > On Tue, Oct 25, 2022 at 12:34:50PM +0100, Jonathan Wakely wrote: > > > On Mon, 24 Oct 2022 at 18:30, Jason Merrill wrote: > > > > > > > > On 10/21/22 19:28, Marek Polacek wrote: > > > > > W

[PATCH v3] c++: Implement -Wdangling-reference [PR106393]

On Tue, Oct 25, 2022 at 11:53:51AM -0400, Jason Merrill via Gcc-patches wrote: > On 10/25/22 11:21, Marek Polacek wrote: > > On Mon, Oct 24, 2022 at 01:30:42PM -0400, Jason Merrill wrote: > > > On 10/21/22 19:28, Marek Polacek wrote: > > > > It doesn't warn when the function in question is a member

[PATCH v4] c++: Implement -Wdangling-reference [PR106393]

On Wed, Oct 26, 2022 at 12:42:27PM -0400, Jason Merrill wrote: > On 10/26/22 12:10, Marek Polacek wrote: > > As before, I've tested this patch twice, once with -Wdangling-reference > > enabled by default, once with -Wdangling-reference enabled by -Wextra. > > The couple of FAILs I saw were true pos

[PATCH] c++: -Wdangling-reference and system headers

I got this testcase: auto f() -> std::optional; for (char c : f().value()) { } which has a dangling reference: std::optional::value returns a reference to the contained value, but here it's the f() temporary. We warn, which is great, but only with -Wsystem-headers, because the function comes

[PATCH] c++: Tweaks for -Wredundant-move [PR107363]

Two things here: 1) when we're pointing out that std::move on a constant object is redundant, don't say "in return statement" when we aren't in a return statement; 2) suppress the warning when the std::move call was dependent, because removing the std::move may not be correct for a differ

[PATCH] c++: Disable -Wignored-qualifiers for template args [PR107492]

It seems wrong to issue a -Wignored-qualifiers warning for code like: static_assert(!is_same_v); because there the qualifier matters. Likewise in template specialization: template struct S { }; template<> struct S { }; template<> struct S { }; // OK, not a redefinition I'm of the mind

[PATCH] c++: Quash -Wdangling-reference for member operator* [PR107488]

-Wdangling-reference complains here: std::vector v = ...; std::vector::const_iterator it = v.begin(); while (it != v.end()) { const int &r = *it++; // warning } because it sees a call to __gnu_cxx::__normal_iterator >::operator* which returns a reference and its argument is a TARGET_E

[PATCH] c: Implement C23 nullptr (N3042)

This patch implements the C23 nullptr literal: , which is intended to replace the problematic definition of NULL which might be either of integer type or void*. Since C++ has had nullptr for over a decade now, it was relatively easy to ju

Re: [PATCH] c++: Implement P2327R1 - De-deprecating volatile compound operations

On Mon, Aug 15, 2022 at 12:31:10PM +0200, Jakub Jelinek wrote: > Hi! > > From what I can see, this has been voted in as a DR and as it means > we warn less often than before in -std={gnu,c}++2{0,3} modes or with > -Wvolatile, I wonder if it shouldn't be backported to affected release > branches as

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

Ping. (The other std::move patches depend on this one.) (can_do_rvo_p is renamed to can_elide_copy_prvalue_p in the PR90428 patch.) On Tue, Aug 02, 2022 at 07:04:47PM -0400, Marek Polacek via Gcc-patches wrote: > In my recent patch which enhanced -Wpessimizing-move so that it warns >

[wwwdocs] Update C++ DR table from Core Language Issue TOC, Revision 109

A lot of updates this time. Pushed. commit 0a423169f0abf14b765493d7b11b790d847494e8 Author: Marek Polacek Date: Tue Aug 16 11:32:24 2022 -0400 cxx-dr-status: Update from C++ Core Language Issue TOC, Revision 109 diff --git a/htdocs/projects/cxx-dr-status.html b/htdocs/projects/cxx-dr-st

[wwwdocs] Add C++23 papers approved by WG21 at the July plenary

We have a lot of new papers to implement. I've also opened PRs for them. Pushed. commit c6f8ab1adad76d2b43f6cbdacd84202131ae1e5c Author: Marek Polacek Date: Tue Aug 16 13:39:34 2022 -0400 cxx-status: Add C++23 papers approved by WG21 at the July plenary diff --git a/htdocs/projects/cxx-

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