[PATCH v7] c++: Move consteval folding to cp_fold_r

On Sat, Sep 16, 2023 at 04:22:44PM -0400, Jason Merrill wrote: > On 9/15/23 16:32, Marek Polacek wrote: > > On Fri, Sep 15, 2023 at 02:08:46PM -0400, Jason Merrill wrote: > > > On 9/13/23 20:02, Marek Polacek wrote: > > > > On Wed, Sep 13, 2023 at 05:57:47PM -0400, Jason Merrill wrote: > > > > >

[PATCH v6] c++: Move consteval folding to cp_fold_r

On Fri, Sep 15, 2023 at 02:08:46PM -0400, Jason Merrill wrote: > On 9/13/23 20:02, Marek Polacek wrote: > > On Wed, Sep 13, 2023 at 05:57:47PM -0400, Jason Merrill wrote: > > > On 9/13/23 16:56, Marek Polacek wrote: > > > > On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason Merrill wrote: > > > > >

Re: RFC: Introduce -fhardened to enable security-related flags

On Fri, Sep 01, 2023 at 10:09:28PM +, Qing Zhao via Gcc-patches wrote: > > > > On Aug 29, 2023, at 3:42 PM, Marek Polacek via Gcc-patches > > wrote: > > > > Improving the security of software has been a major trend in the recent > > years. Fortunately

Re: RFC: Introduce -fhardened to enable security-related flags

On Mon, Sep 04, 2023 at 11:40:34PM +0100, Richard Sandiford wrote: > Qing Zhao via Gcc-patches writes: > >> On Aug 29, 2023, at 3:42 PM, Marek Polacek via Gcc-patches > >> wrote: > >> > >> Improving the security of software has been a major trend in t

Re: RFC: Introduce -fhardened to enable security-related flags

On Wed, Aug 30, 2023 at 03:08:46PM +0200, Richard Biener wrote: > On Wed, Aug 30, 2023 at 12:51 PM Jakub Jelinek via Gcc-patches > wrote: > > > > On Tue, Aug 29, 2023 at 03:42:27PM -0400, Marek Polacek via Gcc-patches > > wrote: > > > +

Re: RFC: Introduce -fhardened to enable security-related flags

On Wed, Aug 30, 2023 at 12:50:40PM +0200, Jakub Jelinek wrote: > On Tue, Aug 29, 2023 at 03:42:27PM -0400, Marek Polacek via Gcc-patches wrote: > > + if (UNLIKELY (flag_hardened) > > + && (opt->code == OPT_D || opt->code == OPT_U)) > > +

Re: RFC: Introduce -fhardened to enable security-related flags

On Wed, Aug 30, 2023 at 05:06:57PM +0800, Xi Ruoyao via Gcc-patches wrote: > On Tue, 2023-08-29 at 15:42 -0400, Marek Polacek via Gcc-patches wrote: > > + if (UNLIKELY (flag_hardened) > > + && (opt->code == O

Re: RFC: Introduce -fhardened to enable security-related flags

On Wed, Aug 30, 2023 at 10:46:14AM +0200, Martin Uecker wrote: > > Improving the security of software has been a major trend in the recent > > years. Fortunately, GCC offers a wide variety of flags that enable extra > > hardening. These flags aren't enabled by default, though. And since > >

[PATCH] gcc: Introduce -fhardened

Bootstrapped/regtested on x86_64-pc-linux-gnu, powerpc64le-unknown-linux-gnu, and aarch64-unknown-linux-gnu; ok for trunk? -- >8 -- In I proposed -fhardened, a new umbrella option that enables a reasonable set of hardening flags.

[PATCH v5] c++: Move consteval folding to cp_fold_r

On Wed, Sep 13, 2023 at 05:57:47PM -0400, Jason Merrill wrote: > On 9/13/23 16:56, Marek Polacek wrote: > > On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason Merrill wrote: > > > On 9/8/23 14:24, Marek Polacek wrote: > > > > + switch (TREE_CODE (stmt)) > > > > +{ > > > > +/* Unfortunately

[PATCH v4] c++: Move consteval folding to cp_fold_r

On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason Merrill wrote: > On 9/8/23 14:24, Marek Polacek wrote: > > + if (!in_immediate_context () > > + /* P2564: a subexpression of a manifestly constant-evaluated > > expression > > +or conversion is an immediate function context. */ > > +

Re: [pushed] c++: __integer_pack with class argument [PR111357]

On Tue, Sep 12, 2023 at 01:27:44PM -0400, Jason Merrill via Gcc-patches wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > The argument might not already be an integer. > > PR c++/111357 > > gcc/cp/ChangeLog: > > * pt.cc (expand_integer_pack): Convert

[PATCH v3] c++: Move consteval folding to cp_fold_r

On Thu, Sep 07, 2023 at 02:32:51PM -0400, Jason Merrill wrote: > On 9/7/23 11:23, Marek Polacek wrote: > > On Tue, Sep 05, 2023 at 04:36:34PM -0400, Jason Merrill wrote: > > > On 9/5/23 15:59, Marek Polacek wrote: > > > > On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote: > > > > > On

[PATCH v2] c++: Move consteval folding to cp_fold_r

On Tue, Sep 05, 2023 at 04:36:34PM -0400, Jason Merrill wrote: > On 9/5/23 15:59, Marek Polacek wrote: > > On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote: > > > On 9/1/23 13:23, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > >

Re: [PATCH] c++: Move consteval folding to cp_fold_r

On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote: > On 9/1/23 13:23, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > > > In the review of P2564: > > > > it

Re: [PATCH] c++: improve verify_constant diagnostic [PR91483]

On Fri, Sep 01, 2023 at 08:00:01PM -0400, Marek Polacek via Gcc-patches wrote: >if (TREE_OVERFLOW_P (t)) > diff --git a/gcc/testsuite/g++.dg/diagnostic/constexpr3.C > b/gcc/testsuite/g++.dg/diagnostic/constexpr3.C > new file mode 100644 > index 000..b6e43a93664 > ---

[PATCH] c++: improve verify_constant diagnostic [PR91483]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- When verify_constant complains, it's pretty terse. Consider void test () { constexpr int i = 42; constexpr const int *p = } where it says "'& i' is not a constant expression". OK, but why? With this patch,

Re: [PATCH] c++: Move consteval folding to cp_fold_r

On Fri, Sep 01, 2023 at 01:23:48PM -0400, Marek Polacek via Gcc-patches wrote: > --- a/gcc/cp/cp-gimplify.cc > +++ b/gcc/cp/cp-gimplify.cc [...] > case ADDR_EXPR: >if (TREE_CODE (TREE_OPERAND (stmt, 0)) == FUNCTION_DECL > - && DECL_IMMEDIATE_FUNCTION_P

[PATCH] c++: Move consteval folding to cp_fold_r

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In the review of P2564: it turned out that in order to correctly handle an example in the paper, we should stop doing immediate evaluation in build_over_call

Re: [PATCH] c++: CWG 2359, wrong copy-init with designated init [PR91319]

On Tue, Aug 29, 2023 at 04:44:11PM -0400, Jason Merrill wrote: > On 8/28/23 19:09, Marek Polacek wrote: > > On Mon, Aug 28, 2023 at 06:27:26PM -0400, Jason Merrill wrote: > > > On 8/25/23 12:44, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > >

Re: RFC: Introduce -fhardened to enable security-related flags

On Tue, Aug 29, 2023 at 09:11:35PM +0100, Sam James via Gcc-patches wrote: > > Marek Polacek via Gcc-patches writes: > > > Improving the security of software has been a major trend in the recent > > years. Fortunately, GCC offers a wide variety of flags that enabl

Re: [PATCH v2] c++: tweaks for explicit conversion fns diagnostic

On Tue, Aug 29, 2023 at 04:42:33PM -0400, Jason Merrill wrote: > On 8/28/23 19:24, Marek Polacek wrote: > > On Fri, Aug 25, 2023 at 08:34:37PM -0400, Jason Merrill wrote: > > > On 8/25/23 19:37, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > >

RFC: Introduce -fhardened to enable security-related flags

Improving the security of software has been a major trend in the recent years. Fortunately, GCC offers a wide variety of flags that enable extra hardening. These flags aren't enabled by default, though. And since there are a lot of hardening flags, with more to come, it's been difficult to keep

[PATCH] c++: disallow constinit on functions [PR111173]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- [dcl.constinit]/1: The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration. and while we detect constinit int fn(); we weren't detecting using F = int();

[PATCH v2] c++: tweaks for explicit conversion fns diagnostic

On Fri, Aug 25, 2023 at 08:34:37PM -0400, Jason Merrill wrote: > On 8/25/23 19:37, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > > > 1) When saying that a conversion is erroneous because it would use > > an explicit constructor, it

Re: [PATCH] c++: CWG 2359, wrong copy-init with designated init [PR91319]

On Mon, Aug 28, 2023 at 06:27:26PM -0400, Jason Merrill wrote: > On 8/25/23 12:44, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > > > This CWG clarifies that designated initializer support > > direct-initialization. > > Just be careful

[PATCH] c++: tweaks for explicit conversion fns diagnostic

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- 1) When saying that a conversion is erroneous because it would use an explicit constructor, it might be nice to show where exactly the explicit constructor is located. For example, with this patch: [...] explicit.C:4:12:

Re: [PATCH] c++: use conversion_obstack_sentinel throughout

On Fri, Aug 25, 2023 at 12:33:31PM -0400, Patrick Palka via Gcc-patches wrote: > Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk? Very nice. LGTM. > -- >8 -- > > This replaces manual memory management via conversion_obstack_alloc(0) > and obstack_free with the

[PATCH] c++: CWG 2359, wrong copy-init with designated init [PR91319]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This CWG clarifies that designated initializer support direct-initialization. Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the initialization is by designated-initializer-clause, its form determines whether

[PATCH] c++: implement P2564, consteval needs to propagate up [PR107687]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This patch implements P2564, described at , whereby certain functions are promoted to consteval. For example: consteval int id(int i) { return i; } template constexpr int f(T t) { return t + id(t); // id causes

Re: [PATCH V4] Add warning options -W[no-]compare-distinct-pointer-types

On Thu, Aug 17, 2023 at 05:37:03PM +0200, Jose E. Marchesi via Gcc-patches wrote: > > > On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote: > > > >> +@opindex Wcompare-distinct-pointer-types > >> +@item -Wcompare-distinct-pointer-types > > > > This @item should say @r{(C and Objective-C

Re: [committed] i386: Fix grammar typo in diagnostic

On Mon, Aug 07, 2023 at 10:12:35PM +0100, Jonathan Wakely via Gcc-patches wrote: > Committed as obvious. > > Less obvious (to me) is whether it's correct to say "GCC V13" here. I > don't think we refer to a version that way anywhere else, do we? > > Would "since GCC 13.1.0" be better?

Re: [PATCH v2] analyzer: stash values for CPython plugin [PR107646]

On Wed, Aug 02, 2023 at 12:59:28PM -0400, David Malcolm wrote: > On Wed, 2023-08-02 at 12:20 -0400, Eric Feng wrote: > > Hi Eric, thanks for the updated patch. > > Overall, looks good to me, although I'd drop the "Exited." from the > "sorry" message (and thus from the dg-message directive),

[PATCH] c++: parser cleanup, remove dummy arguments

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Now that cp_parser_constant_expression accepts a null non_constant_p, we can transitively remove dummy arguments in the call chain. Running dg.exp and counting the # of is_rvalue_constant_expression calls from

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Tue, Jul 25, 2023 at 04:24:39PM -0400, Jason Merrill wrote: > On 7/25/23 15:59, Marek Polacek wrote: > > Something like this, then? I see that cp_parser_initializer_clause et al > > offer further opportunities (because they sometimes use a dummy too) but > > this should be a good start. > >

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

/23 14:13, Marek Polacek wrote: > > > > > On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote: > > > > > > On Tue, 18 Jul 2023, Marek Polacek via Gcc-patches wrote: > > > > > > > > > > > > > Bootstrapped/regtested on x86_64-p

[PATCH] c++: clear tf_partial et al in instantiate_template [PR108960]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In we concluded that we might clear all flags except tf_warning_or_error when performing instantiate_template. PR c++/108960 gcc/cp/ChangeLog:

[PATCH v3] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On Tue, Jul 25, 2023 at 11:15:07AM -0400, Jason Merrill wrote: > On 7/24/23 18:37, Marek Polacek wrote: > > On Sat, Jul 22, 2023 at 12:28:59AM -0400, Jason Merrill wrote: > > > On 7/21/23 18:38, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > >

[PATCH v2] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On Sat, Jul 22, 2023 at 12:28:59AM -0400, Jason Merrill wrote: > On 7/21/23 18:38, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > -- >8 -- > > > > This code in cxx_eval_array_reference has been hard to get right. > > In r12-2304 I added some

[PATCH] c++: fix ICE with constexpr ARRAY_REF [PR110382]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- This code in cxx_eval_array_reference has been hard to get right. In r12-2304 I added some code; in r13-5693 I removed some of it. Here the problematic line is "S s = arr[0];" which causes a crash on the assert in

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Thu, Jul 20, 2023 at 03:51:32PM -0400, Marek Polacek wrote: > On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote: > > On 7/20/23 14:13, Marek Polacek wrote: > > > On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote: > > > > On Tue, 18 Jul 2023,

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote: > On 7/20/23 14:13, Marek Polacek wrote: > > On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote: > > > On Tue, 18 Jul 2023, Marek Polacek via Gcc-patches wrote: > > > > > > > Bootst

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote: > On Tue, 18 Jul 2023, Marek Polacek via Gcc-patches wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk and branches? > > Looks reasonable to me. Thanks. > Though I wonder

Re: [PATCH] testsuite: fix allocator-opt1.C FAIL with old ABI

On Wed, Jul 19, 2023 at 03:22:10PM -0400, Marek Polacek wrote: > Ping. > > On Mon, Jul 10, 2023 at 04:33:26PM -0400, Marek Polacek via Gcc-patches wrote: > > Running > > $ make check-g++ > > RUNTESTFLAGS='--target_board=unix\{-D_GLIBCXX_USE_CXX11_ABI=0,\} > > dg

[PATCH v2] c++: fix ICE with designated initializer [PR110114]

On Wed, Jul 19, 2023 at 03:24:10PM -0400, Jason Merrill wrote: > On 7/19/23 14:38, Marek Polacek wrote: > > On Wed, Jul 19, 2023 at 02:32:15PM -0400, Patrick Palka wrote: > > > On Wed, 19 Jul 2023, Marek Polacek wrote: > > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > >

[PATCH] c++: Improve printing of base classes [PR110745]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This patch changes warning: missing initializer for member 'D::' [-Wmissing-field-initializers] to warning: missing initializer for member 'D::B' [-Wmissing-field-initializers] PR c++/110745 gcc/cp/ChangeLog:

Re: [PATCH] c++: -Wmissing-field-initializers and empty class [PR110064]

On Wed, Jul 19, 2023 at 03:36:49PM -0400, Jason Merrill wrote: > On 7/19/23 15:20, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > OK. We might also improve the diagnostic for base classes, perhaps by > teaching dump_simple_decl about DECL_FIELD_IS_BASE?

Re: [PATCH] testsuite: fix allocator-opt1.C FAIL with old ABI

Ping. On Mon, Jul 10, 2023 at 04:33:26PM -0400, Marek Polacek via Gcc-patches wrote: > Running > $ make check-g++ > RUNTESTFLAGS='--target_board=unix\{-D_GLIBCXX_USE_CXX11_ABI=0,\} > dg.exp=allocator-opt1.C' > yields: > > FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++98

[PATCH] c++: -Wmissing-field-initializers and empty class [PR110064]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Let's suppress -Wmissing-field-initializers for empty classes. Here I don't think I need the usual COMPLETE_TYPE_P/dependent_type_p checks. PR c++/110064 gcc/cp/ChangeLog: * typeck2.cc

Re: [PATCH] c++: fix ICE with designated initializer [PR110114]

On Wed, Jul 19, 2023 at 02:32:15PM -0400, Patrick Palka wrote: > On Wed, 19 Jul 2023, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > LGTM. It might be preferable to check COMPLETE_TYPE_P in the caller > instead, so that we avoid inspecting

[PATCH] c++: fix ICE with designated initializer [PR110114]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- r13-1227 added an assert checking that the index in a CONSTRUCTOR is a FIELD_DECL. That's a reasonable assumption but in this case we never called reshape_init due to the type being incomplete, and so the index remained an

[PATCH] c++: fix ICE with is_really_empty_class [PR110106]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk and branches? -- >8 -- is_really_empty_class is liable to crash when it gets an incomplete or dependent type. Since r11-557, we pass the yet-uninstantiated class type S<0> of the PARM_DECL s to is_really_empty_class -- because of the

[pushed] c++: Add tests for P2621, no UB in lexer [PR110340]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- C++26 P2621 removes UB in the lexer and either makes the construct valid or ill-formed. We're already handling this correctly so this patch only adds tests. PR c++/110340 gcc/testsuite/ChangeLog: * g++.dg/cpp/string-4.C:

[PATCH v2] c++: wrong error with static constexpr var in tmpl [PR109876]

On Fri, May 26, 2023 at 09:47:10PM -0400, Jason Merrill wrote: > On 5/26/23 19:18, Marek Polacek wrote: > > Since r8-509, we'll no longer create a static temporary var for > > the initializer '{ 1, 2 }' for num in the attached test because > > the code in finish_compound_literal is now guarded by

Re: [pushed] c++: C++26 constexpr cast from void* [PR110344]

On Tue, Jun 27, 2023 at 11:29:34PM -0400, Jason Merrill via Gcc-patches wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > P2768 allows static_cast from void* to ob* in constant evaluation if the > pointer does in fact point to an object of the appropriate type. >

[PATCH] testsuite: fix allocator-opt1.C FAIL with old ABI

Running $ make check-g++ RUNTESTFLAGS='--target_board=unix\{-D_GLIBCXX_USE_CXX11_ABI=0,\} dg.exp=allocator-opt1.C' yields: FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++98 scan-tree-dump-times gimple "struct allocator D" 1 FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++14

[PATCH] testsuite: fix dwarf2/utf-1.C with DWARF4

Running $ make check-c++ RUNTESTFLAGS='--target_board=unix\{-gdwarf-5,-gdwarf-4\} dwarf2.exp=utf-1.C' shows FAIL: g++.dg/debug/dwarf2/utf-1.C -std=gnu++20 scan-assembler-times DW_AT_encoding \\(0x10\\) 3 because with -gdwarf-4 the output is: .byte 0x10# DW_AT_encoding but with

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, Jun 30, 2023 at 04:11:44AM +0800, Xi Ruoyao wrote: > On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > > These tests fail when the testsuite is executed with -fstack- > > > prote

[PATCH] i386: add -fno-stack-protector to two tests

These tests fail when the testsuite is executed with -fstack-protector-strong. To avoid this, this patch adds -fno-stack-protector to dg-options. Tested on x86_64-pc-linux-gnu, ok for trunk? gcc/testsuite/ChangeLog: * gcc.target/i386/pr104610.c: Use -fno-stack-protector. *

[PATCH] testsuite: Use -fno-report-bug in gcc.dg/plugin/

Certain downstream compilers (for example, in Fedora) default to -freport-bug. The extra output breaks the following tests. We can use -fno-report-bug to fix that. Patch verified with: $ make check RUNTESTFLAGS='--target_board=unix\{,-freport-bug\} plugin.exp' Tested x86_64-pc-linux-gnu, ok

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

On Thu, Jun 29, 2023 at 05:58:22PM +0200, Martin Jambor wrote: > Hi, > > On Tue, Jun 27 2023, Marek Polacek wrote: > > On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote: > >> Hello, > >> > >> On Tue, May 16 2023, Marek Polacek via Gcc-patches

Re: [PATCH] c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

On Thu, Jun 29, 2023 at 11:22:55AM -0400, Patrick Palka via Gcc-patches wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk/13? > > -- >8 -- > > cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding > a CONSTRUCTOR initializer, which for

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

On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote: > Hello, > > On Tue, May 16 2023, Marek Polacek via Gcc-patches wrote: > > As promised in the --enable-host-pie patch, this patch adds another > > configure option, --enable-host-bind-now, which add

[PATCH] c++: fix error reporting routines re-entered ICE [PR110175]

Here we get the "error reporting routines re-entered" ICE because of an unguarded use of warning_at. While at it, I added a check for a warning_at just above it. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/110175 gcc/cp/ChangeLog: * typeck.cc

[PATCH v2] c++: Add support for -std={c,gnu}++2{c,6}

On Fri, Jun 23, 2023 at 10:58:54AM -0400, Jason Merrill wrote: > On 6/22/23 20:25, Marek Polacek wrote: > > It seems prudent to add C++26 now that the first C++26 papers have been > > approved. I followed commit r11-6920 as well as r8-3237. > > > > I was puzzled to see that -std=c++23 was marked

[PATCH] c++: Add support for -std={c,gnu}++2{c,6}

It seems prudent to add C++26 now that the first C++26 papers have been approved. I followed commit r11-6920 as well as r8-3237. I was puzzled to see that -std=c++23 was marked Undocumented but -std=c++2b wasn't. I think it should be the other way round, like the earlier modes. As for

Re: PING: Re: [PATCH] c++: provide #include hint for missing includes [PR110164]

On Wed, Jun 21, 2023 at 04:44:00PM -0400, David Malcolm via Gcc-patches wrote: > I'd like to ping this C++ FE patch for review: > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621779.html Not an approval, but LGTM, though some nits below: > On Wed, 2023-06-14 at 20:28 -0400, David

[wwwdocs] cxx-status: Add C++26 papers (Spring 2023, Varna)

First C++26 papers started to trickle in. Update our docs accordingly. We don't have -std=c++2c/-std=c++26/-std=gnu++2c/-std=gnu++26 yet, but I should have a patch for it by the end of this week. W3C validated. Pushed. commit 9c66e33761140358d350c5fb2d1638f6afdaead4 Author: Marek Polacek

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

On Fri, Jun 16, 2023 at 12:26:23PM +0200, Martin Jambor wrote: > Hello, > > On Thu, Jun 15 2023, Marek Polacek via Gcc-patches wrote: > > On Mon, Jun 05, 2023 at 09:06:43PM -0600, Jeff Law wrote: > >> > >> > >> On 6/5/23 10:18, Marek Polacek via Gcc-pa

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

On Mon, Jun 05, 2023 at 09:06:43PM -0600, Jeff Law wrote: > > > On 6/5/23 10:18, Marek Polacek via Gcc-patches wrote: > > Ping. Anyone have any further comments? > Given this was approved before, but got reverted due to issues (which have > since been addressed) -- I think

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

A biiig update with 100 new DRs. Also updated to reflect that DR 976 has been implemented. W3C validated. Pushed. commit d558d0a4f3407696d3f2ed868926a09a289e032e Author: Marek Polacek Date: Mon Jun 12 20:06:34 2023 -0400 cxx-dr-status: Update from C++ Core Language Issue TOC, Revision

[PATCH] doc: Clarification for -Wmissing-field-initializers

The manual is incorrect in saying that the option does not warn about designated initializers, which it does in C++. Whether the divergence in behavior is desirable is another thing, but let's at least make the manual match the reality. PR c/39589 PR c++/96868 gcc/ChangeLog:

[PATCH] c++: wrong error with static constexpr var in tmpl [PR109876]

Since r8-509, we'll no longer create a static temporary var for the initializer '{ 1, 2 }' for num in the attached test because the code in finish_compound_literal is now guarded by '&& fcl_context == fcl_c99' but it's fcl_functional here. This causes us to reject num as non-constant when

[PATCH] c++: -Wdangling-reference not suppressed in template [PR109774]

In check_return_expr, we suppress the -Wdangling-reference warning when we're sure it would be a false positive. It wasn't working in a template, though, because the suppress_warning call was never reached. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk and 13.2? PR

[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

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

Ping. On Tue, May 09, 2023 at 03:41:58PM -0400, Marek Polacek via Gcc-patches wrote: > [ This is my third attempt to add this configure option. The first > version was approved but it came too late in the development cycle. > The second version was also approved, but I had to revert it:

[PATCH v2] c++: wrong std::is_convertible with cv-qual fn [PR109680]

On Wed, May 03, 2023 at 03:37:03PM -0400, Jason Merrill wrote: > On 5/2/23 19:10, Marek Polacek wrote: > > This PR points out that std::is_convertible has given the wrong answer > > in > > > >static_assert (!std::is_convertible_v , ""); > > > > since r13-2822 implemented

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

[ This is my third attempt to add this configure option. The first version was approved but it came too late in the development cycle. The second version was also approved, but I had to revert it: . I've fixed the problem (by

[PATCH] c++: wrong std::is_convertible with cv-qual fn [PR109680]

This PR points out that std::is_convertible has given the wrong answer in static_assert (!std::is_convertible_v , ""); since r13-2822 implemented __is_{,nothrow_}convertible. std::is_convertible uses the imaginary To test() { return std::declval(); } to do its job. Here, From is 'int ()

[PATCH] c++: Move -Wdangling-reference to -Wextra [PR109642]

Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving

[pushed] ubsan: ubsan_maybe_instrument_array_ref tweak

In we discussed that the copy_node in ubsan_maybe_instrument_array_ref is redundant, but also that it'd be best to postpone the optimization to GCC 14. So I'm making that change now. Tested x86_64-pc-linux-gnu, applying to trunk.

Re: [PATCH] doc: Describe behaviour of enums with fixed underlying type

On Thu, Apr 27, 2023 at 12:16:34PM +0100, Jonathan Wakely via Gcc-patches wrote: > C2x adds the ability to give an enumeration type a fixed underlying > type, as C++ already has. The -fshort-enums option alters the compiler's > choice of underlying type, but when it's fixed the compiler can't >

Re: [PATCH] c: Avoid -Wenum-int-mismatch warning for redeclaration of builtin acc_on_device [PR107041]

On Thu, Apr 20, 2023 at 07:24:29PM +0200, Jakub Jelinek wrote: > On Thu, Apr 20, 2023 at 12:48:57PM -0400, Marek Polacek wrote: > > > - else if (enum_and_int_p && TREE_CODE (newdecl) != TYPE_DECL) > > > + else if (enum_and_int_p > > > +&& TREE_CODE (newdecl) != TYPE_DECL > > > +/* Don't

Re: [PATCH] c: Avoid -Wenum-int-mismatch warning for redeclaration of builtin acc_on_device [PR107041]

On Wed, Apr 19, 2023 at 11:02:53AM +0200, Jakub Jelinek wrote: > Hi! > > The new -Wenum-int-mismatch warning triggers with -Wsystem-headers in > , for obvious reasons the builtin acc_on_device uses int > type argument rather than enum which isn't defined yet when the builtin > is created, while

Re: [PATCH] sanitizer: missing signed integer overflow errors [PR109107]

Ping. On Tue, Mar 14, 2023 at 06:50:26PM -0400, Marek Polacek via Gcc-patches wrote: > Here we're failing to detect a signed overflow with -O because match.pd, > since r8-1516, transforms > > c = (a + 1) - (int) (short int) b; > > into > > c = (int) ((unsi

[PATCH v2] c++: further -Wdangling-reference refinement [PR107532]

On Sat, Mar 18, 2023 at 08:35:36AM -0400, Jason Merrill wrote: > On 3/17/23 16:29, Marek Polacek wrote: > > Based on , > > it seems like we should treat *any* class with a reference member > > as a reference wrapper. This simplifies the

[PATCH] c++: explicit ctor and list-initialization [PR109159]

When I implemented explicit(bool) in r9-3735, I added this code to add_template_candidate_real: + /* Now the explicit specifier might have been deduced; check if this + declaration is explicit. If it is and we're ignoring non-converting + constructors, don't add this function to the set

[PATCH] c++: further -Wdangling-reference refinement [PR107532]

Based on , it seems like we should treat *any* class with a reference member as a reference wrapper. This simplifies the code so I'm happy to make that change. The patch, however, does not suppress the warning in int i = 42; auto

Re: [PATCH] c, ubsan: Instrument even shortened divisions [PR109151]

On Fri, Mar 17, 2023 at 09:14:04AM +0100, Jakub Jelinek wrote: > Hi! > > On the following testcase, the C FE decides to shorten the division because > it has a guarantee that INT_MIN / -1 division won't be encountered, the > first operand is widened from narrower unsigned and/or the second

Re: [PATCH v2] c++: ICE with constexpr lambda [PR107280]

On Wed, Mar 15, 2023 at 12:48:27PM -0400, Jason Merrill wrote: > On 3/15/23 10:37, Marek Polacek wrote: > > On Fri, Mar 10, 2023 at 01:47:46PM -0500, Jason Merrill wrote: > > > On 3/10/23 11:17, Marek Polacek wrote: > > > > We crash here since r10-3661, the store_init_value hunk in particular. > >

[PATCH v2] c++: ICE with constexpr lambda [PR107280]

On Fri, Mar 10, 2023 at 01:47:46PM -0500, Jason Merrill wrote: > On 3/10/23 11:17, Marek Polacek wrote: > > We crash here since r10-3661, the store_init_value hunk in particular. > > Before, we called cp_fully_fold_init, so e.g. > > > >{.str=VIEW_CONVERT_EXPR("")} > > > > was folded into > >

[PATCH] sanitizer: missing signed integer overflow errors [PR109107]

Here we're failing to detect a signed overflow with -O because match.pd, since r8-1516, transforms c = (a + 1) - (int) (short int) b; into c = (int) ((unsigned int) a + 4294946117); wrongly eliding the overflow. This kind of problems is usually avoided by using TYPE_OVERFLOW_SANITIZED in

[PATCH] c++: suppress -Wdangling-reference for std::span [PR107532]

std::span is a view and therefore should be treated as a reference wrapper class for the purposes of -Wdangling-reference. I'm not sure there's a pattern that we could check for. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/107532 gcc/cp/ChangeLog: *

Re: [PATCH v2] ubsan: missed -fsanitize=bounds for compound ops [PR108060]

On Fri, Mar 10, 2023 at 07:07:36PM +0100, Jakub Jelinek wrote: > On Thu, Mar 09, 2023 at 07:44:53PM -0500, Marek Polacek wrote: > > On Thu, Mar 09, 2023 at 09:44:49AM +0100, Jakub Jelinek wrote: > > > On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote: > > > > I think this is a

[PATCH] c++: ICE with constexpr lambda [PR107280]

We crash here since r10-3661, the store_init_value hunk in particular. Before, we called cp_fully_fold_init, so e.g. {.str=VIEW_CONVERT_EXPR("")} was folded into {.str=""} but now we don't fold and keep the VCE around, and it causes trouble in cxx_eval_store_expression: in the

[PATCH v2] ubsan: missed -fsanitize=bounds for compound ops [PR108060]

On Thu, Mar 09, 2023 at 09:44:49AM +0100, Jakub Jelinek wrote: > On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote: > > I think this is a reasonable way to address the regression, so OK. > > It is true that both C and C++ (including c++14_down and c++17 and later > where the latter

[PATCH] ubsan: missed -fsanitize=bounds for compound ops [PR108060]

In this PR we are dealing with a missing .UBSAN_BOUNDS, so the out-of-bounds access in the test makes the program crash before a UBSan diagnostic was emitted. In C and C++, c_genericize gets a[b] = a[b] | c; but in C, both a[b] are one identical shared tree (not in C++ because

Re: [PATCH] [RFC] RAII auto_mpfr and autp_mpz

On Tue, Mar 07, 2023 at 09:54:08PM +, Jonathan Wakely via Gcc-patches wrote: > On Tue, 7 Mar 2023 at 21:52, Alexander Monakov wrote: > > > > > > On Tue, 7 Mar 2023, Jonathan Wakely wrote: > > > > > > Shouldn't this use the idiom suggested in ansidecl.h, i.e. > > > > > > > > private: > > > >

Re: [PATCH v2] c++: error with constexpr operator() [PR107939]

On Tue, Mar 07, 2023 at 09:53:28AM -0500, Jason Merrill wrote: > On 3/6/23 17:01, Marek Polacek wrote: > > On Mon, Mar 06, 2023 at 11:12:56AM -0500, Jason Merrill wrote: > > > On 3/3/23 12:51, Marek Polacek wrote: > > > > Similarly to PR107938, this also started with r11-557, whereby > > > >

[PATCH] c++: noexcept and copy elision [PR109030]

When processing a noexcept, constructors aren't elided: build_over_call has /* It's unsafe to elide the constructor when handling a noexcept-expression, it may evaluate to the wrong value (c++/53025). */ && (force_elide || cp_noexcept_operand == 0)) so

  1   2   3   4   5   6   7   8   9   10   >