Re: [PATCH] c++: compile time evaluation of prvalues [PR116416]

On Wed, Sep 25, 2024 at 08:54:46AM -0400, Jason Merrill wrote: > On 9/24/24 5:10 PM, Marek Polacek wrote: > > On Fri, Sep 20, 2024 at 06:39:52PM -0400, Jason Merrill wrote: > > > On 9/20/24 12:18 AM, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86

[PATCH] c++: use TARGET_EXPR accessors

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- While futzing around with PR116416 I noticed that we can use the _SLOT and _INITIAL macros to make the code more readable. gcc/c-family/ChangeLog: * c-pretty-print.cc (c_pretty_printer::primary_expression): Use

Re: [PATCH] c++: compile time evaluation of prvalues [PR116416]

On Sat, Sep 21, 2024 at 05:00:51PM +0200, Jakub Jelinek wrote: > On Fri, Sep 20, 2024 at 07:03:45PM -0400, Jason Merrill wrote: > > > The CALL_EXPR case in cp_fold uses !flag_no_inline instead, that makes > > > more > > > sense to me. > > > Because checking "noinline" attribute (which means don't

Re: [PATCH] c++: compile time evaluation of prvalues [PR116416]

On Fri, Sep 20, 2024 at 06:39:52PM -0400, Jason Merrill wrote: > On 9/20/24 12:18 AM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > This PR reports a missed optimization. When we have: > > > &g

[PATCH] c++: diagnose this specifier in requires expr [PR116798]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- We don't detect an explicit object parameter in a requires expression. We can get there by way of requires-expression -> requirement-parameter-list -> parameter-declaration-clause -> ... -> parameter-declaration with this[opt].

[PATCH] c++: compile time evaluation of prvalues [PR116416]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This PR reports a missed optimization. When we have: Str str{"Test"}; callback(str); as in the test, we're able to evaluate the Str::Str() call at compile time. But when we have: callback(Str{"Test"}); we are not. W

Re: [PATCH] c++: ICE with structured bindings and m-d array [PR102594]

Ping. On Thu, Sep 05, 2024 at 06:32:28PM -0400, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? > > -- >8 -- > We ICE in decay_conversion with this test: > > struct S { > S() {} > }; > S arr[1][1]; > auto [m](

[PATCH v5] c++: deleting explicitly-defaulted functions [PR116162]

On Tue, Sep 17, 2024 at 12:50:46PM -0400, Jason Merrill wrote: > On 9/16/24 7:14 PM, Marek Polacek wrote: > > +/* Mark an explicitly defaulted function FN as =deleted and warn. > > + IMPLICIT_FN is the corresponding special member function that > > + would have bee

[PATCH] c++: concept in default argument [PR109859]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- 1) We're hitting the assert in cp_parser_placeholder_type_specifier. It says that if it turns out to be false, we should do error() instead. Do so, then. 2) lambda-targ8.C should compile fine, though. The problem was that loca

[PATCH] c++: tweak for -Wrange-loop-construct [PR116731]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This PR reports that the warning would be better off using a check for trivially constructible rather than trivially copyable. LLVM accepted a similar fix: https://github.com/llvm/llvm-project/issues/47355 PR c++/11673

Re: [PATCH 2/2] c++: -Wdangling-reference diagnostic

On Tue, Sep 17, 2024 at 05:16:48PM -0400, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu. Marek, thoughts? Makes sense. OK, thanks. > -- 8< -- > > The -Wdangling-reference diagnostic talks about the full-expression, but > prints one call, while the full-expression in a declaration is the e

Re: [PATCH 1/2] c++: -Wdangling-reference and empty class [PR115361]

On Tue, Sep 17, 2024 at 05:16:47PM -0400, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu. Marek, any concerns? LGTM, thanks. The ChangeLog may not pass the hook because it's missing some entries. > -- 8< -- > > We can't have a dangling reference to an empty class unless it's > specifically

[PATCH v3] c++: ICE with -Wtautological-compare in template [PR116534]

On Tue, Sep 17, 2024 at 12:53:25PM -0400, Jason Merrill wrote: > On 9/16/24 7:08 PM, Marek Polacek wrote: > > On Tue, Sep 10, 2024 at 10:37:31AM -0400, Jason Merrill wrote: > > > On 8/29/24 12:23 PM, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64

[PATCH] c++: fix constexpr cast from void* diag issue [PR116741]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- The result of build_fold_indirect_ref can be a COMPONENT_REF in which case using DECL_SOURCE_LOCATION will crash. Look at its op1 instead. PR c++/116741 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_constant_

Re: [PATCH] c++: crash with anon VAR_DECL [PR116676]

On Tue, Sep 17, 2024 at 12:13:29PM -0400, Patrick Palka wrote: > On Tue, 17 Sep 2024, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13? > > Why not backport this to 12 as well? It didn't seem important enough but I've

[PATCH] c++: crash with anon VAR_DECL [PR116676]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13? -- >8 -- r12-3495 added maybe_warn_about_constant_value which will crash if it gets a nameless VAR_DECL, which is what happens in this PR. We created this VAR_DECL in cp_parser_decomposition_declaration. PR c++/116676 gc

[PATCH v4] c++: deleting explicitly-defaulted functions [PR116162]

On Fri, Sep 13, 2024 at 06:43:06PM +0200, Jason Merrill wrote: > On 9/12/24 3:12 PM, Marek Polacek wrote: > > On Wed, Sep 11, 2024 at 10:25:34PM -0400, Jason Merrill wrote: > > > On 9/11/24 4:08 PM, Marek Polacek wrote: > > > > @@ -6503,10 +6504,17 @@ c

[PATCH v2] c++: ICE with -Wtautological-compare in template [PR116534]

On Tue, Sep 10, 2024 at 10:37:31AM -0400, Jason Merrill wrote: > On 8/29/24 12:23 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? > > > > -- >8 -- > > Pre r14-4793, we'd call warn_tautological_cmp -> operan

Re: [PATCH] libcpp: Fix up UB in finish_embed

On Fri, Sep 13, 2024 at 12:33:00PM +0200, Jakub Jelinek wrote: > Hi! > > Jonathan reported on IRC that certain unnamed proprietary static analyzer > is unhappy about the new finish_embed function and it is actually right. > On a testcase like: > #embed __FILE__ limit (0) if_empty (0) > params->if_

[PATCH v3] c++: deleting explicitly-defaulted functions [PR116162]

On Wed, Sep 11, 2024 at 10:25:34PM -0400, Jason Merrill wrote: > On 9/11/24 4:08 PM, Marek Polacek wrote: > > @@ -6503,10 +6504,17 @@ check_bases_and_members (tree t) > > bool fn_const_p = (copy == 2); > > if (fn_const_p && !imp_const_p) > &

Re: [PATCH] c++: Disable deprecated/unavailable diagnostics when creating thunks for methods with such attributes [PR116636]

On Wed, Sep 11, 2024 at 11:26:35PM +0200, Jakub Jelinek wrote: > Hi! > > On the following testcase, we emit false positive warnings/errors about using > the deprecated or unavailable methods when creating thunks for them, even > when nothing (in the testcase so far) actually used those. > > The f

[PATCH v2] c++: ICE with TTP [PR96097]

On Wed, Sep 11, 2024 at 11:26:56AM -0400, Jason Merrill wrote: > On 9/11/24 10:53 AM, Patrick Palka wrote: > > On Wed, 11 Sep 2024, Patrick Palka wrote: > > > > > On Wed, 11 Sep 2024, Patrick Palka wrote: > > > > > > > On Wed, 4 Sep 2024, Marek Pol

[PATCH v2] c++: deleting explicitly-defaulted functions [PR116162]

On Wed, Sep 11, 2024 at 01:19:53PM -0400, Jason Merrill wrote: > On 9/11/24 12:54 PM, Marek Polacek wrote: > > + auto_diagnostic_group d; > > + /* We used to emit a hard error, so this uses 0 rather than > > +OPT_Wpedantic. */ > > + if (pedwarn (D

[PATCH] c++: deleting explicitly-defaulted functions [PR116162]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This PR points out the we're not implementing [dcl.fct.def.default] properly. Consider e.g. struct C { C(const C&&) = default; }; where we wrongly emit an error, but the move ctor should be just =deleted. According t

Re: [PATCH] c++: ICE with -Wtautological-compare in template [PR116534]

Ping. On Thu, Aug 29, 2024 at 12:23:35PM -0400, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? > > -- >8 -- > Pre r14-4793, we'd call warn_tautological_cmp -> operand_equal_p > with operands wrapped in NON_DEPENDENT_EXPR, which

Re: [PATCH] c++: mutable temps in rodata [PR116369]

Ping. On Thu, Aug 29, 2024 at 04:15:41PM -0400, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13? > > -- >8 -- > Here we wrongly mark the reference temporary for g TREE_READONLY, > so it's put in .rodata and so we can't modify i

[PATCH] c++: ICE with structured bindings and m-d array [PR102594]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- We ICE in decay_conversion with this test: struct S { S() {} }; S arr[1][1]; auto [m](arr3); But not when the last line is: auto [n] = arr3; Therefore the difference is between copy- and direct-init. In par

[PATCH] c++: vtable referring to "unavailable" virtual fn [PR116606]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- mark_vtable_entries already has /* It's OK for the vtable to refer to deprecated virtual functions. */ warning_sentinel w(warn_deprecated_decl); but that doesn't cover __attribute__((unavailable)). We can use the follo

[pushed] doc: remove stray character

Applying to trunk as obvious. -- >8 -- There's an extra '+'. gcc/ChangeLog: * doc/invoke.texi: Remove an extra char in @item sme2. --- gcc/doc/invoke.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 193db761d64..0f9

[PATCH v3] c++: fn redecl in fn scope wrongly accepted [PR116239]

On Thu, Sep 05, 2024 at 10:42:22AM -0400, Jason Merrill wrote: > On 9/4/24 1:18 PM, Marek Polacek wrote: > > On Wed, Sep 04, 2024 at 12:28:49PM -0400, Jason Merrill wrote: > > > > > + if (!validate_constexpr_redeclaration (alias, de

Re: [PATCH] aarch64: Handle attributes in the global namespace for aarch64_lookup_shared_state_flags [PR116598]

On Wed, Sep 04, 2024 at 02:05:21PM -0700, Andrew Pinski wrote: > The code in aarch64_lookup_shared_state_flags all C++11 attributes on the > function type > had a namespace associated with them. But with the addition of > reproducible/unsequenced, > this was no longer true. > This is the simple f

Re: [PATCH] c++: ICE with TTP [PR96097]

On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote: > On 9/3/24 6:12 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? > > The change to return bool seems like unrelated cleanup; please push that > separately on

[pushed] c++: cleanup coerce_template_template_parm

Split out from https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662261.html which was tested on x86_64-pc-linux-gnu. I'm checking this in. -- >8 -- This function could use some sprucing up. gcc/cp/ChangeLog: * pt.cc (coerce_template_template_parm): Return bool instead of int. --

[PATCH v2] c++: fn redecl in fn scope wrongly accepted [PR116239]

On Wed, Sep 04, 2024 at 12:28:49PM -0400, Jason Merrill wrote: > On 8/30/24 3:40 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Redeclaration such as > > > >void f(void); > >co

Re: [PATCH RFC] c-family: add attribute flag_enum [PR46457]

On Wed, Sep 04, 2024 at 08:15:25AM -0400, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu. Any objections? Looks good except... > +/* Attributes also recognized in the clang:: namespace. */ > +const struct attribute_spec c_common_clang_attributes[] = { > + { "flag_enum", 0, 0, fal

[PATCH] c++: ICE with TTP [PR96097]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- We crash when dependent_type_p gets a TEMPLATE_TYPE_PARM outside a template. That happens here because in template typename X> void func() {} template struct Y {}; void g() { func(); } when performing overload

[PATCH] c++: noexcept and pointer to member function type [PR113108]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- We ICE in nothrow_spec_p because it got a DEFERRED_NOEXCEPT. This DEFERRED_NOEXCEPT was created in implicitly_declare_fn when declaring Foo& operator=(Foo&&) = default; in the test. The problem is that in resolve_overloa

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

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- Fixed by r13-6693. PR c++/109095 gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nontype-class66.C: New test. --- gcc/testsuite/g++.dg/cpp2a/nontype-class66.C | 19 +++ 1 file changed, 19 insertions(+) create mode

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

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- -fconcepts-ts is no longer supported so this can't be made to ICE anymore. PR c++/101099 gcc/testsuite/ChangeLog: * g++.dg/concepts/pr101099.C: New test. --- gcc/testsuite/g++.dg/concepts/pr101099.C | 6 ++ 1 file chan

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

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- This got fixed by r15-2120. PR c++/115616 gcc/testsuite/ChangeLog: * g++.dg/template/friend83.C: New test. --- gcc/testsuite/g++.dg/template/friend83.C | 24 1 file changed, 24 insertions(+) creat

[PATCH] c++: fn redecl in fn scope wrongly accepted [PR116239]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Redeclaration such as void f(void); consteval void f(void); is invalid. In a namespace scope, we detect the collision in validate_constexpr_redeclaration, but not when one declaration is at block scope. When we have v

[PATCH] c++: mutable temps in rodata [PR116369]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13? -- >8 -- Here we wrongly mark the reference temporary for g TREE_READONLY, so it's put in .rodata and so we can't modify its subobject even when the subobject is marked mutable. This is so since r9-869. r14-1785 fixed a similar pr

[PATCH] c++: ICE with -Wtautological-compare in template [PR116534]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- Pre r14-4793, we'd call warn_tautological_cmp -> operand_equal_p with operands wrapped in NON_DEPENDENT_EXPR, which works, since o_e_p bails for codes it doesn't know. But now we pass operands not encapsulated in NON_DEPENDE

[PATCH] c++: wrong error due to std::initializer_list opt [PR116476]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- Here maybe_init_list_as_array gets elttype=field, init={NON_LVALUE_EXPR <2>} and it tries to convert the init's element type (int) to field using implicit_conversion, which works, so overall maybe_init_list_as_array is succes

[PATCH] c++: ICE with ()-init and TARGET_EXPR eliding [PR116424]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we crash on a cp_gimplify_expr/TARGET_EXPR assert: gcc_checking_assert (!TARGET_EXPR_ELIDING_P (*expr_p) || !TREE_ADDRESSABLE (TREE_TYPE (*expr_p))); We cannot elide the TARGET_EXPR becaus

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Mon, Aug 19, 2024 at 10:34:20PM +0100, Jonathan Wakely wrote: > On Mon, 19 Aug 2024 at 21:51, Gerald Pfeifer wrote: > > > > On Wed, 12 Oct 2022, Marek Polacek via Gcc-patches wrote: > > > + > > > +The two overload resolutions approach was complicated and quir

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Mon, Aug 19, 2024 at 10:51:28PM +0200, Gerald Pfeifer wrote: > On Wed, 12 Oct 2022, Marek Polacek via Gcc-patches wrote: > > + > > +The two overload resolutions approach was complicated and quirky, so users > > +should transition to the newer model. This change

[PATCH] c++: fix ICE in convert_nontype_argument [PR116384]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we ICE since r14-8291 in C++11/C++14 modes. Fortunately this is an easy one. The important bit of r14-8291 is this: @@ -20056,9 +20071,12 @@ tsubst_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)

[PATCH] c++: ICE with enum and conversion fn in template [PR115657]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we initialize an enumerator with a class prvalue with a conversion function. When we fold it in build_enumerator, we create a TARGET_EXPR for the object, and subsequently crash in tsubst_expr, which should not see such a c

Re: [PATCH v2] c++: ICE with NSDMIs and fn arguments [PR116015]

On Tue, Aug 13, 2024 at 03:12:01PM -0700, Jason Merrill wrote: > On 8/12/24 7:21 PM, Marek Polacek wrote: > > On Fri, Aug 09, 2024 at 05:15:05PM -0400, Jason Merrill wrote: > > > On 8/9/24 4:21 PM, Marek Polacek wrote: > > > > On Fri, Aug 09, 2024 at 12:58:3

[PATCH v2] c++: ICE with NSDMIs and fn arguments [PR116015]

On Fri, Aug 09, 2024 at 05:15:05PM -0400, Jason Merrill wrote: > On 8/9/24 4:21 PM, Marek Polacek wrote: > > On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote: > > > On 8/8/24 1:37 PM, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86

Re: [PATCH] c++: ICE with NSDMIs and fn arguments [PR116015]

On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote: > On 8/8/24 1:37 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > The problem in this PR is that we ended up with > > > >{.ro

Re: [PATCH] c++: Add missing auto_diagnostic_groups

On Fri, Aug 09, 2024 at 11:03:24AM +1000, Nathaniel Shead wrote: > On Thu, Aug 08, 2024 at 03:16:24PM -0400, Marek Polacek wrote: > > On Thu, Aug 08, 2024 at 09:13:05AM +1000, Nathaniel Shead wrote: > > > diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc > > > index 6c22

Re: [PATCH] c++: Add missing auto_diagnostic_groups

On Thu, Aug 08, 2024 at 09:13:05AM +1000, Nathaniel Shead wrote: > diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc > index 6c22ff55b46..03c19e4a7e4 100644 > --- a/gcc/cp/error.cc > +++ b/gcc/cp/error.cc > @@ -4782,12 +4782,14 @@ qualified_name_lookup_error (tree scope, tree name, > s

[PATCH] c++: ICE with NSDMIs and fn arguments [PR116015]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- The problem in this PR is that we ended up with {.rows=(&)->n, .outer_stride=(&)->rows} that is, two PLACEHOLDER_EXPRs for different types on the same level in one { }. That should not happen; we may, for instance, negle

[PATCH] c++: further concept_check_p clean-up

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Patrick noticed a few more concept_check_p checks that can be removed now. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_call_expression): Remove concept_check_p check. (cxx_eval_outermost_constant_expr): Likewise

Re: [PATCH] c++: fold calls to std::forward_like [PR96780]

On Tue, Aug 06, 2024 at 10:01:22AM -0400, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > look OK for trunk? Looks simple & good. Reviewed-by: Marek Polacek > -- >8 -- > > This extends our folding of cast-like standard libra

Re: [PATCH] c++: remove function/var concepts code

On Mon, Aug 05, 2024 at 09:56:20PM -0400, Patrick Palka wrote: > On Fri, 2 Aug 2024, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu. Comments? > > > > -- >8 -- > > This patch removes vestigial Concepts TS code as discussed in >

Re: [PATCH] c++: remove function/var concepts code

On Mon, Aug 05, 2024 at 02:52:32PM -0400, Jason Merrill wrote: > On 8/5/24 2:44 PM, Marek Polacek wrote: > > On Mon, Aug 05, 2024 at 12:00:04PM -0400, Jason Merrill wrote: > > > > I think we also want to adjust the 'concept bool' handling in >

Re: [PATCH] c++: remove function/var concepts code

On Mon, Aug 05, 2024 at 12:00:04PM -0400, Jason Merrill wrote: > On 8/2/24 2:12 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu. Comments? > > > > -- >8 -- > > This patch removes vestigial Concepts TS code as discussed in > > <ht

[PATCH v2] c++: fix -Wdangling-reference false positive [PR115987]

On Thu, Aug 01, 2024 at 05:20:43PM -0400, Jason Merrill wrote: > On 8/1/24 4:19 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > This fixes another false positive. When a function is taking a > > te

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

On Thu, Aug 01, 2024 at 05:18:35PM -0400, Jason Merrill wrote: > On 8/1/24 4:20 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Despite a number of mitigations (don't warn for std::span-like

[PATCH] c++: remove function/var concepts code

Bootstrapped/regtested on x86_64-pc-linux-gnu. Comments? -- >8 -- This patch removes vestigial Concepts TS code as discussed in . In particular, it removes code related to function/variable concepts. That includes variable_concept_

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

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Despite a number of mitigations (don't warn for std::span-like classes, lambdas, adding [[gnu::no_dangling]], etc.), the warning still seems to cause some grief. Let's move the warning to -Wextra, then. gcc/c-family/ChangeLog:

[PATCH] c++: DR882, main cannot be deleted [PR116169]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This DR clarifies that "int main() = delete;" is ill-formed. PR c++/116169 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Disallow deleting ::main. gcc/testsuite/ChangeLog: * g++.dg/DRs/dr882.C: New t

[PATCH] c++: fix -Wdangling-reference false positive [PR115987]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This fixes another false positive. When a function is taking a temporary of scalar type that couldn't be bound to the return type of the function, don't warn, such a program would be ill-formed. Thanks to Jonathan for reportin

[PATCH v3] c++: array new with value-initialization, again [PR115645]

On Tue, Jul 30, 2024 at 05:38:37PM -0400, Jason Merrill wrote: > On 7/30/24 4:59 PM, Marek Polacek wrote: > > On Mon, Jul 29, 2024 at 06:34:40PM -0400, Jason Merrill wrote: > > > On 7/29/24 4:18 PM, Marek Polacek wrote: > > > > On Tue, Jul 23, 2024 at 05:18:5

[PATCH v2] c++: array new with value-initialization, again [PR115645]

On Mon, Jul 29, 2024 at 06:34:40PM -0400, Jason Merrill wrote: > On 7/29/24 4:18 PM, Marek Polacek wrote: > > On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote: > > > On 7/17/24 5:33 PM, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86

Re: [PATCH] c++: array new with value-initialization, again [PR115645]

On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote: > On 7/17/24 5:33 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > Hmm, I thought I had replied to this already. > > > -- >8 -- > > Unfortunately, m

Re: [PATCH] c++: fix wrong ambiguity resolution [PR29834]

On Tue, Jul 23, 2024 at 05:12:14PM -0400, Jason Merrill wrote: > On 7/23/24 4:18 PM, Marek Polacek wrote: > > On Tue, Jul 23, 2024 at 12:53:07AM -0400, Jason Merrill wrote: > > > On 7/20/24 2:31 PM, Marek Polacek wrote: > > > > [ Entering the contest to f

[pushed] doc: add missing @option for musttail

I'll push this as obvious soon. -- >8 -- gcc/ChangeLog: * doc/extend.texi: Add missing @option. --- gcc/doc/extend.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index b0273927b25..66c99ef7a66 100644 --- a/gcc/doc/ex

Re: [PATCH] c++: fix wrong ambiguity resolution [PR29834]

On Tue, Jul 23, 2024 at 12:53:07AM -0400, Jason Merrill wrote: > On 7/20/24 2:31 PM, Marek Polacek wrote: > > [ Entering the contest to fix the oldest PR in this cycle. ] > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- >

Re: Compare loop bounds in ipa-icf

On Mon, Jul 22, 2024 at 06:12:43PM +0200, Jan Hubicka wrote: > Hi, > this testcase shows another poblem with missing comparators for metadata > in ICF. With value ranges available to loop optimizations during early > opts we can estimate number of iterations based on guarding condition that > can b

Re: [PATCH] c++: Some cp-tree.def comment fixes

On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote: > On Mon, 22 Jul 2024, Jakub Jelinek wrote: > > > Hi! > > > > While reading the fold expression and concept tree comments, I found > > various spots referring to non-existent macros etc. > > > > The following patch attempts to sync t

Re: [PATCH] c++: Some cp-tree.def comment fixes

On Mon, Jul 22, 2024 at 05:32:17PM +0200, Jakub Jelinek wrote: > Hi! > > While reading the fold expression and concept tree comments, I found > various spots referring to non-existent macros etc. > > The following patch attempts to sync that with what is actually implemented. > > Ok for trunk?

[PATCH] c++: fix wrong ambiguity resolution [PR29834]

[ Entering the contest to fix the oldest PR in this cycle. ] Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This 18-year-old PR reports that we parse certain comma expressions as a declaration rather than statement when the statement begins with a functional-style cast expr

Re: [PATCH v10 2/3] C: Implement musttail attribute for returns

On Thu, Jul 18, 2024 at 04:18:56PM -0700, Andi Kleen wrote: > > > > > + set_musttail_on_return (retval, xloc, musttail_p); > > > > > + > > > > >if (retval) > > > > > { > > > > >tree semantic_type = NULL_TREE; > > > > > > > > Is it deliberate that set_musttail_on_return is called

Re: [PATCH v10 2/3] C: Implement musttail attribute for returns

On Thu, Jul 18, 2024 at 03:11:56PM -0700, Andi Kleen wrote: > On Thu, Jul 18, 2024 at 02:19:21PM -0400, Marek Polacek wrote: > > On Wed, Jul 17, 2024 at 09:30:00PM -0700, Andi Kleen wrote: > > > Implement a C23 clang compatible musttail attribute similar to the earlier > >

Re: [PATCH] c++: implement DR1363 and DR1496 for __is_trivial [PR85723]

Ping. On Wed, Jun 19, 2024 at 09:54:23AM -0400, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > is_trivial was introduced in > <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2230.html> > which sp

Re: [PATCH v10 2/3] C: Implement musttail attribute for returns

On Wed, Jul 17, 2024 at 09:30:00PM -0700, Andi Kleen wrote: > Implement a C23 clang compatible musttail attribute similar to the earlier > C++ implementation in the C parser. > > gcc/c/ChangeLog: > > PR c/83324 > * c-parser.cc (struct attr_state): Define with musttail_p. > (c_pa

[PATCH v2] eh: ICE with std::initializer_list and ASan [PR115865]

On Wed, Jul 17, 2024 at 01:37:23PM +0200, Jakub Jelinek wrote: > On Thu, Jul 11, 2024 at 04:08:20PM -0400, Marek Polacek wrote: > > and we ICE on the empty finally in lower_try_finally_onedest while > > getting get_eh_else. > > > > Rather than checking everywhere that

[PATCH] c++: array new with value-initialization, again [PR115645]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Unfortunately, my r15-1946 fix broke the attached testcase. In it, we no longer go into the /* P1009: Array size deduction in new-expressions. */ block, and instead generate an operator new [] call along with a loop in build

Re: [PATCH v2 1/8] Fix warnings for tree formats in gfc_error

On Fri, Jul 12, 2024 at 04:11:48PM +0200, Paul-Antoine Arras wrote: > This enables proper warnings for formats like %qD. Ok. The new lines are the same as in gcc_cdiag_char_table and gcc_tdiag_char_table. > gcc/c-family/ChangeLog: > > * c-format.cc (gcc_gfc_char_table): Add formats for t

[PATCH] c++: wrong error initializing empty class [PR115900]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- In r14-409, we started handling empty bases first in cxx_fold_indirect_ref_1 so that we don't need to recurse and waste time. This caused a bogus "modifying a const object" error. I'm appending my analysis from the PR, but

Re: [PATCH v9 05/10] C: Implement musttail attribute for returns

On Mon, Jul 08, 2024 at 09:55:57AM -0700, Andi Kleen wrote: > Implement a C23 clang compatible musttail attribute similar to the earlier > C++ implementation in the C parser. Sorry that we haven't reviewed the C parts before. > > PR83324 I don't think this is going to pass the pre-commit

[pushed] doc: remove @opindex for fconcepts-ts

Applying to trunk as obvious. -- >8 -- We're getting complaints from the CI system about this removed option. I suspect I should have removed the @opindex and @itemx for it. This patch does that. gcc/ChangeLog: * doc/invoke.texi: Remove @opindex and @itemx for -fconcepts-ts. --- gcc/do

[PATCH] eh: ICE with std::initializer_list and ASan [PR115865]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Here we ICE with -fsanitize=address on std::initializer_list x = { 1, 2, 3 }; since r14-8681, which removed .ASAN_MARK calls on TREE_STATIC variables. That means that lower_try_finally now instead of try { .ASAN

Re: [PATCH v10] C, ObjC: Add -Wunterminated-string-initialization

The patch is OK, thanks. On Sat, Jun 29, 2024 at 03:10:43PM +0200, Alejandro Colomar wrote: > Warn about the following: > > char s[3] = "foo"; > > Initializing a char array with a string literal of the same length as > the size of the array is usually a mistake. Rarely is the case where >

[PATCH] c++: array new with value-initialization [PR115645]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches? -- >8 -- This extends the r11-5179 fix which doesn't work with multidimensional arrays. In particular, struct S { explicit S() { } }; auto p = new S[1][1](); should not say "converting to S from initializer list wou

[pushed] testsuite: fix spaceship-narrowing1.C

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- I made sure that Wnarrowing22.C works fine on ILP32, but apparently I didn't verify that spaceship-narrowing1.C works there as well. :( gcc/testsuite/ChangeLog: * g++.dg/cpp2a/spaceship-narrowing1.C: Use __INT64_TYPE__. --- gcc/te

[PATCH v2] c++: ICE with computed gotos [PR115469]

On Mon, Jul 01, 2024 at 02:44:56PM -0400, Jason Merrill wrote: > On 6/26/24 6:04 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > This is a low-prio crash on invalid code where we ICE on a VAR_DECL >

[PATCH] c++: DR2627, Bit-fields and narrowing conversions [PR94058]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This DR (https://cplusplus.github.io/CWG/issues/2627.html) says that even if we are converting from an integer type or unscoped enumeration type to an integer type that cannot represent all the values of the original type, it's

Re: [PATCH] preprocessor: Create the parser before handling command-line includes [PR115312]

6-64 Linux; > bootstrap + regtest c,c++ on x86_64-w64-mingw32. Is it OK for 14 branch and > master please? Thanks! The patch looks good to me. I think you can push it next week if there are no objections. Reviewed-by: Marek Polacek > -- >8 -- > > Since r14-2893, we create a pars

Re: [PATCH] c: ICE with invalid sizeof [PR115642]

Sorry, I used the wrong e-mail address for Joseph. On Wed, Jun 26, 2024 at 11:09:37AM -0400, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > Here we ICE in c_expr_sizeof_expr on an erroneous expr.value. The > code che

Re: [PATCH] c: ICE on invalid with attribute optimize [PR115549]

Sorry, I used the wrong e-mail address for Joseph. On Thu, Jun 27, 2024 at 05:04:41PM -0400, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > I had this PR in my open tabs so why not go ahead and fix it. > > decl_attribute

[PATCH] c: ICE on invalid with attribute optimize [PR115549]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- I had this PR in my open tabs so why not go ahead and fix it. decl_attributes gets last_decl, the last already pushed declaration, to be used in common_handle_aligned_attribute. In C++, we look up the decl via find_last_decl,

Re: [PATCH v3] c: Error message for incorrect use of static in array declarations

On Thu, Jun 27, 2024 at 11:06:51AM +, Uecker, Martin wrote: > > Next version with the improved location. I assume the [PATCH] > should become part of the commit message. Just the "c: ..." part please. > Bootstrapped and regression tested on x86_64. Thanks, this patch is OK. > c: Err

[PATCH] c++: ICE with computed gotos [PR115469]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This is a low-prio crash on invalid code where we ICE on a VAR_DECL with erroneous type. I thought I'd try to avoid putting such decls into ->names and ->names_in_scope but that sounds riskier than the following cleanup.

Re: [PATCH v2] c: Error message for incorrect use of static in array declarations

On Wed, Jun 26, 2024 at 08:01:57PM +0200, Martin Uecker wrote: > > Thanks Marek, here is the second version which should > implement all your suggestions.   Thanks! > (BTW: Without the newline of the end, the test case has > undefined behavior..., not that we need to care.) > > > Bootstrapped

[PATCH] c++: unresolved overload with comma op [PR115430]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This works: template int Func(T); typedef int (*funcptrtype)(int); funcptrtype fp0 = &Func; but this doesn't: funcptrtype fp2 = (0, &Func); because we only call resolve_nondeduced_context on the LHS (via convert_to

  1   2   3   4   5   6   7   8   9   10   >