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 g

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

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 n

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 locall

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

[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 gcc/c

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

[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:28AM -0500, Pat

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

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

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 checkin

[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 c++/94231

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

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 > > gcc/cp/Chang

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 s

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

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]; would you prefer something else? -- >8 -- Since my r11-532 changes to implement DR2237, for this test: template struct S { S(); }; in C

[PATCH] libitm: small update for C++20

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- C++20 DR 2237 disallows simple-template-id in cdtors, so you can't write template struct S { S(); // should be S(); }; This hasn't been a problem until now but I'm adding a warning about it to -Wc++20-compat

Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

On Fri, Feb 02, 2024 at 05:32:31PM +0100, Jakub Jelinek wrote: > On Fri, Feb 02, 2024 at 11:27:09AM -0500, Marek Polacek wrote: > > > With -pedantic-errors we would have __has_extension behaving like > > > __has_feature, and I wanted to check in the test that this doesn'

Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

On Fri, Feb 02, 2024 at 03:45:48PM +, Alex Coplan wrote: > On 02/02/2024 09:34, Marek Polacek wrote: > > On Fri, Feb 02, 2024 at 10:27:23AM +, Alex Coplan wrote: > > > Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk? > > > > > > T

Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

On Fri, Feb 02, 2024 at 10:27:23AM +, Alex Coplan wrote: > Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk? > > Thanks, > Alex > > -- >8 -- > > When __has_feature was introduced for GCC 14, I included the feature > cxx_constexpr_string_builtins, since of the relevant string built

[PATCH] c++: -Wdangling-reference tweak to unbreak aarch64

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? aarch64-unknown-linux-gnu now bootstraps. -- >8 -- My recent -Wdangling-reference change to not warn on std::span-like classes unfortunately caused a new warning: extending reference_like_class_p also opens the door to new warnings sinc

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On Thu, Feb 01, 2024 at 02:32:33PM +, Alex Coplan wrote: > On 31/01/2024 15:53, Marek Polacek wrote: > > On Wed, Jan 31, 2024 at 07:44:41PM +, Alex Coplan wrote: > > > Hi Marek, > > > > > > On 30/01/2024 13:15, Marek Polacek wrote: > > > >

Re: [PATCH v3 4/5] Add tests for C/C++ musttail attributes

On Wed, Jan 31, 2024 at 11:39:56PM -0800, Andi Kleen wrote: > > This will run the test only once with -std=c++11. We'll get better coverage > > with dropping the line above and using > > > > /* { dg-do compile { target { tail_call && { c || c++11 } } } } */ > > > > but here it may not matter. >

[PATCH] c++: ICE with throw inside concept [PR112437]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13/12? -- >8 -- We crash in the loop at the end of treat_lvalue_as_rvalue_p for code like template concept Throwable = requires(T x) { throw x; }; because the code assumes that we eventually reach sk_function_parms or sk_try and ba

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On Wed, Jan 31, 2024 at 02:57:09PM -0500, Jason Merrill wrote: > On 1/31/24 14:44, Alex Coplan wrote: > > Hi Marek, > > > > On 30/01/2024 13:15, Marek Polacek wrote: > > > On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote: > > >

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On Wed, Jan 31, 2024 at 07:44:41PM +, Alex Coplan wrote: > Hi Marek, > > On 30/01/2024 13:15, Marek Polacek wrote: > > On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote: > > > On 1/25/24 20:36, Marek Polacek wrote: > > > > Better version: > &

Re: [PATCH v3 1/5] Improve must tail in RTL backend

On Wed, Jan 31, 2024 at 12:16:59PM -0800, Andi Kleen wrote: > > This results in "error: cannot tail-call: cannot tail-call: other reasons". > > So the second argument should be "other reasons" only. > > Yes will fix those. Thanks. > > > > > I notice that if I don't use -O2 I also get "other reas

Re: [PATCH v3 4/5] Add tests for C/C++ musttail attributes

On Tue, Jan 30, 2024 at 06:17:17PM -0800, Andi Kleen wrote: > Mostly adopted from the existing C musttail plugin tests. Please add a ChangeLog entry. > --- > gcc/testsuite/c-c++-common/musttail1.c | 17 > gcc/testsuite/c-c++-common/musttail2.c | 36 + > gcc

Re: [PATCH v3 2/5] C++: Support clang compatible [[musttail]] (PR83324)

On Tue, Jan 30, 2024 at 06:17:15PM -0800, Andi Kleen wrote: > This patch implements a clang compatible [[musttail]] attribute for > returns. > > musttail is useful as an alternative to computed goto for interpreters. > With computed goto the interpreter function usually ends up very big > which ca

Re: [PATCH v2] c++: add deprecation notice for -fconcepts-ts

On Wed, Jan 31, 2024 at 02:00:18PM -0500, Jason Merrill wrote: > On 1/31/24 10:55, Marek Polacek wrote: > > On Wed, Jan 31, 2024 at 08:53:00AM -0500, Jason Merrill wrote: > > > On 1/31/24 03:40, Richard Biener wrote: > > > > On Wed, Jan 31, 2024 at 12:19 AM

Re: [PATCH v3 1/5] Improve must tail in RTL backend

On Tue, Jan 30, 2024 at 06:17:14PM -0800, Andi Kleen wrote: > - Give error messages for all causes of non sibling call generation > - Don't override choices of other non sibling call checks with > must tail. This causes ICEs. The must tail attribute now only > overrides flag_optimize_sibling_calls

[PATCH v2] c++: add deprecation notice for -fconcepts-ts

On Wed, Jan 31, 2024 at 08:53:00AM -0500, Jason Merrill wrote: > On 1/31/24 03:40, Richard Biener wrote: > > On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote: > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > -

[PATCH] c++: add deprecation notice for -fconcepts-ts

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- We plan to deprecate -fconcepts-ts in GCC 15 and remove the flag_concepts_ts code. This note is an admonishing reminder to convert the Concepts TS code to C++20 Concepts. gcc/c-family/ChangeLog: * c-opts.cc (c_common_

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote: > On 1/25/24 20:36, Marek Polacek wrote: > > Better version: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Real-world experience shows that

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

On Thu, Jan 25, 2024 at 08:37:36PM -0500, Marek Polacek wrote: > +/* Handle a "non_owning" attribute; arguments as in > + struct attribute_spec.handler. */ > + > +tree > +handle_non_owning_attribute (tree *node, tree name, tree args, int, > +

[PATCH] c++: #pragma doesn't disable -Wunused-label [PR113582]

Low prio and not a regression. Feel free to ignore till GCC 15. Bootstrapped/regtested on x86_64-pc-linux-gnu. -- >8 -- The PR complains that void do_something(){ #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-label" start:; #pragma GCC diagnostic pop }

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

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Since -Wdangling-reference has false positives that can't be prevented, we should offer an easy way to suppress the warning. Currently, that is only possible by using a #pragma, either around the enclosing class or around the ca

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

Better version: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Real-world experience shows that -Wdangling-reference triggers for user-defined std::span-like classes a lot. We can easily avoid that by considering classes like template struct Span { T* data_;

[PATCH] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Real-world experience shows that -Wdangling-reference triggers for user-defined std::span-like classes a lot. We can easily avoid that by considering classes like template struct Span { T* data_; std::size

[pushed] c++: extend Wdangling-reference17.C [PR109642]

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- This patch extends g++.dg/warn/Wdangling-reference17.C with code from PR109642. I'm not creating a new test because this one already #includes the required headers. PR c++/109642 gcc/testsuite/ChangeLog: * g++.dg/warn/Wdan

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

On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote: > I don't really know whether this is the right way to treat > CONVERT_EXPR as below, but... Regtested native > x86_64-linux-gnu. Ok to commit? Thanks for taking a look at this problem. > brgds, H-P > > -- >8 -- > That gcc_un

[PATCH] c++: -Wdangling-reference and lambda false warning [PR109640]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- -Wdangling-reference checks if a function receives a temporary as its argument, and only warns if any of the arguments was a temporary. But we should not warn when the temporary represents a lambda or we generate false positive

[PATCH] libstdc++: suppress -Wdangling-reference with operator| [PR111410]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- It seems to me that we should exclude std::ranges::views::__adaptor::operator| from the -Wdangling-reference warning. It's commonly used when handling ranges. PR c++/111410 libstdc++-v3/ChangeLog: * include/s

[PATCH] c++: ICE when xobj is not the first parm [PR113389]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In grokdeclarator/cdk_function the comment says that the find_xobj_parm lambda clears TREE_PURPOSE so that we can correctly detect an xobj that is not the first parameter. That's all good, but we should also clear the TREE_PURP

[PATCH] c++: fix xobj diagnostic messages

Tested x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Diagnostics should start with a lower-case letter. gcc/cp/ChangeLog: * decl.cc (grokdeclarator) : Tweak diagnostic messages. --- gcc/cp/decl.cc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/cp/dec

[PATCH] c++: fix ICE with xobj in destructor [PR113340]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we crash in maybe_retrofit_in_chrg on an invalid dtor with explicit this. Such member functions do not get converted to METHOD_TYPE. If a dtor gets parameters, we reset arg_types to void_list_node in grokdeclarator. This

[PATCH] c++: ICE with auto in template arg [PR110065]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we started crashing with r14-1659 because that removed the auto checking in cp_parser_template_type_arg which seemed like dead code. But the attached test shows that the code can still be reached because cp_parser_type_id

Re: [PATCH RFC] codingconventions: add lambda guidelines

On Thu, Jan 11, 2024 at 04:33:10PM -0500, Jason Merrill wrote: > Now in patch form! > > Any further comments? It looks good to me, but it doesn't say if we want to put a space after } and before () if we're invoking the lambda (I suppose we want that space). As in ... = [&] (tree arg) { ... }

Re: [PATCH] c-family: copy attribute diagnostic fixes [PR113262]

On Tue, Jan 09, 2024 at 09:52:17AM +0100, Jakub Jelinek wrote: > Hi! > > The copy attributes is allowed on decls as well as types and even has > checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics > unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only work

[PATCH] sccopy: remove unused data member [PR113069]

Should be obvious, but... tested on x86_64, ok for trunk? -- >8 -- PR tree-optimization/113069 gcc/ChangeLog: * gimple-ssa-sccopy.cc (scc_discovery): Remove unused member. --- gcc/gimple-ssa-sccopy.cc | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/gimple-ssa-sccopy.cc

Re: [PATCH] c++: [[deprecated]] on template redecl [PR84542]

On Mon, Dec 18, 2023 at 02:50:04PM -0500, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk? LGTM but... > -- >8 -- > > The deprecated and unavailable attributes weren't working when used on > a template redeclaration ultimately because the

[PATCH] c++: fix parsing with auto(x) at block scope [PR112482]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This is sort of like r14-5514, but at block scope. Consider struct A { A(int, int); }; void g (int a) { A bar(auto(a), 42); // not a fn decl } where we emit error: 'auto' parameter not permitted in this context

[PATCH v4] c++: fix ICE with sizeof in a template [PR112869]

On Wed, Dec 13, 2023 at 03:28:38PM -0500, Jason Merrill wrote: > On 12/12/23 17:48, Marek Polacek wrote: > > On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote: > > > On 12/8/23 16:15, Marek Polacek wrote: > > > > On Fri, Dec 08, 2023 at 12:09:1

Re: [PATCH] hardened: use LD_PIE_SPEC only if defined

On Thu, Dec 14, 2023 at 04:50:49PM -0300, Alexandre Oliva wrote: > > sol2.h may define LINK_PIE_SPEC and leave LD_PIE_SPEC undefined, but > gcc.cc will only provide a LD_PIE_SPEC definition if LINK_PIE_SPEC is > not defined, and then it uses LD_PIE_SPEC guarded by #ifdef HAVE_LD_PIE > only. Add L

Re: [PATCH] c++: section attribute on templates [PR70435, PR88061]

On Thu, Dec 14, 2023 at 02:17:25PM -0500, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk? LGTM. > -- >8 -- > > The section attribute currently has no effect on templates because the > call to set_decl_section_name only happens at parse ti

Re: [PATCH] c++: Implement P2582R1, CTAD from inherited constructors

On Wed, Dec 13, 2023 at 08:48:49PM -0500, Jason Merrill wrote: > On 11/27/23 10:58, Patrick Palka wrote: > > gcc/cp/ChangeLog: > > > > * cp-tree.h (type_targs_deducible_from): Adjust return type. > > * pt.cc (alias_ctad_tweaks): Handle C++23 inherited CTAD. > > (inherited_ctad_tweaks):

Re: [pushed 1/4] c++: copy location to AGGR_INIT_EXPR

On Wed, Dec 13, 2023 at 08:38:12PM -0500, Jason Merrill wrote: > On 12/13/23 19:00, Marek Polacek wrote: > > On Wed, Dec 13, 2023 at 11:47:37AM -0500, Jason Merrill wrote: > > > Tested x86_64-pc-linux-gnu, applying to trunk. > > > > > > -- 8< -- > > &g

Re: [pushed 1/4] c++: copy location to AGGR_INIT_EXPR

On Wed, Dec 13, 2023 at 11:47:37AM -0500, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > When building an AGGR_INIT_EXPR from a CALL_EXPR, we shouldn't lose location > information. I think the following should be an obvious fix, so I'll check it in. -- >8

[PATCH v3] c++: fix ICE with sizeof in a template [PR112869]

On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote: > On 12/8/23 16:15, Marek Polacek wrote: > > On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: > > > On 12/5/23 15:31, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86

Re: [PATCH] c++: Fix warmth propagation for member function templates

On Tue, Dec 12, 2023 at 07:29:40PM +, Jason Xu wrote: > Support was recently added for class-level warmth attributes that are > propagated to member functions. The current implementation ignores > member function templates and this patch fixes that. Thanks for the patch. Is there a bug in the

Re: [PATCH] c++: End lifetime of objects in constexpr after destructor call [PR71093]

On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote: > On 12/11/23 14:21, Marek Polacek wrote: > > On Mon, Dec 11, 2023 at 08:17:22PM +0100, Richard Biener wrote: > > > > > > > > > > Am 11.12.2023 um 20:12 schrieb Jason Merrill : > > >

Re: [PATCH] c++: End lifetime of objects in constexpr after destructor call [PR71093]

On Mon, Dec 11, 2023 at 08:17:22PM +0100, Richard Biener wrote: > > > > Am 11.12.2023 um 20:12 schrieb Jason Merrill : > > Maybe something like this? Or shall we write out the names like > > CLOBBER_OBJECT_START, CLOBBER_STORAGE_END, etc? > > Yeah, the abbreviations look a bit confusing so spe

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

On Mon, Dec 11, 2023 at 02:02:52PM -0500, Jason Merrill wrote: > On 12/11/23 03:49, FX Coudert wrote: > > Hi Marek, > > > > The patch is causing three failures on x86_64-apple-darwin21: > > > > > FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler > > > _Z1gI1XEvT_ > > > FAIL:

[PATCH v2] c++: fix ICE with sizeof in a template [PR112869]

On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: > On 12/5/23 15:31, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > This test shows that we cannot clear *walk_subtrees in >

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

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- This one was fixed by r12-7714-g47da5198766256. PR c++/88848 gcc/testsuite/ChangeLog: * g++.dg/inherit/multiple2.C: New test. --- gcc/testsuite/g++.dg/inherit/multiple2.C | 35 1 file changed, 35 i

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

On Thu, Dec 07, 2023 at 04:05:47PM +, Richard Sandiford wrote: > Marek Polacek writes: > > Bootstrapped/regtested on aarch64-pc-linux-gnu, ok for trunk/13? > > > > -- >8 -- > > These tests fail when the testsuite is executed with > > -fstack-protector-s

Re: [PATCH] c-family: Fix up -fno-debug-cpp [PR111965]

On Thu, Dec 07, 2023 at 08:53:37AM +0100, Jakub Jelinek wrote: > Hi! > > As can be seen in the second testcase, -fno-debug-cpp is actually > implemented the same as -fdebug-cpp and so doesn't turn the debugging > off. > > The following patch fixes that. > > Bootstrapped/regtested on x86_64-linux

[PATCH] aarch64: add -fno-stack-protector to tests

Bootstrapped/regtested on aarch64-pc-linux-gnu, ok for trunk/13? -- >8 -- These tests fail when the testsuite is executed with -fstack-protector-strong. To avoid this, this patch adds -fno-stack-protector to dg-options. The list of FAILs is appended. As you can see, it's mostly about scan-assemb

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

On Wed, Dec 06, 2023 at 05:09:21PM +0530, Prathamesh Kulkarni wrote: > On Tue, 5 Dec 2023 at 06:18, Marek Polacek wrote: > > > > On Mon, Dec 04, 2023 at 04:49:29PM -0500, Jason Merrill wrote: > > > On 12/4/23 15:23, Marek Polacek wrote: > > > > +/* FN is not

[PATCH] c++: fix ICE with sizeof in a template [PR112869]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This test shows that we cannot clear *walk_subtrees in cp_fold_immediate_r when we're in_immediate_context, because that, as the comment says, affects cp_fold_r as well. Here we had an expression with min ((long int) VIEW_CO

[PATCH] build: unbreak bootstrap on uclinux targets [PR112762]

Tested with .../configure --target=c6x-uclinux [...] && make all-gcc, ok for trunk? -- >8 -- Currently, cross-compiling with --target=c6x-uclinux (and several other) fails due to: ../../src/gcc/config/linux.h:221:45: error: 'linux_fortify_source_default_level' was not declared in this scope #de

Re: [PATCH] c++, v2: Fix parsing [[]][[]];

On Tue, Dec 05, 2023 at 06:00:31PM +0100, Jakub Jelinek wrote: > On Tue, Dec 05, 2023 at 09:45:32AM -0500, Marek Polacek wrote: > > > When working on the previous patch I put [[]] [[]] asm (""); into a > > > testcase, but was surprised it wasn't parsed. > &

Re: [PATCH] c++: Further #pragma GCC unroll C++ fix [PR112795]

On Tue, Dec 05, 2023 at 07:55:37AM +0100, Jakub Jelinek wrote: > Hi! > > When committing the #pragma GCC unroll patch, I found I forgot one spot > for diagnosting the invalid unrolls - if #pragma GCC unroll argument is > dependent and the pragma is before a range for loop, the unroll tree (now, >

Re: [PATCH] c++: Further #pragma GCC unroll C++ fix [PR112795]

On Tue, Dec 05, 2023 at 10:21:18AM -0500, Marek Polacek wrote: > On Tue, Dec 05, 2023 at 07:55:37AM +0100, Jakub Jelinek wrote: > > Hi! > > > > When committing the #pragma GCC unroll patch, I found I forgot one spot > > for diagnosting the invalid unrolls - if #pr

Re: [PATCH] c++: Fix parsing [[]][[]];

On Tue, Dec 05, 2023 at 08:51:51AM +0100, Jakub Jelinek wrote: > Hi! > > When working on the previous patch I put [[]] [[]] asm (""); into a > testcase, but was surprised it wasn't parsed. By wasn't parsed you mean we gave an error, right? I only see an error with block-scope [[]] [[]];. > The

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

On Fri, Dec 01, 2023 at 07:43:35PM -0500, Jason Merrill wrote: > On 12/1/23 18:37, Marek Polacek wrote: > > On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote: > > > On 11/23/23 11:46, Marek Polacek wrote: > > > > v5 greatly simplifies the code. > >

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

On Mon, Dec 04, 2023 at 04:49:29PM -0500, Jason Merrill wrote: > On 12/4/23 15:23, Marek Polacek wrote: > > +/* FN is not a consteval function, but may become one. Remember to > > + escalate it after all pending templates have been instantiated. */

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

On Thu, Nov 30, 2023 at 06:34:01PM -0500, Jason Merrill wrote: > On 11/23/23 11:46, Marek Polacek wrote: > > v5 greatly simplifies the code. > > Indeed, it's much cleaner now. > > > I still need a new ff_ flag to signal that we can return immediately > > af

Re: [PATCH] gcc: Disallow trampolines when -fhardened

On Fri, Dec 01, 2023 at 11:44:28AM -0800, Andrew Pinski wrote: > On Fri, Dec 1, 2023, 11:36 Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > It came up that a good hardening strategy is to disable

[PATCH] gcc: Disallow trampolines when -fhardened

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- It came up that a good hardening strategy is to disable trampolines which may require executable stack. Therefore the following patch adds -Werror=trampolines to -fhardened. gcc/ChangeLog: * common.opt (Wtrampolines):

Re: [PATCH v2] c++: wrong ambiguity in accessing static field [PR112744]

On Thu, Nov 30, 2023 at 11:42:36AM -0500, Jason Merrill wrote: > On 11/29/23 17:01, Marek Polacek wrote: > > On Wed, Nov 29, 2023 at 03:28:44PM -0500, Jason Merrill wrote: > > > On 11/29/23 12:43, Marek Polacek wrote: > > > > On Wed, Nov 29, 2023 at 12:23:4

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

On Thu, Nov 30, 2023 at 10:30:44PM +0100, Jakub Jelinek wrote: > On Thu, Nov 30, 2023 at 10:27:33PM +0100, Florian Weimer wrote: > > * Jakub Jelinek: > > > > > On Thu, Nov 30, 2023 at 04:15:26PM -0500, Marek Polacek wrote: > > >> On Thu, Nov 30, 2023 at 10

Re: [PATCH] preprocessor: Reinitialize frontend parser after loading a PCH [PR112319]

On Wed, Nov 01, 2023 at 05:54:57PM -0400, Lewis Hyatt wrote: > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319 > > This is a one-line patch to fix the GCC 14 regression noted in the > PR. Bootstrap + regtest all languages on x86-64 looks good. Is it OK please? > Thanks! > > -Lewis

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

On Thu, Nov 30, 2023 at 10:11:31PM +0100, Florian Weimer wrote: > * Marek Polacek: > > > On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote: > >> --- a/gcc/doc/invoke.texi > >> +++ b/gcc/doc/invoke.texi > >> @@ -6183,6 +6183,7 @@ that

Re: [PATCH v3 11/11] c: Add new -Wdeclaration-missing-parameter-type permerror

On Mon, Nov 20, 2023 at 10:56:42AM +0100, Florian Weimer wrote: > This used to be a warning, enabled by default, without its own option. I think this patch is OK now. > A subsequent change could improve diagnostics and provide spelling > hints for declarations like “void function (int32t);”. Fe

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote: > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -6183,6 +6183,7 @@ that have their own flag: > @gccoptlist{ > -Wimplicit-function-declaration @r{(C)} > -Wimplicit-int @r{(C)} > +-Wincompatible-pointer-types @r{(C)} > -

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote: > The change to build_conditional_expr drops the downgrade > from a pedwarn to warning for builtins for C99 and later > language dialects. It remains a warning in C89 mode (not > a permerror), as the -std=gnu89 -fno-permissive test sh

Re: [PATCH v3 08/11] c: Do not ignore some forms of -Wimplicit-int in system headers

On Mon, Nov 20, 2023 at 10:56:26AM +0100, Florian Weimer wrote: > Most -Wimplicit-int warnings were unconditionally disabled for system > headers. Only missing types for parameters in old-style function > definitions resulted in warnings. This is inconsistent with the > treatment of other permerr

Re: [PATCH v3 07/11] c: Turn -Wimplicit-int into a permerror

On Mon, Nov 20, 2023 at 10:56:20AM +0100, Florian Weimer wrote: > Most of these new permerrors are currently not diagnosed in system > headers. > > gcc/ > > PR c/91093 > PR c/96284 > * doc/invoke.texi (Warning Options): Document changes. > > gcc/c/ > > * c-decl.cc (warn_

Re: [PATCH v3 06/11] c: Turn -Wimplicit-function-declaration into a permerror

On Mon, Nov 20, 2023 at 10:56:16AM +0100, Florian Weimer wrote: > In the future, it may make sense to avoid cascading errors from > the implicit declaration, especially its assumed int return type. > This change here only changes the kind of the diagnostic, not > its wording or consequences. Looks

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