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

On Fri, Jan 28, 2022 at 05:12:41PM +0100, Martin Liška wrote: > On 1/28/22 16:26, Marek Polacek wrote: > > 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, Mart

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

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

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

[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] = where the type of the array is <<< Unknown tree: template_type_parm

[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 ()[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 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 b

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

[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

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

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

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

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

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

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. Consider: &

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

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 started > > with r11-4682. It's a bit tricky to explain. Consider: > > > >

Re: PING^5 [PATCH v4 0/2] Implement indirect external access

Ping, could a global maintainer take a look at this? On Mon, Jan 03, 2022 at 07:32:25PM -0800, H.J. Lu via Gcc-patches wrote: > On Sat, Dec 11, 2021 at 10:44 AM H.J. Lu wrote: > > > > On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu wrote: > > > > > > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu wrote: > > >

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

This is a "canonical types differ for identical types" ICE, which started with r11-4682. It's a bit tricky to explain. Consider: template struct S { S bar() noexcept(T::value); // #1 S foo() noexcept(T::value); // #2 }; template S S::foo() noexcept(T::value) {} // #3 We ICE

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

On Fri, Jan 14, 2022 at 10:23:16AM +0100, Stephan Bergmann wrote: > On 30/11/2021 16:27, Marek Polacek wrote: > > I guess we were concerned with programs that generate other programs. > > Maybe UCNs should be ignored by default. There's still time to adjust > > the behavi

[wwwdocs] Update C++ DR table

A new batch of DRs. Pushed. commit ecbd709b2ecb1e3c35fa4ede09bcb7ceb443def6 Author: Marek Polacek Date: Thu Jan 6 17:06:24 2022 -0500 Update C++ DR table diff --git a/htdocs/projects/cxx-dr-status.html b/htdocs/projects/cxx-dr-status.html index e8002b27..cc2afc03 100644 --- a/htdocs

[PATCH] Avoid more -Wformat-diag warnings [PR103758]

Let's use "%, %, or %" rather than "[x|y|z]" as in the rest of our codebase. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11? PR c++/103758 gcc/c-family/ChangeLog: * c-pragma.c (handle_pragma_scalar_storage_order): Use %< %> in diagnostic messages.

[PATCH v2] c-family: Have -Wformat-diag accept "decl-specifier" [PR103758]

On Mon, Dec 20, 2021 at 09:53:25PM +0100, Jakub Jelinek wrote: > On Mon, Dec 20, 2021 at 03:21:04PM -0500, Jason Merrill via Gcc-patches wrote: > > > @@ -3215,6 +3215,14 @@ check_tokens (const token_t *tokens, unsigned > > > ntoks, > > > plural = "s"; > > > }

Re: [PATCH] c++: Avoid narrowing in make_char_string_pack

On Sat, Dec 18, 2021 at 07:43:55PM -0500, Eric Gallager wrote: > On Fri, Dec 17, 2021 at 5:59 PM Marek Polacek via Gcc-patches > wrote: > > > > This fixes > > > > gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str + > > ((sizetype

[PATCH] c-family: Have -Wformat-diag accept "decl-specifier" [PR103758]

I'm tired of seeing cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag] cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag] every time I compile cp/parser.c, which happens...a lot.

[PATCH] c++: Avoid narrowing in make_char_string_pack

This fixes gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str + ((sizetype)i)))' from 'char' to 'unsigned char' [-Wnarrowing] 4618 | unsigned char s[3] = { '\'', str[i], '\'' }; |~^ Bootstrapped/regtested on

[PATCH v4] attribs: Fix wrong error with -Wno-attribute=A::b [PR103649]

On Fri, Dec 17, 2021 at 02:33:01PM -0500, Jason Merrill wrote: > On 12/17/21 13:14, Marek Polacek wrote: > > @@ -28979,7 +28979,9 @@ cp_parser_std_attribute (cp_parser *parser, tree > > attr_ns) > > /* A GNU attribute that takes an identifier in parameter. */

[PATCH v3] attribs: Fix wrong error with -Wno-attribute=A::b [PR103649]

On Thu, Dec 16, 2021 at 08:06:43PM -0500, Jason Merrill wrote: > On 12/16/21 19:52, Marek Polacek wrote: > > --- /dev/null > > +++ b/gcc/testsuite/c-c++-common/Wno-attributes-6.c > > @@ -0,0 +1,14 @@ > > +/* PR c/103649 */ > > +/* { dg-do compile { target {

[PATCH v2] c++: Improve diagnostic for class tmpl/class redecl [PR103749]

On Thu, Dec 16, 2021 at 08:13:01PM -0500, Jason Merrill wrote: > On 12/16/21 17:36, Marek Polacek wrote: > > + if (DECL_CLASS_TEMPLATE_P (decl) > > + && !template_header_p > > + && how == TAG_how::CURRENT_ONLY) > > +{ > > + err

[PATCH] c++: Improve diagnostic for class tmpl/class redecl [PR103749]

For code like template struct bar; struct bar { int baz; }; bar var; we emit a fairly misleading and unwieldy diagnostic: ~ $ g++ -c u.cc u.cc:6:8: error: template argument required for 'struct bar' 6 | struct bar { |

[PATCH] attribs: Fix wrong error with -Wno-attribute=A::b [PR103649]

My patch to implement -Wno-attribute=A::b caused a bogus error when parsing [[foo::bar(1, 2)]]; when -Wno-attributes=foo::bar was specified on the command line, because when we create a fake foo::bar attribute and insert it into our attribute table, it is created with max_length == 0 which

[PATCH] c++: delayed noexcept in member function template [PR99980]

Some time ago I noticed that we don't properly delay parsing of noexcept for member function templates. This patch fixes that. It didn't work because even though we set CP_PARSER_FLAGS_DELAY_NOEXCEPT in cp_parser_member_declaration, member template declarations take a different path: we call

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

On Wed, Dec 15, 2021 at 04:17:37PM -0500, Jason Merrill wrote: > On 12/15/21 15:20, Marek Polacek wrote: > > On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote: > > > On 12/10/21 17:29, Marek Polacek wrote: > > > > My r11-2202 was trying to enforce [dcl.t

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

On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote: > On 12/10/21 17:29, Marek Polacek wrote: > > 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] > &g

[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

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

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

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

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 siz

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

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

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

[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

[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

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++: 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 & = 0; > >decltype(auto) j = i; // should behave like int & = i; error > > > >

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

[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

[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

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

In r11-4758, I tried to fix this problem: int & = 0; decltype(auto) j = i; // should behave like int & = 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. Unfortunately

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

[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

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

[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

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