[PATCH v2] c++: mark TARGET_EXPRs for function arguments eliding [PR114707]

On Thu, May 23, 2024 at 04:04:13PM -0400, Jason Merrill wrote: > On 5/23/24 10:41, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Coming back to our discussion in > > <https://gcc.gnu.org/piper

[PATCH] c++: extend -Wself-move for mem-init-list [PR109396]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- We already warn for: x = std::move (x); which triggers: warning: moving 'x' of type 'int' to itself [-Wself-move] but bug 109396 reports that this doesn't work for a member-initializer-list: X() : x(std::move (x))

[PATCH] c++: mark TARGET_EXPRs for function arguments eliding [PR114707]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Coming back to our discussion in : TARGET_EXPRs that initialize a function argument are not marked TARGET_EXPR_ELIDING_P even though gimplify_arg drops such

Re: [PATCH] c++: folding non-dep enumerator from current inst [PR115139]

On Fri, May 17, 2024 at 12:05:15PM -0400, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk/14? This patch looks good to me, thanks. > -- >8 -- > > After the tsubst_copy removal r14-4796-g3e3d73ed5e85e7 GCC 14 ICEs during >

[PATCH] c++: add test for DR 2855

Tested x86_64-pc-linux-gnu, OK to add such a test? -- >8 -- Let int8_t x = 127; This DR says that while x++; invokes UB, ++x; does not. The resolution was to make the first one valid. The following test verifies that we don't report any errors in a constexpr context. DR

[PATCH v2] c++: DR 569, DR 1693: fun with semicolons [PR113760]

On Thu, May 09, 2024 at 12:44:52PM -0400, Jason Merrill wrote: > On 5/9/24 12:16, Marek Polacek wrote: > > +static void > > +maybe_warn_extra_semi (location_t loc, extra_semi_kind kind) > > +{ > > + /* -Wno-extra-semi suppresses all. */ > > + if (warn

[PATCH v2] c++: ICE with reference NSDMI [PR114854]

On Thu, May 09, 2024 at 03:47:54PM -0400, Jason Merrill wrote: > On 5/9/24 12:04, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Here we crash on a cp_gimplify_expr/TARGET_EXPR assert: > > > &

[wwwdocs] cxx-dr-status: Update from C++ Core Language Issue TOC, Revision 114

Pushed. commit 06c46c88cc02e0dff5f65b41754178fb25fb939e Author: Marek Polacek Date: Mon May 13 16:09:05 2024 -0400 cxx-dr-status: Update from C++ Core Language Issue TOC, Revision 114 diff --git a/htdocs/projects/cxx-dr-status.html b/htdocs/projects/cxx-dr-status.html index a5f45359

Re: [PATCH] c++: Avoid using __array_rank as a variable name [PR115061]

On Sun, May 12, 2024 at 11:48:07PM -0700, Ken Matsui wrote: > This patch fixes a compilation error when building GCC using Clang. > Since __array_rank is used as a built-in trait name, use rank instead. I think you can go ahead and push this patch as obvious, thanks. > PR c++/115061 > >

[PATCH v2] c++: failure to suppress -Wsizeof-array-div in template [PR114983]

On Thu, May 09, 2024 at 12:51:28PM -0400, Jason Merrill wrote: > On 5/9/24 12:03, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > -Wsizeof-array-div offers a way to suppress the warning by wrapping > >

Re: [PATCH] c++: Optimize in maybe_clone_body aliases even when not at_eof [PR113208]

On Thu, May 09, 2024 at 08:20:00PM +0200, Jakub Jelinek wrote: > --- gcc/cp/decl.cc.jj 2024-05-09 10:30:54.804505130 +0200 > +++ gcc/cp/decl.cc2024-05-09 17:07:08.400110018 +0200 > @@ -19280,6 +19280,14 @@ cxx_comdat_group (tree decl) > else > break; > } > + /* If

[PATCH] c++: DR 569, DR 1693: fun with semicolons [PR113760]

In GCC 14, I submitted a minimal fix for the "extra ; warning", pushed in r14-8967. That patch mentions a more complete patch for GCC 15. This is the patch. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Prompted by c++/113760, I started looking into a bogus "extra ;"

[PATCH] c++: ICE with reference NSDMI [PR114854]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we crash on a cp_gimplify_expr/TARGET_EXPR assert: /* A TARGET_EXPR that expresses direct-initialization should have been elided by cp_gimplify_init_expr. */ gcc_checking_assert

[PATCH] c++: failure to suppress -Wsizeof-array-div in template [PR114983]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- -Wsizeof-array-div offers a way to suppress the warning by wrapping the second operand of the division in parens: sizeof (samplesBuffer) / (sizeof(unsigned char)) but this doesn't work in a template, because we fail to

ping [PATCH] contrib: add cxx-dr-table.sh

A patch to to keep up-to-date: Marek

Re: [PATCH] c++: ICE with templated sizeof(E1) / sizeof(E2) [PR114888]

On Mon, Apr 29, 2024 at 10:28:19AM -0400, Patrick Palka wrote: > Lightly tested on x86_64-pc-linux-gnu so far, does this look OK for > trunk/14.1 after bootstrap+regtest finishes? LGTM. > -- >8 -- > > We're missing a dependence check for the second operand in the > sizeof / sizeof handling. >

Re: [COMMITTED] gcc-14: Add Ada changes

On Fri, Apr 26, 2024 at 10:55:35AM +0200, Marc Poulhiès wrote: > Co-authored-by: Fernando Oleo Blanco > Co-authored-by: Piotr Trojanek > Signed-off-by: Marc Poulhiès > --- > htdocs/gcc-14/changes.html | 67 +- > 1 file changed, 66 insertions(+), 1

Re: [PATCH] wwwdocs: Add note to changes.html for __has_{feature,extension}

On Fri, Apr 26, 2024 at 11:12:54AM +0100, Alex Coplan wrote: > On 17/04/2024 11:41, Marek Polacek wrote: > > On Mon, Apr 15, 2024 at 11:13:27AM +0100, Alex Coplan wrote: > > > On 04/04/2024 11:00, Alex Coplan wrote: > > > > Hi, > > > > > >

[PATCH] testsuite: prune -freport-bug output

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? I can defer to 15 if needed, of course. -- >8 -- When the compiler defaults to -freport-bug, a few dg-ice tests fail with: Excess errors: Preprocessed source stored into /tmp/cc6hldZ0.out file, please attach this to your bugreport.

Re: [PATCH] wwwdocs: Add note to changes.html for __has_{feature,extension}

On Mon, Apr 15, 2024 at 11:13:27AM +0100, Alex Coplan wrote: > On 04/04/2024 11:00, Alex Coplan wrote: > > Hi, > > > > This adds a note to the GCC 14 release notes mentioning support for > > __has_{feature,extension} (PR60512). > > > > OK to commit? > > Ping. Is this changes.html patch OK? I

Re: [PATCH v3] c++: ICE with temporary of class type in array DMI [PR109966]

On Fri, Apr 12, 2024 at 04:15:45PM -0400, Jason Merrill wrote: > On 3/14/24 17:26, Marek Polacek wrote: > > > > In the following patch, I'm taking a different tack. I believe > > we ought to use TARGET_EXPR_ELIDING_P. The gimplify_arg bit I'm &g

[wwwdocs] Update cxx-dr-status page

A big update. I posted a script to generate new entries and check the existing separately. W3 validated. Pushed. commit 9e32f911b70a8c2303b9b60679ce337896ccffdd Author: Marek Polacek Date: Thu Apr 11 21:18:23 2024 -0400 cxx-dr-status: Update from C++ Core Language Issue TOC, Revision

[PATCH] contrib: add cxx-dr-table.sh

Use --check to check if the existing entries need to be updated. +# May need $ iconv -f iso-8859-1 -t utf-8 cwg_toc.html > cwg_toc2.html + +# Written by Marek Polacek + +AWK=/usr/bin/awk +DIFF=/usr/bin/vimdiff +SED=/usr/bin/sed + +usage() +{ + echo "Usage: $0 --check cwg_toc.html ~/src/gc

[wwwdocs] Document more C++ changes

I went through all cp/ commits in GCC 14 and documented a few interesting user-visible changes, modulo Modules. W3 validated. Pushed. commit d65752191baaa137eb6d604b802e7b9170a39752 Author: Marek Polacek Date: Wed Apr 10 17:21:09 2024 -0400 gcc-14/changes: Document more C++ changes

Re: [PATCH] c++: Fix up maybe_warn_for_constant_evaluated calls [PR114580]

On Fri, Apr 05, 2024 at 09:40:48AM +0200, Jakub Jelinek wrote: > Hi! > > When looking at maybe_warn_for_constant_evaluated for the trivial > infinite loops patch, I've noticed that it can emit weird diagnostics > for if constexpr in templates, first warn that std::is_constant_evaluted() > always

[PATCH v2] target: missing -Whardened with -fcf-protection=none [PR114606]

On Fri, Apr 05, 2024 at 08:28:08PM +0200, Jakub Jelinek wrote: > On Fri, Apr 05, 2024 at 02:22:18PM -0400, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > -Whardened warns when -fhardened couldn't enable

[PATCH] target: missing -Whardened with -fcf-protection=none [PR114606]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- -Whardened warns when -fhardened couldn't enable a hardening option because that option was disabled on the command line, e.g.: $ ./cc1plus -quiet g.C -fhardened -O2 -fstack-protector cc1plus: warning:

[pushed] c++: add fixed test [PR91079]

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- Fixed by r12-2975. PR c++/91079 DR 1881 gcc/testsuite/ChangeLog: * g++.dg/ext/is_std_layout5.C: New test. --- gcc/testsuite/g++.dg/ext/is_std_layout5.C | 13 + 1 file changed, 13 insertions(+) create

[pushed] c-family: remove dead #undef

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- The #undef was added in r0-90320-g100d537d7a7b5c but it never did anything. gcc/c-family/ChangeLog: * c-warn.cc (warn_about_parentheses): Remove an #undef. --- gcc/c-family/c-warn.cc | 1 - 1 file changed, 1 deletion(-) diff

[PATCH v2] c++: constexpr error with fn redecl in local scope [PR111132]

On Thu, Apr 04, 2024 at 05:28:22PM -0400, Jason Merrill wrote: > On 4/4/24 14:43, Marek Polacek wrote: > > On Wed, Apr 03, 2024 at 01:14:46PM -0400, Jason Merrill wrote: > > > On 4/2/24 13:52, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64

Re: [PATCH] c++: constexpr error with fn redecl in local scope [PR111132]

On Wed, Apr 03, 2024 at 01:14:46PM -0400, Jason Merrill wrote: > On 4/2/24 13:52, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > -- >8 -- > > We evaluate constexpr functions on the original, pre-generic

[PATCH] c++: constexpr error with fn redecl in local scope [PR111132]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- We evaluate constexpr functions on the original, pre-genericization bodies. That means that the function body we're evaluating will not have gone through cp_genericize_r's "Map block scope extern declarations to visible

[PATCH] c++: make __is_array return false for T[0] [PR114479]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- When we switched to using the __is_array built-in trait to implement std::is_array in r14-6623-g7fd9c349e45534, we started saying that T[0] is an array. There are various opinions as to whether that is the best answer, but it

[PATCH] c++: ICE with scoped enum in switch condition [PR114451]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- Here we ICE when gimplifying enum class Type { Pawn }; struct Piece { Type type : 4; }; void foo() { switch (Piece().type) case Type::Pawn:; } because we ended up with TYPE_PRECISION (cond) <

[pushed] c++: add fixed test [PR100557]

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- We used to hit the "Error reporting routines re-entered." ICE here but it was fixed by Patrick's r14-3809. PR c++/100557 gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr100557.C: New test. ---

[PATCH v3] c++: ICE with noexcept and local specialization, again [PR114349]

On Mon, Mar 25, 2024 at 03:40:10PM -0400, Jason Merrill wrote: > On 3/22/24 17:30, Marek Polacek wrote: > > On Thu, Mar 21, 2024 at 05:27:37PM -0400, Jason Merrill wrote: > > > On 3/21/24 17:01, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86

[PATCH] c++: broken direct-init with trailing array member [PR114439]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- can_init_array_with_p is wrongly saying that the init for 's' here: struct S { int *list = arr; int arr[]; }; struct A { A() {} S s[2]{}; }; is invalid. But as process_init_constructor_array says,

Re: [PATCH v2] c++: direct-init of an array of class type [PR59465]

On Mon, Mar 25, 2024 at 01:39:39PM +0100, Stephan Bergmann wrote: > On 3/25/24 13:07, Jakub Jelinek wrote: > > On Mon, Mar 25, 2024 at 12:36:46PM +0100, Stephan Bergmann wrote: > > > This started to break > > > > > > > $ cat test.cc > > > > struct S1 { S1(); }; > > > > struct S2 { > > > >

[PATCH v2] c++: ICE with noexcept and local specialization, again [PR114349]

On Thu, Mar 21, 2024 at 05:27:37PM -0400, Jason Merrill wrote: > On 3/21/24 17:01, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Patrick noticed that my r14-9339-gdc6c3bfb59baab patch is wrong; > >

Re: [PATCH] c++: ICE with noexcept and local specialization [PR114114]

On Fri, Mar 15, 2024 at 12:12:49PM -0400, Patrick Palka wrote: > On Fri, 15 Mar 2024, Marek Polacek wrote: > > > On Fri, Mar 15, 2024 at 10:35:07AM -0400, Patrick Palka wrote: > > > On Tue, 5 Mar 2024, Marek Polacek wrote: > > > > > > > Bootstrapped/regt

[PATCH] c++: ICE with noexcept and local specialization, again [PR114349]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Patrick noticed that my r14-9339-gdc6c3bfb59baab patch is wrong; we're dealing with a noexcept-spec there, not a noexcept-expr, so setting cp_noexcept_operand et al is incorrect. Back to the drawing board then. To fix

[PATCH v2] c++: direct-init of an array of class type [PR59465]

On Wed, Mar 20, 2024 at 09:21:02PM -0400, Jason Merrill wrote: > On 3/1/24 19:58, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? I don't > > claim that this has to go to 14 though. > > > > -- >8 -- > > ...from anoth

[pushed] testsuite: fix target for linkage-1.C

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- This test fails in C++11 due to: linkage-1.C:3:8: error: 'f' function uses 'auto' type specifier without trailing return type 3 | inline auto f() { |^~~~ linkage-1.C:3:8: note: deduced return type only available with

Re: [PATCH] c++: direct-init of an array of class type [PR59465]

Ping. Though I reckon it may be better to defer this to 15. On Fri, Mar 01, 2024 at 07:58:51PM -0500, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? I don't > claim that this has to go to 14 though. > > -- >8 -- > ...from another array in

Re: [PATCH v3] c++: ICE with temporary of class type in array DMI [PR109966]

On Thu, Mar 14, 2024 at 05:26:59PM -0400, Marek Polacek wrote: > @@ -1441,11 +1406,13 @@ static tree > replace_placeholders_for_class_temp_r (tree *tp, int *, void *data) > { >tree t = *tp; > - tree full_expr = *static_cast(data); > + auto pset = static_cast *>(dat

[PATCH v2] c++: explicit inst of template method not generated [PR110323]

On Mon, Mar 18, 2024 at 09:10:27PM -0400, Jason Merrill wrote: > On 3/15/24 13:48, Marek Polacek wrote: > > On Thu, Mar 14, 2024 at 03:39:04PM -0400, Jason Merrill wrote: > > > On 3/8/24 12:02, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86

Re: [PATCH] c++: explicit inst of template method not generated [PR110323]

On Thu, Mar 14, 2024 at 03:39:04PM -0400, Jason Merrill wrote: > On 3/8/24 12:02, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Consider > > > >constexpr int VAL = 1; > >struc

Re: [PATCH] c++: ICE with noexcept and local specialization [PR114114]

On Fri, Mar 15, 2024 at 10:35:07AM -0400, Patrick Palka wrote: > On Tue, 5 Mar 2024, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Here we ICE because we call register_local_specialization while >

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

On Tue, Mar 12, 2024 at 06:26:14PM -0400, Jason Merrill wrote: > On 3/12/24 11:56, Marek Polacek wrote: > > On Tue, Mar 12, 2024 at 09:57:14AM -0400, Jason Merrill wrote: > > > On 3/11/24 19:27, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64

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

On Tue, Mar 12, 2024 at 09:57:14AM -0400, Jason Merrill wrote: > On 3/11/24 19:27, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > -- >8 -- > > This ICE started with the fairly complicated r13-765. We crash in > &g

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

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- This ICE started with the fairly complicated r13-765. We crash in gimplify_var_or_parm_decl because a stray VAR_DECL leaked there. The problem is ultimately that potential_prvalue_result_of wasn't correctly handling arrays

[PATCH] c++: explicit inst of template method not generated [PR110323]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Consider constexpr int VAL = 1; struct foo { template void bar(typename std::conditional::type arg) { } }; template void foo::bar<1>(int arg); where we since r11-291 fail to emit the code for the explicit

[PATCH] c++: ICE with noexcept and local specialization [PR114114]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we ICE because we call register_local_specialization while local_specializations is null, so local_specializations->put (); crashes on null this. It's null since maybe_instantiate_noexcept calls push_to_top_level

[PATCH] c++: ICE with variable template and [[deprecated]] [PR110031]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- lookup_and_finish_template_variable already has and uses the complain parameter but it is not passing it down to mark_used so we got the default tf_warning_or_error, which causes various problems when

Re: [PATCH] c++: lambda capturing structured bindings [PR85889]

On Fri, Mar 01, 2024 at 07:58:24PM -0500, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 15? (Or even trunk?) > > -- >8 -- > <https://wg21.link/p1381r1> clarifies that it's OK to capture structured > bindings. > > [expr.prim.lambda.c

Re: [PATCH v5] c++: implement [[gnu::non_owning]] [PR110358]

On Mon, Mar 04, 2024 at 11:00:18AM +, Jonathan Wakely wrote: > On 01/03/24 15:38 -0500, Jason Merrill wrote: > > On 3/1/24 14:24, Marek Polacek wrote: > > > +@smallexample > > > +template > > > +[[gnu::no_dangling(std::is_reference_v)]] int foo (T& t)

[PATCH] c++: DECL_DECOMPOSITION_P cleanup

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 15? -- >8 -- DECL_DECOMPOSITION_P already checks VAR_P but we repeat the check in a lot of places. gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Don't check VAR_P before DECL_DECOMPOSITION_P. * init.cc

[PATCH] c++: direct-init of an array of class type [PR59465]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? I don't claim that this has to go to 14 though. -- >8 -- ...from another array in a mem-initializer should not be accepted. We already reject struct string {} a[1]; string x[1](a); but struct pair { string s[1];

[PATCH] c++: lambda capturing structured bindings [PR85889]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 15? (Or even trunk?) -- >8 -- clarifies that it's OK to capture structured bindings. [expr.prim.lambda.capture]/4 says "The identifier in a simple-capture shall denote a local entity" and [basic.pre]/3: "An entity

[PATCH v5] c++: implement [[gnu::non_owning]] [PR110358]

On Fri, Mar 01, 2024 at 01:19:40PM -0500, Jason Merrill wrote: > On 3/1/24 12:39, Marek Polacek wrote: > > @option{-Wdangling-reference} also warns about code like > > @smallexample > > @@ -3932,6 +3935,10 @@ struct Span @{ > > as @code{std::span}-like; that i

[PATCH v4] c++: implement [[gnu::non_owning]] [PR110358]

On Thu, Feb 29, 2024 at 07:30:02PM -0500, Jason Merrill wrote: > On 2/29/24 19:12, Marek Polacek wrote: > > On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote: > > > > > Hmm, if we're also going to allow the attribute to be applied to a > > > functio

[PATCH v3] c++: implement [[gnu::non_owning]] [PR110358]

On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote: > On 2/21/24 19:35, Marek Polacek wrote: > > On Fri, Jan 26, 2024 at 04:04:35PM -0500, Jason Merrill wrote: > > > On 1/25/24 20:37, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86

Re: [pushed] testsuite: fix Wmismatched-new-delete-8.C with -m32

On Thu, Feb 22, 2024 at 04:06:51PM -0800, Andrew Pinski wrote: > On Thu, Feb 22, 2024, 15:56 Marek Polacek wrote: > > > Tested x86_64-pc-linux-gnu, applying to trunk. > > > I backported/pushed the change to 13 branch already so please apply it > there too. Ah right. Done. Marek

[pushed] testsuite: fix Wmismatched-new-delete-8.C with -m32

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- This fixes error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter [-fpermissive] gcc/testsuite/ChangeLog: * g++.dg/warn/Wmismatched-new-delete-8.C: Use __SIZE_TYPE__. ---

Re: [PATCH] c++: -Wuninitialized when binding a ref to uninit DM [PR113987]

On Thu, Feb 22, 2024 at 08:34:45AM +, Jason Merrill wrote: > On 2/20/24 19:15, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > This PR asks that our -Wuninitialized for mem-initializers does > &g

[PATCH v2] c++: implement [[gnu::non_owning]] [PR110358]

On Fri, Jan 26, 2024 at 04:04:35PM -0500, Jason Merrill wrote: > On 1/25/24 20:37, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Since -Wdangling-reference has false positives that can't be > > pr

[PATCH] c++: -Wuninitialized when binding a ref to uninit DM [PR113987]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This PR asks that our -Wuninitialized for mem-initializers does not warn when binding a reference to an uninitialized data member. We already check !INDIRECT_TYPE_P in find_uninit_fields_r, but that won't catch binding a

[PATCH v3] c++: wrong looser excep spec for dep noexcept [PR113158]

On Fri, Feb 16, 2024 at 04:39:47PM -0500, Patrick Palka wrote: > On Fri, 16 Feb 2024, Marek Polacek wrote: > > + /* We also have to defer checking when we're in a template and couldn't > > + instantiate & evaluate the noexcept to true/false. */ > > + if

[PATCH v2] c++: wrong looser excep spec for dep noexcept [PR113158]

On Fri, Feb 16, 2024 at 03:58:02PM -0500, Jason Merrill wrote: > On 2/15/24 17:17, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > By the ??? below I mean that maybe_instantiate_noexcept could

Re: [COMMITTED] c++: Add testcase for this PR [PR97990]

On Fri, Feb 16, 2024 at 11:00:34AM -0800, Andrew Pinski wrote: > This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add > one to make sure it does not regress again. > > Committed as obvious after a quick test on the testcase. > > PR c++/97990 > > gcc/testsuite/ChangeLog: >

[PATCH v2] c++: implicit move with throw [PR113853]

On Thu, Feb 15, 2024 at 04:36:40PM -0500, Jason Merrill wrote: > On 2/15/24 10:19, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Here we have > > > >template > >

[PATCH] c++: wrong looser excep spec for dep noexcept [PR113158]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? By the ??? below I mean that maybe_instantiate_noexcept could return a tristate, and then maybe_check_overriding_exception_spec could check if (maybe_instantiate_noexcept ().is_unknown ()) return true; and we don't have to add

[PATCH] c++: wrong looser exception spec with deleted fn

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? IMHO trivial enough to go ahead now seeing as it doesn't introduce new errors. -- >8 -- I noticed we don't implement the "unless the overriding function is defined as deleted" wording added to [except.spec] via CWG 1351. DR

[PATCH] c++: implicit move with throw [PR113853]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we have template auto is_throwable(T t) -> decltype(throw t, true) { ... } where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused the wrong overload to have been chosen. Jason figured out it's because

[PATCH] c++: adjust the extra ; warning [PR113760]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- A minimal fix to quash an extra ; warning. I have a more complete patch for GCC 15. DR 1693 PR c++/113760 gcc/cp/ChangeLog: * parser.cc (cp_parser_member_declaration): Only pedwarn about an extra

Re: [PATCH] c++: DR 569, DR 1693: fun with semicolons [PR113760]

On Tue, Feb 13, 2024 at 03:41:53PM -0500, Jason Merrill wrote: > On 2/13/24 14:43, Marek Polacek wrote: > > On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote: > > > On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote: > > > > Sadly, I must adm

Re: [PATCH] c++: DR 569, DR 1693: fun with semicolons [PR113760]

On Tue, Feb 13, 2024 at 02:43:39PM -0500, Marek Polacek wrote: > On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote: > > On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote: > > > Sadly, I must admit this is looking like GCC 15 material. > > > >

Re: [PATCH] c++: DR 569, DR 1693: fun with semicolons [PR113760]

On Tue, Feb 13, 2024 at 08:38:18PM +0100, Jakub Jelinek wrote: > On Tue, Feb 13, 2024 at 02:24:11PM -0500, Marek Polacek wrote: > > Sadly, I must admit this is looking like GCC 15 material. > > If deferred for GCC 15, can't we at least do some minimal > change and just guard

[PATCH] c++: DR 569, DR 1693: fun with semicolons [PR113760]

Sadly, I must admit this is looking like GCC 15 material. Bootstrapped/regtested on x86_64-pc-linux-gnu. -- >8 -- Prompted by c++/113760, I started looking into a bogus "extra ;" warning in C++14. It quickly turned out that if I want to fix this for good, the fix will not be so small. This

Re: [PATCH] attribs: Don't canonicalize lookup_scoped_attribute_spec argument [PR113674]

On Mon, Feb 12, 2024 at 06:30:55PM +0100, Jakub Jelinek wrote: > Hi! > > The C and C++ FEs when parsing attributes already canonicalize them > (i.e. if they start with __ and end with __ substrings, we remove those). > lookup_attribute already verifies in gcc_assert that the first character > of

Re: [PATCH 2/1] c++: Also support lambdas attached to TYPE_DECLs in modules

On Sun, Feb 11, 2024 at 02:54:18PM +1100, Nathaniel Shead wrote: > Bootstrapped and regtested (so far just modules.exp and dg.exp) on > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? > > (Also I noticed I forgot to add the PR to the changelog in my last > patch, I've fixed that

[PATCH] c++: ICE with reinterpret_cast and switch [PR113545]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Jason, this is the patch you proposed for PR113545. It looks very safe so I'm posting it here so that it's not forgotten. PR c++/113545 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_switch_expr): If the

[PATCH] c++: SFINAE-unfriendly error on throwing pointer [PR112436]

Probably stage1 material but it should be safe... Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- On the heels of r14-8903, this patch adds further complain parameters so that we don't emit "invalid use of incomplete type" from inside a concept. PR c++/112436

[PATCH v4] c++: DR2237, cdtor and template-id tweaks [PR107126]

On Fri, Feb 09, 2024 at 10:20:04AM -0500, Jason Merrill wrote: > On 2/8/24 16:26, Marek Polacek wrote: > > This patch does *not* fix > > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202#c8> > > where the C++20 diagnostic is missing altogether. > > What would i

[PATCH] c++: fix ICE with __type_pack_element [PR113834]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we crash on this invalid code because we seem to infinitely recurse and end up with __type_pack_element with index that doesn't tree_fits_shwi_p which then crashes on tree_to_shwi. Thanks to Jakub for suggesting a nicer

[PATCH v3] c++: make build_throw SFINAE-friendly [PR98388]

On Fri, Feb 09, 2024 at 10:07:33AM -0500, Jason Merrill wrote: > On 2/8/24 17:20, Marek Polacek wrote: > > On Thu, Feb 08, 2024 at 04:53:45PM -0500, Jason Merrill wrote: > > > On 2/8/24 11:51, Marek Polacek wrote: > > > > On Thu, Feb 08, 2024 at 08:49:2

Re: [PATCH v2] c++: make build_throw SFINAE-friendly [PR98388]

On Thu, Feb 08, 2024 at 04:53:45PM -0500, Jason Merrill wrote: > On 2/8/24 11:51, Marek Polacek wrote: > > On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick Palka wrote: > > > On Wed, 7 Feb 2024, Marek Polacek wrote: > > > > > > > Bootstrapped/regtest

[PATCH v3] c++: DR2237, cdtor and template-id tweaks [PR107126]

On Wed, Feb 07, 2024 at 05:19:56PM -0500, Jason Merrill wrote: > On 2/5/24 22:11, Marek Polacek wrote: > > On Mon, Feb 05, 2024 at 10:14:34AM -0500, Jason Merrill wrote: > > > On 2/3/24 10:24, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86

[PATCH v2] c++: make build_throw SFINAE-friendly [PR98388]

On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick Palka wrote: > On Wed, 7 Feb 2024, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Here the problem is that we give hard errors while substituti

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

On Thu, Feb 08, 2024 at 05:07:21PM +0100, Hans-Peter Nilsson wrote: > > Date: Thu, 8 Feb 2024 10:44:31 -0500 > > From: Marek Polacek > > Cc: ja...@redhat.com, gcc-patches@gcc.gnu.org > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline >

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

On Thu, Feb 08, 2024 at 04:40:40PM +0100, Hans-Peter Nilsson wrote: > > Date: Wed, 7 Feb 2024 21:11:59 -0500 > > From: Marek Polacek > > > On Wed, Feb 07, 2024 at 04:32:57PM -0500, Jason Merrill wrote: > > > On 2/6/24 19:23, Hans-Peter Nilsson wrote: > > &

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

On Wed, Feb 07, 2024 at 04:32:57PM -0500, Jason Merrill wrote: > On 2/6/24 19:23, Hans-Peter Nilsson wrote: > > > Date: Mon, 22 Jan 2024 14:33:59 -0500 > > > From: Marek Polacek > > > > > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote:

[PATCH] c++: make build_throw SFINAE-friendly [PR98388]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here the problem is that we give hard errors while substituting template parameters during overload resolution of is_throwable which has an invalid throw in decltype. The backtrace shows that fn_type_unification ->

Re: [wwwdocs] Add 2 more C++26 core papers

On Wed, Feb 07, 2024 at 10:58:18AM +0100, Jakub Jelinek wrote: > Hi! > > cppreference has 2 more Kona papers listed and it seems eel.is/c++draft/ > has those papers incorporated. > > Ok for wwwdocs? Patch is OK. W3 validates fine too. Thanks, > diff --git a/htdocs/projects/cxx-status.html

Re: [PATCH] c++: Disallow this specifier except for parameter declarations [PR113788]

On Tue, Feb 06, 2024 at 09:37:44PM +0100, Jakub Jelinek wrote: > Hi! > > The deducing this patchset added parsing of this specifier to > cp_parser_decl_specifier_seq unconditionally, but in the C++ grammar > this[opt] only appears in the parameter-declaration non-terminal, so > rather than

[pushed] c++: add fixed test [PR94231]

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- I was suprised to find out that r14-8759 fixed this accepts-invalid. clang version 17.0.6 rejects the test as well; clang version 19.0.0git crashes for which I opened . PR

[PATCH] c++: further DR 2237 fix [PR97202]

Technically, not a regression. But it's such a simple fix for such rare code that I think we should put it in now and be done with DR 2237. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- With a redundant inline specifier like this: template struct S : Base { inline

[PATCH v2] c++: DR2237, cdtor and template-id tweaks [PR107126]

On Mon, Feb 05, 2024 at 10:14:34AM -0500, Jason Merrill wrote: > On 2/3/24 10:24, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > I'm not certain OPT_Wc__20_extensions is the best thing for something > > from [diff.cpp17];

Re: [pushed] c++: defaulted op== for incomplete class [PR107291]

On Mon, Feb 05, 2024 at 09:29:08PM -0500, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > After complaining about lack of friendship, we should not try to go on and > define the defaulted comparison operator anyway. > > PR c++/107291 > >

Re: [PATCH] c: Avoid ICE with _BitInt(N) : 0 bitfield [PR113740]

On Mon, Feb 05, 2024 at 08:57:18AM +0100, Jakub Jelinek wrote: > Hi! > > finish_struct already made sure not to call build_bitint_type for > signed _BitInt(2) : 1; > or > signed _BitInt(2) : 0; > bitfields (but instead build a zero precision integral type, > we remove it later), this patch makes

  1   2   3   4   5   6   7   8   9   10   >