Re: [PATCH] c++: merge tsubst_copy into tsubst_copy_and_build

On 10/4/23 12:08, Patrick Palka wrote: On Tue, 3 Oct 2023, Jason Merrill wrote: On 10/3/23 08:41, Patrick Palka wrote: On Mon, 2 Oct 2023, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The relationship betw

Re: [PATCH v3] c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660]

On 10/19/23 14:45, Marek Polacek wrote: On Thu, Oct 19, 2023 at 01:02:33PM -0400, Jason Merrill wrote: On 10/19/23 12:55, Marek Polacek wrote: On Thu, Oct 19, 2023 at 12:32:49PM -0400, Jason Merrill wrote: On 10/19/23 10:14, Marek Polacek wrote: On Thu, Oct 19, 2023 at 10:06:01AM -0400

Re: [PATCH v3] c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660]

On 10/19/23 12:55, Marek Polacek wrote: On Thu, Oct 19, 2023 at 12:32:49PM -0400, Jason Merrill wrote: On 10/19/23 10:14, Marek Polacek wrote: On Thu, Oct 19, 2023 at 10:06:01AM -0400, Jason Merrill wrote: On 10/19/23 09:39, Patrick Palka wrote: On Tue, 17 Oct 2023, Marek Polacek wrote

Re: [PATCH v3] c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660]

On 10/19/23 10:14, Marek Polacek wrote: On Thu, Oct 19, 2023 at 10:06:01AM -0400, Jason Merrill wrote: On 10/19/23 09:39, Patrick Palka wrote: On Tue, 17 Oct 2023, Marek Polacek wrote: On Tue, Oct 17, 2023 at 04:49:52PM -0400, Jason Merrill wrote: On 10/16/23 20:39, Marek Polacek wrote

Re: [PATCH] ABOUT-GCC-NLS: add usage guidance

On 10/19/23 11:21, Jakub Jelinek wrote: On Thu, Oct 19, 2023 at 11:11:30AM -0400, Jason Merrill wrote: A recent question led me to look at this file again, and it occurred to me that it could use to offer more guidance. OK for trunk? -- 8< -- gcc/ChangeLog: * ABOUT-GCC-NLS:

[PATCH RFA] diagnostic: rename new permerror overloads

OK for trunk? -- 8< -- While checking another change, I noticed that the new permerror overloads break gettext with "permerror used incompatibly as both --keyword=permerror:2 --flag=permerror:2:gcc-internal-format and --keyword=permerror:3 --flag=permerror:3:gcc-internal-format". So let's

[pushed] c++: use G_ instead of _

Tested with make po/gcc.pot to see that the strings are still there (though in a different place, now with the gcc-internal-format tag). Applying to trunk. -- 8< -- Since these strings are passed to error_at, they should be marked for translation with G_, like other diagnostic messages, rather

[PATCH] ABOUT-GCC-NLS: add usage guidance

A recent question led me to look at this file again, and it occurred to me that it could use to offer more guidance. OK for trunk? -- 8< -- gcc/ChangeLog: * ABOUT-GCC-NLS: Add usage guidance. --- gcc/ABOUT-GCC-NLS | 13 + 1 file changed, 13 insertions(+) diff --git

Re: [PATCH 2/1] c++: more non-static memfn call dependence cleanup [PR106086]

On 10/12/23 14:49, Patrick Palka wrote: On Tue, 26 Sep 2023, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This follow-up patch removes some more repetition of the type-dependent On second thought there's no good reason to

Re: [PATCH v3] c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660]

On 10/19/23 09:39, Patrick Palka wrote: On Tue, 17 Oct 2023, Marek Polacek wrote: On Tue, Oct 17, 2023 at 04:49:52PM -0400, Jason Merrill wrote: On 10/16/23 20:39, Marek Polacek wrote: On Sat, Oct 14, 2023 at 01:13:22AM -0400, Jason Merrill wrote: On 10/13/23 14:53, Marek Polacek wrote

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 10/18/23 13:28, waffl3x wrote: I will try to get something done today, but I was struggling with writing some of the tests, there's also a lot more of them now. I also wrote a bunch of musings in comments that I would like feedback on. My most concrete question is, how exactly should I be

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 10/18/23 07:46, waffl3x wrote: Any progress on this, or do I need to coax the process along? :) Yeah, I've been working on it since the copyright assignment process has finished, originally I was going to note that on my next update which I had hoped to finish today or tomorrow. Well, in

Re: [PATCH] c++: accepts-invalid with =delete("") [PR111840]

On 10/17/23 17:38, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- r6-2367 added a DECL_INITIAL check to cp_parser_simple_declaration so that we don't emit multiple errors in g++.dg/parse/error57.C. But that means we don't diagnose int f1()

[pushed] c++: mangling tweaks

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Most of this is introducing the abi_check function to reduce the verbosity of most places that check -fabi-version. The start_mangling change is to avoid needing to zero-initialize additional members of the mangling globals, though I'm not

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 9/25/23 21:56, waffl3x wrote: On the plus side, I took my time to figure out how to best to pass down information about whether a param is an xobj param. My initial impression on what you were suggesting was to push another node on the front of the list, but I stared at it for a few hours

Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 9/25/23 21:56, waffl3x wrote: Also, just a quick update on my copyright assignment, I have sent an e-mail to the FSF and haven't gotten a response yet. From what I was reading, I am confident that it's my preferred option going forward though. Hopefully they get back to me soon. Any

Re: [PATCH v3] c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660]

On 10/16/23 20:39, Marek Polacek wrote: On Sat, Oct 14, 2023 at 01:13:22AM -0400, Jason Merrill wrote: On 10/13/23 14:53, Marek Polacek wrote: On Thu, Oct 12, 2023 at 09:41:43PM -0400, Jason Merrill wrote: On 10/12/23 17:04, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu

Re: [PATCH] c++: Add missing auto_diagnostic_groups to constexpr.cc

On 10/17/23 12:34, Marek Polacek wrote: On Tue, Oct 17, 2023 at 09:35:21PM +1100, Nathaniel Shead wrote: Marek pointed out in another patch of mine [1] that I was missing an auto_diagnostic_group to correctly associate informative notes with their errors in structured error outputs. This patch

PING Re: [PATCH v2 RFA] diagnostic: add permerror variants with opt

Ping? On 10/3/23 17:09, Jason Merrill wrote: This revision changes from using DK_PEDWARN for permerror-with-option to using DK_PERMERROR. Tested x86_64-pc-linux-gnu. OK for trunk? -- 8< -- In the discussion of promoting some pedwarns to be errors by default, rather than move them

[pushed] c++: improve fold-expr location

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- I want to distinguish between constraint && and fold-expressions there of written by the user and those implied by template parameter type-constraints; to that end, let's improve our EXPR_LOCATION for an explicit fold-expression. The

Re: [PATCH] c++: fix truncated diagnostic in C++23 [PR111272]

On 10/13/23 18:15, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- In C++23, since P2448, a constexpr function F that calls a non-constexpr function N is OK as long as we don't actually call F in a constexpr context. So instead of giving an

Re: [PATCH v2] c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660]

On 10/13/23 14:53, Marek Polacek wrote: On Thu, Oct 12, 2023 at 09:41:43PM -0400, Jason Merrill wrote: On 10/12/23 17:04, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- My recent patch introducing cp_fold_immediate_r caused exponential compile t

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

On 10/10/23 13:20, Marek Polacek wrote: Thanks for looking into this. It's kept me occupied for quite a while. Thanks, nice work. On Tue, Aug 29, 2023 at 03:26:46PM -0400, Jason Merrill wrote: On 8/23/23 15:49, Marek Polacek wrote: +struct A { + int x; + int y = id(x); +}; + +template

Re: [PATCH] c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660]

On 10/12/23 17:04, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- My recent patch introducing cp_fold_immediate_r caused exponential compile time with nested COND_EXPRs. The problem is that the COND_EXPR case recursively walks the arms of a

Re: [PATCH v6] c++: Check for indirect change of active union member in constexpr [PR101631,PR102286]

On 10/12/23 04:53, Nathaniel Shead wrote: On Wed, Oct 11, 2023 at 12:48:12AM +1100, Nathaniel Shead wrote: On Mon, Oct 09, 2023 at 04:46:46PM -0400, Jason Merrill wrote: On 10/8/23 21:03, Nathaniel Shead wrote: Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631203.html

[pushed] c++: mangle multiple levels of template parms [PR109422]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- This becomes be more important with concepts, but can also be seen with generic lambdas. PR c++/109422 gcc/cp/ChangeLog: * mangle.cc (write_template_param): Also mangle level. gcc/testsuite/ChangeLog: *

Re: Documenting common C/C++ options

On Tue, Oct 10, 2023 at 7:12 AM Florian Weimer via Gcc wrote: > * Richard Earnshaw: > > > On 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote: > >> On 10/10/2023 10:47, Florian Weimer via Gcc wrote: > >>> Currently, -fsigned-char and -funsigned-char are only documented as C > >>>

Re: C89 question: Do we need to accept -Wint-conversion warnings

On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc wrote: > Are these code fragments valid C89 code? > > int i1 = 1; > char *p1 = i; > > char c; > char *p2 = > int i2 = p2; > > Or can we generate errors for them even with -std=gnu89? > > (It will still be possible to override this

Re: [PATCH v4] c++: Check for indirect change of active union member in constexpr [PR101631,PR102286]

On 10/8/23 21:03, Nathaniel Shead wrote: Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631203.html + && (TREE_CODE (t) == MODIFY_EXPR + /* Also check if initializations have implicit change of active +member earlier up the access chain.

Re: [PATCH] c++: Improve diagnostics for constexpr cast from void*

On 10/9/23 06:03, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu with GXX_TESTSUITE_STDS=98,11,14,17,20,23,26,impcx. -- >8 -- This patch improves the errors given when casting from void* in C++26 to include the expected type if the type of the pointed-to object was

Re: [PATCH] wwwdocs: Add ADL to C++ non-bugs

On 10/3/23 10:45, Jonathan Wakely wrote: We have a long history of INVALID bugs about std functions being available in the global namespace (PRs 27846, 67566, 82619, 99865, 110602, 111553, probably others). Let's document it. Also de-prioritize the C++98-only bugs, which are unlikely to affect

Re: [PATCH v2 RFA] diagnostic: add permerror variants with opt

On 10/4/23 03:07, Florian Weimer wrote: * Jason Merrill: @@ -6159,6 +6153,18 @@ errors by @option{-pedantic-errors}. For instance: -Wwrite-strings @r{(C++11 or later)} } +@opindex fpermissive +@item -fpermissive +Downgrade some required diagnostics about nonconformant code from

Re: [PATCH] c++: merge tsubst_copy into tsubst_copy_and_build

On 10/3/23 08:41, Patrick Palka wrote: On Mon, 2 Oct 2023, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The relationship between tsubst_copy_and_build and tsubst_copy (two of the main template argument substitution routines for

Re: [PATCH] c++: print source code in print_instantiation_partial_context_line

On 10/3/23 12:48, David Malcolm wrote: As mentioned in my Cauldron talk, this patch adds a call to diagnostic_show_locus to the "required from here" messages in print_instantiation_partial_context_line, so that e.g., rather than the rather mystifying: In file included from

[PATCH v2 RFA] diagnostic: add permerror variants with opt

This revision changes from using DK_PEDWARN for permerror-with-option to using DK_PERMERROR. Tested x86_64-pc-linux-gnu. OK for trunk? -- 8< -- In the discussion of promoting some pedwarns to be errors by default, rather than move them all into -fpermissive it seems to me to make sense to

Re: [PATCH] Remove poly_int_pod

On 9/28/23 05:55, Richard Sandiford wrote: poly_int was written before the switch to C++11 and so couldn't use explicit default constructors. This led to an awkward split between poly_int_pod and poly_int. poly_int simply inherited from poly_int_pod and added constructors, with the

Re: [PATCH v14 16/40] c, c++: Use 16 bits for all use of enum rid for more keyword space

On Tue, Sep 19, 2023 at 7:05 PM Ken Matsui wrote: > On Tue, Sep 19, 2023 at 9:59 AM Jason Merrill wrote: > > > > On 9/15/23 19:51, Ken Matsui via Gcc-patches wrote: > > > Now that RID_MAX has reached 255, we need to update the bit sizes of > every > > &

Re: [PATCH 1/2] c++: remove NON_DEPENDENT_EXPR, part 1

On 9/25/23 16:43, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This tree code dates all the way back to r69130[1] which implemented typing of non-dependent expressions. Its motivation was never clear (to me at least) since the

[pushed] c++ __integer_pack conversion again [PR111357]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- As Jakub pointed out, the real problem here is that in a partial substitution we're forgetting the conversion to the type of the non-type template argument, because maybe_convert_nontype_argument doesn't do anything with value-dependent

[pushed] c++: constexpr and designated initializer

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The change of active member being non-constant (before C++20) results in a CONSTRUCTOR with a null value for the first field, don't crash. gcc/cp/ChangeLog: * constexpr.cc (free_constructor): Handle null ce->value.

Re: [PATCH v3] c++: Catch indirect change of active union member in constexpr [PR101631]

On 9/21/23 09:41, Nathaniel Shead wrote: I've updated the error messages, and also fixed another bug I found while retesting (value-initialised unions weren't considered to have any active member yet). Bootstrapped and regtested on x86_64-pc-linux-gnu. -- >8 -- This patch adds checks for

[pushed] c++: unroll pragma in templates [PR111529]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were failing to handle ANNOTATE_EXPR in tsubst_copy_and_build, leading to problems with substitution of any wrapped expressions. Let's also not tell users that lambda templates are available in C++14. PR c++/111529

Re: [PATCH v2 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 9/21/23 07:28, waffl3x wrote: This seems like a reasonable place for it since 'this' is supposed to precede the decl-specifiers, and since we are parsing initial attributes here rather than in the caller. You will want to give an error if found_decl_spec is set. And elsewhere complain about

Re: [PATCH] c++: improve class NTTP object pretty printing [PR111471]

On 9/21/23 11:53, Jason Merrill wrote: On 9/20/23 10:13, Patrick Palka wrote: On Tue, 19 Sep 2023, Patrick Palka wrote: On Tue, 19 Sep 2023, Jason Merrill wrote: On 9/19/23 12:40, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13? OK for trunk.  What's

Re: [PATCH] c++: improve class NTTP object pretty printing [PR111471]

On 9/20/23 10:13, Patrick Palka wrote: On Tue, 19 Sep 2023, Patrick Palka wrote: On Tue, 19 Sep 2023, Jason Merrill wrote: On 9/19/23 12:40, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13? OK for trunk. What's your argument for backporting? Thanks

Re: [PATCH v2 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 9/19/23 20:30, waffl3x wrote: Thank you, this is great! Thanks! One legal hurdle to start with: our DCO policy (https://gcc.gnu.org/dco.html) requires real names in the sign-off, not pseudonyms. If you would prefer to contribute under this pseudonym, I encourage you to file a copyright

Re: [PATCH] c++: missing SFINAE in grok_array_decl [PR111493]

On 9/20/23 11:03, Patrick Palka wrote: On Wed, 20 Sep 2023, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This fixes some missed SFINAE in grok_array_decl when checking a C++23 multidimensional subscript operator expression.

Re: [PATCH] c++: constraint rewriting during ttp coercion [PR111485]

On 9/20/23 13:10, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps backports? OK for trunk and 13. -- >8 -- In order to compare the constraints of a ttp with that of its argument, we rewrite the ttp's constraints in terms of the

Re: [PATCH v2] c++: Catch indirect change of active union member in constexpr [PR101631]

On 9/19/23 20:55, Nathaniel Shead wrote: On Tue, Sep 19, 2023 at 05:25:20PM -0400, Jason Merrill wrote: On 9/1/23 08:22, Nathaniel Shead wrote: On Wed, Aug 30, 2023 at 04:28:18PM -0400, Jason Merrill wrote: On 8/29/23 09:35, Nathaniel Shead wrote: This is an attempt to improve the constexpr

Re: [PATCH v2 2/2] c++: convert_to_void and volatile references

On 9/19/23 13:53, Patrick Palka wrote: On Mon, 18 Sep 2023, Jason Merrill wrote: On 9/18/23 12:12, Patrick Palka wrote: Jason pointed out that even implicit loads of volatile references need to undergo lvalue-to-rvalue conversion, but we currently emit a warning in this case and discard

Re: [PATCH v8 0/4] P1689R5 support

On 9/1/23 09:04, Ben Boeckel wrote: Hi, This patch series adds initial support for ISO C++'s [P1689R5][], a format for describing C++ module requirements and provisions based on the source code. This is required because compiling C++ with modules is not embarrassingly parallel and need to be

Re: [PATCH v8 0/4] P1689R5 support

On 9/1/23 09:04, Ben Boeckel wrote: Hi, This patch series adds initial support for ISO C++'s [P1689R5][], a format for describing C++ module requirements and provisions based on the source code. This is required because compiling C++ with modules is not embarrassingly parallel and need to be

Re: [PATCH v2] c++: Catch indirect change of active union member in constexpr [PR101631]

On 9/1/23 08:22, Nathaniel Shead wrote: On Wed, Aug 30, 2023 at 04:28:18PM -0400, Jason Merrill wrote: On 8/29/23 09:35, Nathaniel Shead wrote: This is an attempt to improve the constexpr machinery's handling of union lifetime by catching more cases that cause UB. Is this approach OK? I'd

Re: [PATCH v5] c++: extend cold, hot attributes to classes

On 9/6/23 06:20, Javier Martinez wrote: reminder: ready for commit? Pushed, thanks! - Javier On Wed 23. Aug 2023 at 15:02, Javier Martinez <mailto:javier.martinez.bugzi...@gmail.com>> wrote: On Tue, Aug 22, 2023 at 7:50 PM Jason Merrill mailto:ja...@redhat.com>> wr

Re: [PATCH 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 8/31/23 04:33, Jakub Jelinek wrote: On Thu, Aug 31, 2023 at 06:02:36AM +, waffl3x via Gcc-patches wrote: +++ b/gcc/testsuite/g++.dg/cpp23/explicit-object-param-valid2.C @@ -0,0 +1,24 @@ +// P0847R7 +// { dg-do run { target c++23 } } This raises an important question whether we as an

Re: [PATCH v2 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

On 9/11/23 09:49, waffl3x via Gcc-patches wrote: Bootstrapped and tested on x86_64-linux with no regressions. Hopefully I fixed all the issues. I also took the opportunity to remove the small mistake present in v1, so that is no longer a concern. Thanks again for all the patience. -Alex

Re: [PATCH] c++: further optimize tsubst_template_decl

On 9/19/23 11:04, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This patch makes tsubst_template_decl use use_spec_table=false also in the non-class non-function template case, to avoid computing 'argvec' and doing a hash table

Re: [PATCH] c++: improve class NTTP object pretty printing [PR111471]

On 9/19/23 12:40, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13? OK for trunk. What's your argument for backporting? -- >8 -- 1. Move class NTTP object pretty printing to a more general spot in the pretty printer. 2. Print the type of an class NTTP

Re: [PATCH v14 16/40] c, c++: Use 16 bits for all use of enum rid for more keyword space

On 9/15/23 19:51, Ken Matsui via Gcc-patches wrote: Now that RID_MAX has reached 255, we need to update the bit sizes of every use of the enum rid from 8 to 16 to support more keywords. Sorry to bring this up so late, but this does raise the question of whether we actually want to use keyword

Re: [PATCH v3][RFC] c-family: Implement __has_feature and __has_extension [PR60512]

On 8/3/23 05:21, Alex Coplan wrote: Hi, This patch implements clang's __has_feature and __has_extension in GCC. This is a v3 which addresses feedback for the v2 patch posted here: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626058.html Main changes since v2: - As per Jason's

[pushed] c++: inherited default constructor [CWG2799]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In this testcase, it seems clear that B should be trivially default-constructible, since the inherited default constructor is trivial and there are no other subobjects to initialize. But we were saying no because we don't define triviality

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

On 9/19/23 09:01, Marek Polacek wrote: On Mon, Sep 18, 2023 at 09:36:31PM -0400, Jason Merrill wrote: On 9/18/23 17:42, Marek Polacek wrote: + /* The purpose of this is not to emit errors for mce_unknown. */ + const tsubst_flags_t complain = (data->flags == ff_fold_immedi

Re: [PATCH v2 1/2] c++: overeager type completion in convert_to_void [PR111419]

On 9/18/23 12:19, Patrick Palka wrote: On Mon, 18 Sep 2023, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here convert_to_void always completes the type of an indirection or id-expression, but according to [expr.context] an

Re: [PATCH v2 2/2] c++: convert_to_void and volatile references

On 9/18/23 12:12, Patrick Palka wrote: Jason pointed out that even implicit loads of volatile references need to undergo lvalue-to-rvalue conversion, but we currently emit a warning in this case and discard the load. This patch changes this behavior so that we don't issue a warning, and

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

On 9/18/23 17:42, Marek Polacek wrote: + /* The purpose of this is not to emit errors for mce_unknown. */ + const tsubst_flags_t complain = (data->flags == ff_fold_immediate + ? tf_none : tf_error); Maybe check flags & ff_mce_false, instead? OK with that

Re: [PATCH] c++: optimize tsubst_template_decl for function templates

On 9/18/23 08:58, Patrick Palka wrote: On Sun, 17 Sep 2023, Jason Merrill wrote: On 9/17/23 15:13, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- r14-2655-g92d1425ca78040 made instantiate_template avoid redundantly perform

Re: [PATCH] c++: non-dependent assignment checking [PR63198, PR18474]

On 9/18/23 09:12, Patrick Palka wrote: On Sun, 17 Sep 2023, Jason Merrill wrote: On 9/17/23 14:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Patch generatde with -w to avoid noisy whitespace changes. -- >8 -- This patch makes

[pushed] doc: GTY((cache)) documentation tweak

Applying to trunk as obvious (explaining existing behavior). -- 8< -- gcc/ChangeLog: * doc/gty.texi: Add discussion of cache vs. deletable. --- gcc/doc/gty.texi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi index 15f9fa07405..1dfe4652644

Re: [pushed] c++: [[no_unique_address]] and cv-qualified type

On 9/5/23 23:19, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were checking for overlap using same_type_p and therefore allocating two Empty subobjects at the same offset because one was cv-qualified. This gives the warning at the location of the class n

Re: [PATCH] c++: non-dependent assignment checking [PR63198, PR18474]

On 9/17/23 14:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Patch generatde with -w to avoid noisy whitespace changes. -- >8 -- This patch makes us recognize and check non-dependent simple assigments ahead of time, like we already do

Re: [PATCH] c++: optimize tsubst_template_decl for function templates

On 9/17/23 15:13, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- r14-2655-g92d1425ca78040 made instantiate_template avoid redundantly performing a specialization lookup when instantiating a function or alias template. This patch

Re: [PATCH] c++: constness of decltype of NTTP object [PR98820]

On 9/16/23 18:00, Patrick Palka wrote: On Sat, 16 Sep 2023, Jason Merrill wrote: On 9/15/23 13:55, Patrick Palka wrote: This corrects decltype of a (class) NTTP object as per [dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case. In the non-dependent case (nontype-class8.C) we

Re: [PATCH] c++: overeager type completion in convert_to_void [PR111419]

On 9/16/23 17:41, Patrick Palka wrote: On Sat, 16 Sep 2023, Jason Merrill wrote: On 9/15/23 12:03, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here convert_to_void always completes the type of an INDIRECT_REF or VAR_D

Re: [PATCH] c++: always check arity before deduction

On 9/12/23 20:33, Patrick Palka wrote: Bootstrpaped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- This simple patch extends the r12-3271-gf1e73199569287 optimization to apply to deduction without explicit template arguments as well. The motivation for this

Re: [PATCH] c++: unifying identical tmpls from current inst [PR108347]

On 9/13/23 13:53, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here more_specialized_partial_spec considers the two partial specializations to be unordered ultimately because unify for identical parm=arg=A::C returns failure due

Re: [PATCH] c++: optimize unification of class specializations [PR89231]

On 9/13/23 13:53, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- Since the LHS of a qualified-id is a non-deduced context, it effectively means we can't deduce from outer template arguments of a class template

Re: [PATCH] c++: overeager type completion in convert_to_void [PR111419]

On 9/15/23 12:03, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here convert_to_void always completes the type of an INDIRECT_REF or VAR_DECL expression, but according to [expr.context] an lvalue-to-rvalue conversion is applied to

Re: [PATCH] c++: visibility wrt template and ptrmem targs [PR70413]

On 9/15/23 12:03, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- When constraining the visibility of an instantiation, we weren't properly considering the visibility of PTRMEM_CST and TEMPLATE_DECL template arguments.

Re: [PATCH] c++: constness of decltype of NTTP object [PR98820]

On 9/15/23 13:55, Patrick Palka wrote: This corrects decltype of a (class) NTTP object as per [dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case. In the non-dependent case (nontype-class8.C) we resolve the decltype ahead of time, and finish_decltype_type already made sure to

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

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: On 9/13/23 16:56, Marek Polacek wrote: On Tue, Sep 12, 2023 at 05:26:25PM -0400, Jason

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

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: On 9/8/23 14:24, Marek Polacek wrote: + switch (TREE_CODE (stmt

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

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 we must handle code like +false ? bar () : 42 + where we have to check bar too

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

On 9/8/23 14:24, Marek Polacek wrote: 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

[PATCH RFC] diagnostic: add permerror variants with opt

Tested x86_64-pc-linux-gnu. Does this approach make sense to you? Or do you have another idea? Perhaps the warn_system_headers adjustment should also be part of this? -- 8< -- In the discussion of promoting some pedwarns to be errors by default, rather than move them all into -fpermissive it

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

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 argument to int. gcc/testsuite/ChangeLog: * g++.dg/ext/integer-pack7.C: New test. ---

[pushed] c++: ICE with -fno-exceptions and array init [PR107198]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The removed line no longer has an effect on anew5.C error recovery, and removing it improves error recovery for this testcase. PR c++/107198 gcc/cp/ChangeLog: * typeck2.cc (process_init_constructor_array): Use

Re: [PATCH] c++: cache conversion function lookup

On 9/7/23 16:12, Patrick Palka wrote: On Thu, 7 Sep 2023, Jason Merrill wrote: On 9/6/23 18:07, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION types on some test files

Re: [PATCH] c++: cache conversion function lookup

On 9/6/23 18:07, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION types on some test files. Does it make a measurable difference in compile time? +/* A cache of the result of

Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

On 9/6/23 18:09, Patrick Palka wrote: On Mon, 28 Aug 2023, Jason Merrill wrote: On 8/24/23 09:31, Patrick Palka wrote: On Wed, 23 Aug 2023, Jason Merrill wrote: On 8/21/23 21:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like a reasonable

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

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 9/1/23 13:23, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok

[pushed] c++: [[no_unique_address]] and cv-qualified type

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were checking for overlap using same_type_p and therefore allocating two Empty subobjects at the same offset because one was cv-qualified. This gives the warning at the location of the class name rather than the member declaration, but

Re: [PATCH] c++: Additional warning for name-hiding [PR12341]

On 9/4/23 13:18, priour...@gmail.com wrote: From: benjamin priour Hi, This patch was the first I wrote and had been at that time returned to me because ill-formatted. Getting busy with other things, I forgot about it. I've now fixed the formatting. Succesfully regstrapped on

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

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? -- >8 -- In the review of P2564: <https://gcc.gnu.org/pipermail/gcc-patches/2023-

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

On 9/1/23 20:00, Marek Polacek wrote: 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

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

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 turned out that in order to correctly handle an example in the paper, we should stop doing

Re: [PATCH] c++, v2: Diagnose [basic.scope.block]/2 violations even in compound-stmt of function-try-block [PR52953]

On 9/1/23 09:24, Jakub Jelinek wrote: On Thu, Aug 31, 2023 at 03:52:22PM -0400, Jason Merrill wrote: On 8/31/23 03:20, Jakub Jelinek wrote: As the following testcase shows, while check_local_shadow diagnoses most of the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's

Re: [PATCH] c++, v2: Diagnose [basic.scope.block]/2 violations even for block externs [PR52953]

On 9/1/23 09:34, Jakub Jelinek wrote: On Thu, Aug 31, 2023 at 05:46:28PM -0400, Jason Merrill wrote: I've suggested this to Core. Thanks. So, I'm not really sure what to do. Intuitively the patch seems right because even block externs redeclare stuff and change meaning of the identifiers

Re: [RFC PATCH] c++: Diagnose [basic.scope.block]/2 violations even for block externs [PR52953]

On 8/31/23 04:08, Jakub Jelinek wrote: Hi! C++17 had in [basic.block.scope]/2 "A parameter name shall not be redeclared in the outermost block of the function definition nor in the outermost block of any handler associated with a function-try-block." and in [basic.block.scope]/4 similar rule

Re: [PATCH] c++: Diagnose [basic.scope.block]/2 violations even in compound-stmt of function-try-block [PR52953]

On 8/31/23 03:20, Jakub Jelinek wrote: Hi! As the following testcase shows, while check_local_shadow diagnoses most of the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's name is redeclared inside of the compound-stmt of a function-try-block. There is in that case an

Re: [PATCH] c++, v3: Fix up mangling of function/block scope static structured bindings and emit abi tags [PR111069]

On 8/31/23 15:14, Jakub Jelinek wrote: On Thu, Aug 31, 2023 at 01:11:57PM -0400, Jason Merrill wrote: 2023-08-28 Jakub Jelinek PR c++/111069 gcc/ * common.opt (fabi-version=): Document version 19. * doc/invoke.texi (-fabi-version=): Likewise. gcc/c-family

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