Re: [PATCH] c++: Allow translations of check_postcondition_result messages [PR109309]

On 3/28/23 11:44, Jakub Jelinek wrote: Hi! As mentioned in the PR, constructing a message from two parts by concatenating them prevents translations, unless one of the parts is a keyword which should be never translated. The following patch fixes that, ok for trunk? OK. 2023-03-28 Jakub

PING^2 Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]

On 3/14/23 11:16, Jason Merrill wrote: On 3/8/23 11:54, Jason Merrill wrote: On 3/8/23 11:15, Jason Merrill wrote: On 3/8/23 10:53, Jan Hubicka wrote: Tested x86_64-pc-linux-gnu.  Does this look good, or do we want to factor the flag clearing into a symtab_node counterpart to

Re: [PATCH RFC] c-family: -Wsequence-point and COMPONENT_REF [PR107163]

On 3/24/23 18:25, Jakub Jelinek wrote: On Fri, Mar 24, 2023 at 06:11:44PM -0400, Jason Merrill wrote: When we touch this for COMPONENT_REF, shouldn't we then handle it as unary given that the second operand is FIELD_DECL and third/fourth will likely be NULL and even if not, aren't user

Re: [PATCH RFC] c-family: -Wsequence-point and COMPONENT_REF [PR107163]

On 3/23/23 17:03, Jakub Jelinek wrote: On Thu, Mar 23, 2023 at 04:35:07PM -0400, Jason Merrill wrote: Tested x86_64-pc-linux-gnu. Jakub, does this make sense to you? Do we have a way of testing for compile-hog regressions? -- 8< -- The patch for PR91415 fixed -Wsequence-point to treat

[pushed] c++: default template arg, partial ordering [PR105481]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The default argument code in type_unification_real was assuming that all targs we've deduced by that point are non-dependent, but that's not the case for partial ordering. PR c++/105481 gcc/cp/ChangeLog: * pt.cc

Re: [PATCH] c++: outer 'this' leaking into local class [PR106969]

On 3/23/23 11:00, Patrick Palka wrote: Here when resolving the implicit object for '' within the local class Foo, we expect to obtain a dummy object of type Foo& since there's no 'this' available in this context. And yet at this point current_class_ref still corresponds to the outer class

[pushed] c++: constexpr PMF conversion [PR105996]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here, we were calling build_reinterpret_cast regardless of whether there was actually a cast, and that now sets REINTERPRET_CAST_P. But that optimization seems dodgy anyway, as it involves NOP_EXPR from one RECORD_TYPE to another and we

[PATCH RFC] c-family: -Wsequence-point and COMPONENT_REF [PR107163]

Tested x86_64-pc-linux-gnu. Jakub, does this make sense to you? Do we have a way of testing for compile-hog regressions? -- 8< -- The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF as sequenced in C++17, and COMPONENT_REF as well. But this is unnecessary for

[pushed] c++: local class in nested generic lambda [PR109241]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In this testcase, the tree walk to look for bare parameter packs was confused by finding a type with no TREE_BINFO. But it should be fine that it's unset; we already checked for unexpanded packs at parse time. I also tried doing the

[pushed] c++: array bound partial ordering [PR108390]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- fold_convert doesn't work with a dependent argument, and problematically differed from the corresponding fold+build_nop further down in the function. So change it to match. PR c++/108390 gcc/cp/ChangeLog: * pt.cc

[pushed] c++: attribute on dtor in template [PR108795]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Since r7-2549 we were throwing away the explicit C:: when we found that ~C has an attribute that we treat as making its type dependent. PR c++/108795 gcc/cp/ChangeLog: * semantics.cc (finish_id_expression_1): Check scope

Re: [PATCH] c++: Avoid duplicate diagnostic calling unavailable function [PR109177]

On 3/22/23 07:32, Alex Coplan wrote: Hi, As the PR shows, we currently emit duplicate diagnostics for calls to functions marked with __attribute__((unavailable)). This patch fixes that. I'm not sure whether it's considered acceptable to add the include of decl.h to call.cc (in order to get at

Re: [PATCH] wwwdocs: Clarify experimental status of C++17 prior to GCC 9

On 3/22/23 06:42, Jonathan Wakely wrote: We don't currently have a single page where you can find out when support for a given standard became non-experimental (you have to look through all the gcc-X/changes.html pages to find it). I think we should have that info on the cxx-status.html page.

[pushed] c++: DMI in template with virtual base [PR106890]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- When parsing a default member init we just build a CONVERT_EXPR for converting to a virtual base, and then expand that into the more complex form when we actually use the DMI in a constructor. But that wasn't working for the template case

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

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

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

On 3/20/23 15:26, Jakub Jelinek wrote: On Mon, Mar 20, 2023 at 03:15:32PM -0400, Jason Merrill wrote: + else if (VAR_P (decl) + && CP_DECL_THREAD_LOCAL_P (decl) + && (!DECL_EXTERNAL (decl) || flag_extern_tls_init) Hmm, I wonder why we don't check the above line

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

On 3/18/23 11:09, Jakub Jelinek wrote: On Sat, Mar 18, 2023 at 01:54:58PM +0100, Jakub Jelinek via Gcc-patches wrote: The patch is mostly about DECL_EXTERNAL cases, the others are supposedly handled by the var_definition_p code there (or at least I assumed; testcases certainly test only

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

On 3/20/23 11:55, Marek Polacek wrote: When I implemented explicit(bool) in r9-3735, I added this code to add_template_candidate_real: + /* Now the explicit specifier might have been deduced; check if this + declaration is explicit. If it is and we're ignoring non-converting +

Re: [PATCH] c++: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

On 3/17/23 13:51, Jakub Jelinek wrote: Hi! The following two testcases are miscompiled, because we keep TREE_READONLY on the vars even when they are (possibly) dynamically initialized by a TLS wrapper function. Normally cp_finish_decl drops TREE_READONLY from vars which need dynamic

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

On 3/17/23 16:29, Marek Polacek wrote: Based on , it seems like we should treat *any* class with a reference member as a reference wrapper. This simplifies the code so I'm happy to make that change. The patch, however, does not suppress

[pushed] c++: constant, array, lambda, template [PR108975]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- When a lambda refers to a constant local variable in the enclosing scope, we tentatively capture it, but if we end up pulling out its constant value, we go back at the end of the lambda and prune any unneeded captures. Here while parsing

[pushed] c++: throw and private destructor [PR109172]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Since we aren't going through the normal call machinery, we need to check the dtor access specifically. PR c++/109172 gcc/cp/ChangeLog: * except.cc (build_throw): Check dtor access. gcc/testsuite/ChangeLog: *

[pushed] c++: namespace-scoped friend in local class [PR69410]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- do_friend was only considering class-qualified identifiers for the qualified-id case, but we also need to skip local scope when there's an explicit namespace scope. PR c++/69410 gcc/cp/ChangeLog: * friend.cc (do_friend):

[pushed] c++: __func__ and local class DMI [PR105809]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- As in 108242, we need to instantiate in the context of the enclosing function, not after it's gone. PR c++/105809 gcc/cp/ChangeLog: * init.cc (get_nsdmi): Split out... (maybe_instantiate_nsdmi_init): ...this

[pushed] c++: generic lambda, local class, __func__ [PR108242]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here we are trying to do name lookup in a deferred instantiation of t() and failing to find __func__. tsubst_expr already tries to instantiate members of local classes, but was failing with the partial instantiation of generic lambdas.

[pushed] c++: ::enumerator [PR101869]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We don't want to call build_offset_ref with an enum. PR c++/101869 gcc/cp/ChangeLog: * semantics.cc (finish_qualified_id_expr): Don't try to build a pointer-to-member if the scope is an enumeration.

Re: [PATCH] c++: ICE with diagnosed constraint recursion [PR100288]

On 3/16/23 12:48, Patrick Palka wrote: When satisfaction_cache::get detects constraint recursion, it asserts that entry->result is empty. This makes sense when we're initially detecting/diagnosing recursion from the inner recursive call, but aftewards from the outer recursive call the recursion

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

On 3/16/23 11:48, Patrick Palka wrote: On Thu, 16 Mar 2023, Jason Merrill wrote: On 3/16/23 10:09, Patrick Palka wrote: On Wed, 15 Mar 2023, Patrick Palka wrote: On Thu, 9 Mar 2023, Jason Merrill wrote: On 3/9/23 14:32, Patrick Palka wrote: On Mon, 6 Mar 2023, Marek Polacek via

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

On 3/16/23 10:09, Patrick Palka wrote: On Wed, 15 Mar 2023, Patrick Palka wrote: On Thu, 9 Mar 2023, Jason Merrill wrote: On 3/9/23 14:32, Patrick Palka wrote: On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote: When processing a noexcept, constructors aren't elided: build_over_call

[PATCH RFC] c++: co_await and move-only type [PR105406]

Tested x86_64-pc-linux-gnu. As with the array issue, I know you have WIP to deal with larger issues, but this seems like a reasonable local fix. Does it make sense to you? -- 8< -- Here we were building a temporary MoveOnlyAwaitable to hold the result of evaluating 'o', but since 'o' is an

[pushed] c++: co_await and initializer_list [PR103871]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- When flatten_await_stmt processes the backing array for an initializer_list, we call cp_build_modify_expr to initialize the promoted variable from the TARGET_EXPR; that needs to be accepted. PR c++/103871 PR c++/98056

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

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

[PATCH 2/2] c++: passing one ttp to another [PR108179]

I kept trying to improve our choice of how many levels of outer_args to add, when really the problem was that outer_args are for PARM and for this reverse deduction we should be adding the outer arguments for ARG. I spent quite a while trying to get DECL_CONTEXT set consistently on template

[pushed 1/2] c++: coerce_template_template_parms interface tweak

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- This should have no semantic effect, but is a prerequisite for the PR108179 fix to follow. PR c++/108179 gcc/cp/ChangeLog: * pt.cc (coerce_template_template_parms): Take the arg and parm templates directly.

[pushed] c++: injected class name as default ttp arg [PR58538]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- This function needs to handle this case like convert_template_argument. PR c++/58538 gcc/cp/ChangeLog: * semantics.cc (check_template_template_default_arg): Check maybe_get_template_decl_from_type_decl.

[pushed] c++: variable tmpl partial specialization [PR108468]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Generally we expect TPARMS_PRIMARY_TEMPLATE to be set, but sometimes it isn't for partial instantiations. This ought to be improved, but it's trivial to work around it in this case. PR c++/108468 gcc/cp/ChangeLog: *

Re: [PATCH 2/2] c++: redeclaring member of constrained class template [PR96830]

On 3/14/23 12:41, Patrick Palka wrote: When redeclaring a member of a constrained class template, we need to repeat the class's constraints, but it turns out we don't verify anywhere that the repeated constraints match the class's constraints. A safe place to do so seems to be in

[pushed] c++: -Wreturn-type with if (true) throw [PR107310]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- I removed this folding in GCC 12 because it was interfering with an experiment of richi's, but that never went in and the change causes regressions, so let's put it back. This reverts commit r12-5638-ga3e75c1491cd2d. PR c++/107310

Re: [PATCH] gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634]

On 3/14/23 11:42, Jakub Jelinek wrote: Hi! On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote: The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke gdbhooks, which expects tree_code_type to always be available. I considered trying to make gdbhooks more

Ping Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]

On 3/8/23 11:54, Jason Merrill wrote: On 3/8/23 11:15, Jason Merrill wrote: On 3/8/23 10:53, Jan Hubicka wrote: Tested x86_64-pc-linux-gnu.  Does this look good, or do we want to factor the flag clearing into a symtab_node counterpart to cgraph_node::reset? -- 8< -- In 107897, by the time

Re: [PATCH] c++: Treat unnamed bitfields as padding for __has_unique_object_representations [PR109096]

On 3/14/23 03:58, Jakub Jelinek wrote: Hi! As reported in the PR, for __has_unique_object_representations we were treating unnamed bitfields as named ones, which is wrong, they are actually padding. THe following patch fixes that. Ok for trunk (and what about release branches later?)? OK.

Re: [PATCH] testsuite: Fix up g++.dg/cpp2a/concepts-lambda3.C [PR108972]

On 3/14/23 03:54, Jakub Jelinek wrote: Hi! On Fri, Mar 10, 2023 at 01:49:38PM -0500, Jason Merrill via Gcc-patches wrote: gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda3.C: Run at lower std levels, but expect errors. I'm seeing +UNRESOLVED: g++.dg/cpp2a/concepts

Re: [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634]

On 3/13/23 16:15, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke gdbhooks, which expects tree_code_type to always be available. I considered trying to make gdbhooks more robust, but it seemed

[pushed] c++: handle _FloatNN redeclaration like bool [PR107128]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- It's been inconvenient to compile testcases preprocessed with GCC 12 or earlier because they break on typedef __float128 _Float128; We already had code for handling this with bool and wchar_t, it just needs to be extended to _FloatNN as

[PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634]

Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke gdbhooks, which expects tree_code_type to always be available. I considered trying to make gdbhooks more robust, but it seemed simpler to define tree_code_type as a

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

On 3/10/23 14:07, Marek Polacek wrote: std::span is a view and therefore should be treated as a reference wrapper class for the purposes of -Wdangling-reference. I'm not sure there's a pattern that we could check for. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK.

Re: [PATCH gcc-{11, 12}] c++: top level bind when rewriting coroutines [PR106188]

On 3/13/23 02:57, Arsen Arsenović wrote: In the edge case of a coroutine not containing any locals, the ifcd/switch temporaries would get added to the coroutine frame, corrupting its layout. To prevent this, we can make sure there is always a BIND_EXPR at the top of the function body, and thus,

[pushed] c++: constrained lambda error-recovery [PR108972]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Better not to ICE after various valid errors. PR c++/108972 gcc/cp/ChangeLog: * lambda.cc (compare_lambda_template_head): Check more for error_mark_node. gcc/testsuite/ChangeLog: *

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

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

Re: [PATCH] c++ testsuite: Add test for PR107703

On 3/10/23 10:43, Jakub Jelinek wrote: Hi! This is on top of the https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html and https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613724.html patches (to be precise, the latter isn't essential for it), I've realized that for the

Re: [PATCH] c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates [PR107558]

On 11/24/22 04:13, Jakub Jelinek wrote: Hi! The following testcase ICEs, because OpenMP lowering for shared clause on l variable with REFERENCE_TYPE creates POINTER_TYPE to REFERENCE_TYPE. The reason is that the automatic variable has non-trivial construction (reference to a lambda) and

Re: [PATCH] c++, abi: Fix up class layout with bitfields [PR109039]

On 3/9/23 14:40, Jakub Jelinek wrote: Hi! The following testcase FAILs, because starting with r12-6028 the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one 8-bit bitfield and one 8-bit char field. The reason is that when end_of_class attempts to compute dsize, it simply

[pushed] c++: class NTTP and nested anon union [PR108566]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were failing to come up with the name for the anonymous union. It seems like unfortunate redundancy, but the ABI does say that the name of an anonymous union is its first named member. PR c++/108566 gcc/cp/ChangeLog:

[pushed] c++: signed __int128_t [PR108099]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The code for handling signed + typedef was breaking on __int128_t, because it isn't a proper typedef: it doesn't have DECL_ORIGINAL_TYPE. PR c++/108099 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Handle non-typedef

[pushed] c++: overloaded fn in contract [PR108542]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- PR c++/108542 gcc/cp/ChangeLog: * class.cc (instantiate_type): Strip location wrapper. gcc/testsuite/ChangeLog: * g++.dg/contracts/contracts-err1.C: New test. --- gcc/cp/class.cc

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

On 3/9/23 14:32, Patrick Palka wrote: On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote: When processing a noexcept, constructors aren't elided: build_over_call has /* It's unsafe to elide the constructor when handling a noexcept-expression, it may evaluate to the

[pushed] c++: allocator temps in list of arrays [PR108773]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The optimization to reuse the same allocator temporary for all string constructor calls was breaking on this testcase, because the temps were already in the argument to build_vec_init, and replacing them with references to one slot got

Re: [PATCH RFC 1/3] c++: add __is_deducible trait [PR105841]

On 2/20/23 11:58, Patrick Palka wrote: On Sat, 18 Feb 2023, Jason Merrill via Gcc-patches wrote: Tested x86_64-pc-linux-gnu. Since this is fixing experimental (C++20) functionality, I think it's reasonable to apply now; I'm interested in other opinions, and thoughts about the user-facing

Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]

On 3/8/23 11:15, Jason Merrill wrote: On 3/8/23 10:53, Jan Hubicka wrote: Tested x86_64-pc-linux-gnu.  Does this look good, or do we want to factor the flag clearing into a symtab_node counterpart to cgraph_node::reset? -- 8< -- In 107897, by the time we are looking at the mangling clash,

Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]

On 3/8/23 10:53, Jan Hubicka wrote: Tested x86_64-pc-linux-gnu. Does this look good, or do we want to factor the flag clearing into a symtab_node counterpart to cgraph_node::reset? -- 8< -- In 107897, by the time we are looking at the mangling clash, the alias has already been removed from

[PATCH RFC] c++: lambda mangling alias issues [PR107897]

Tested x86_64-pc-linux-gnu. Does this look good, or do we want to factor the flag clearing into a symtab_node counterpart to cgraph_node::reset? -- 8< -- In 107897, by the time we are looking at the mangling clash, the alias has already been removed from the symbol table by analyze_functions,

[PATCH] c++: static lambda tsubst [PR108526]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- A missed piece of the patch for static operator(): in tsubst_function_decl, we don't want to replace the first parameter with a new closure pointer if operator() is static. PR c++/108526 PR c++/106651 gcc/cp/ChangeLog:

Re: [PATCH] c++: Fix up ICE in emit_support_tinfo_1 [PR109042]

On 3/7/23 04:07, Jakub Jelinek wrote: Hi! In my recent rtti.cc change I assumed when emitting the support tinfos that the tinfos for the fundamental types haven't been created yet. Normally (in libsupc++.a (fundamental_type_info.o)) that is the case, but as can be seen on the testcase, one can

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

On 3/6/23 18:59, Marek Polacek wrote: When processing a noexcept, constructors aren't elided: build_over_call has /* It's unsafe to elide the constructor when handling a noexcept-expression, it may evaluate to the wrong value (c++/53025). */ &&

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

On 3/6/23 17:01, Marek Polacek wrote: On Mon, Mar 06, 2023 at 11:12:56AM -0500, Jason Merrill wrote: On 3/3/23 12:51, Marek Polacek wrote: Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl can call check_initializer even in a template for a constexpr initializer.

Re: [PATCH v6] c++: -Wdangling-reference with reference wrapper [PR107532]

On 3/6/23 16:54, Marek Polacek wrote: On Fri, Mar 03, 2023 at 09:30:38PM -0500, Jason Merrill wrote: On 3/3/23 12:50, Marek Polacek wrote: switch (TREE_CODE (expr)) { case CALL_EXPR: @@ -13831,7 +13895,8 @@ do_warn_dangling_reference (tree expr) std::pair v =

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

On 3/3/23 12:51, Marek Polacek wrote: Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl can call check_initializer even in a template for a constexpr initializer. Here we are rejecting extern const Q q; template constexpr auto p = q(0); even though q has

Re: [PATCH v5] c++: -Wdangling-reference with reference wrapper [PR107532]

On 3/3/23 12:50, Marek Polacek wrote: On Fri, Mar 03, 2023 at 11:25:06AM -0500, Jason Merrill wrote: On 3/2/23 16:24, Marek Polacek wrote: On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote: @@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t) const int& y = (f(1), 42);

Re: [PATCH v4] c++: -Wdangling-reference with reference wrapper [PR107532]

On 3/2/23 16:24, Marek Polacek wrote: On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote: @@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t) const int& y = (f(1), 42); // NULL_TREE const int& z = f(f(1)); // f(f(1)) - EXPR is the initializer. */ + EXPR is the

Re: [PATCH] c++: thinko in extract_local_specs [PR108998]

On 3/3/23 09:58, Patrick Palka wrote: In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make extract_local_specs walk the given pattern twice, ignoring unevaluated operands the first time around so that we prefer to process a local specialization in an evaluated context if it

Re: [PATCH] c++, v2: Don't defer local statics initialized with constant expressions [PR108702]

On 3/3/23 10:18, Jakub Jelinek wrote: On Thu, Mar 02, 2023 at 11:48:04AM -0500, Jason Merrill wrote: The stmtexpr19.C testcase used to be rejected as it has a static variable in statement expression in constexpr context, but as that static variable is initialized by constant expression, when

Re: [PATCH] c++, debug: Fix up locus of DW_TAG_imported_module [PR108716]

On 2/9/23 03:41, Jakub Jelinek wrote: Hi! Before IMPORTED_DECL has been introduced in PR37410, we used to emit correct DW_AT_decl_line on DW_TAG_imported_module on the testcase below, after that change we haven't emitted it at all for a while and after some time started emitting incorrect

Re: [PATCH] c++: Don't defer local statics initialized with constant expressions [PR108702]

On 2/9/23 11:14, Jakub Jelinek wrote: Hi! The stmtexpr19.C testcase used to be rejected as it has a static variable in statement expression in constexpr context, but as that static variable is initialized by constant expression, when P2647R1 was implemented we agreed to make it valid. Now, as

Re: [PATCH] c++: more mce_false folding from cp_fully_fold_init [PR108243]

On 2/21/23 14:10, Patrick Palka wrote: We should also fold the overall initializer passed to cp_fully_fold_init with mce_false, which enables folding of the copy-initialization of 'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR). Unfortunately this doesn't help with

Re: [PATCH] c++: constant non-copy-init is manifestly constant [PR108243]

On 2/21/23 15:18, Patrick Palka wrote: On Mon, 20 Feb 2023, Patrick Palka wrote: According to [basic.start.static]/2 and [expr.const]/2, a variable with static storage duration initialized with a constant initializer has constant initialization, and such an initializer is manifestly

Re: [PATCH] c++, v3: Emit fundamental tinfos for _Float16/decltype(0.0bf16) types on ia32 with -mno-sse2 [PR108883]

On 3/2/23 06:20, Jakub Jelinek wrote: Hi! On Wed, Mar 01, 2023 at 05:50:47PM -0500, Jason Merrill wrote: And then there is a question whether we want to emit rtti for _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless of whether the target supports them at all or not.

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

On 3/1/23 17:33, Marek Polacek wrote: On Wed, Mar 01, 2023 at 04:44:12PM -0500, Jason Merrill wrote: On 3/1/23 16:40, Marek Polacek wrote: On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote: On 3/1/23 15:33, Marek Polacek wrote: -Wmismatched-tags warns about the (harmless)

Re: [PATCH] debug/108772 - ICE with late debug generated with -flto

On 3/2/23 02:43, Richard Biener wrote: On Wed, 1 Mar 2023, Jason Merrill wrote: On 3/1/23 08:09, Jakub Jelinek wrote: On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote: When combining -g1 with -flto we run into the DIE location annotation machinery for globals calling

Re: [PATCH] c++: Add target hook for emit_support_tinfos [PR108883]

On 2/27/23 18:51, Jakub Jelinek wrote: On Mon, Feb 27, 2023 at 06:26:04PM -0500, Jason Merrill wrote: The following patch instead adds a target hook which allows the backend to temporarily tweak registered types such that emit_support_tinfos emits whatever is needed. Why handle these types

Re: [PATCH v4] c++: -Wdangling-reference with reference wrapper [PR107532]

On 2/7/23 11:46, Marek Polacek wrote: On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote: On 1/24/23 17:49, Marek Polacek wrote: On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote: On 1/19/23 21:03, Marek Polacek wrote: On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

On 3/1/23 16:40, Marek Polacek wrote: On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote: On 3/1/23 15:33, Marek Polacek wrote: -Wmismatched-tags warns about the (harmless) struct/class mismatch. For, e.g., template struct A { }; class A a; it works by adding A to the

Re: [PATCH 1/2] c++: factor out TYPENAME_TYPE substitution

On 2/21/23 19:05, Patrick Palka wrote: On Sun, 19 Feb 2023, Jason Merrill wrote: On 2/15/23 12:11, Patrick Palka wrote: On Wed, 15 Feb 2023, Jason Merrill wrote: On 2/15/23 09:21, Patrick Palka wrote: On Tue, 14 Feb 2023, Jason Merrill wrote: On 2/13/23 09:23, Patrick Palka wrote: [N.B.

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

On 3/1/23 15:33, Marek Polacek wrote: -Wmismatched-tags warns about the (harmless) struct/class mismatch. For, e.g., template struct A { }; class A a; it works by adding A to the class2loc hash table while parsing the class-head and then, while parsing the elaborate type-specifier, we

Re: [PATCH] c++: can't eval PTRMEM_CST in incomplete class [PR107574]

On 2/2/23 19:28, Marek Polacek wrote: Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't been completed yet, but that doesn't work: /* We can't lower this until the class is complete. */ if (!COMPLETE_TYPE_P (DECL_CONTEXT (member))) return cst;

Re: [PATCH] debug/108772 - ICE with late debug generated with -flto

On 3/1/23 08:09, Jakub Jelinek wrote: On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote: When combining -g1 with -flto we run into the DIE location annotation machinery for globals calling dwarf2out_late_global_decl but not having any early generated DIE for function scope statics.

Re: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

On 3/1/23 12:20, Patrick Palka wrote: On Wed, 1 Mar 2023, Jason Merrill wrote: On 3/1/23 10:32, Patrick Palka wrote: On Mon, 27 Feb 2023, Jason Merrill wrote: On 2/22/23 14:45, Patrick Palka wrote: Here we're mishandling the unevaluated array new-expressions due to a supposed non-constant

Re: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

On 3/1/23 10:32, Patrick Palka wrote: On Mon, 27 Feb 2023, Jason Merrill wrote: On 2/22/23 14:45, Patrick Palka wrote: Here we're mishandling the unevaluated array new-expressions due to a supposed non-constant array size ever since r12-5253-g4df7f8c79835d569, made us no longer perform

Re: [PATCH] c++: Don't recurse on DECL_INITIAL for DECL_EXPR on non-VAR_DECLs [PR108606]

On 2/22/23 04:06, Jakub Jelinek wrote: Hi! The r13-2965-g73d9b0e5947e16 change changed the line touched in this patch from return RECUR (tmp, want_rval); to return RECUR (DECL_INITIAL (tmp), want_rval); This is on DECL_EXPR handling code, where tmp can be lots of different trees

Re: [PATCH] [vxworks] make wint_t and wchar_t the same distinct type

On 2/22/23 10:23, Alexandre Oliva wrote: Hello, Jason, On Feb 17, 2023, Jason Merrill wrote: On 2/17/23 23:04, Alexandre Oliva wrote: We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and wchar_t mapped to the same underlying type, but this caused a glitch in

Re: [PATCH] Accept pmf-vbit-in-delta extra warning

On 2/22/23 11:03, Alexandre Oliva wrote: On Feb 17, 2023, Jason Merrill wrote: On 2/17/23 23:02, Alexandre Oliva wrote: cp_build_binary_op, that issues -Waddress warnings, issues an extra warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect when comparing a

Re: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

On 2/22/23 14:45, Patrick Palka wrote: Here we're mishandling the unevaluated array new-expressions due to a supposed non-constant array size ever since r12-5253-g4df7f8c79835d569, made us no longer perform constant evaluation of non-manifestly-constant expressions within unevaluated contexts.

Re: [PATCH] c++: Add target hook for emit_support_tinfos [PR108883]

On 2/23/23 05:23, Jakub Jelinek wrote: Hi! _Float16 and decltype(0.0bf16) types are on x86 supported only with -msse2. On x86_64 that is the default, but on ia32 it is not. We should still emit fundamental type tinfo for those types in libsupc++.a/libstdc++.*, regardless of whether

Re: [PATCH] c++: Fix up -fcontracts option description [PR108890]

On 2/23/23 05:26, Jakub Jelinek wrote: Hi! This translation PR mentioned the description is a little bit weird. Ok for trunk? OK. 2023-02-23 Jakub Jelinek PR translation/108890 * c.opt (fcontracts): Fix description. --- gcc/c-family/c.opt.jj 2023-02-01

Re: [PATCH] c++: variable template and targ deduction [PR108550]

On 2/23/23 10:54, Marek Polacek wrote: On Thu, Feb 23, 2023 at 10:17:22AM -0500, Patrick Palka wrote: On Wed, 22 Feb 2023, Marek Polacek wrote: In this test, we get a bogus error because we failed to deduce the auto in constexpr auto is_pointer_v = is_pointer::value; to bool. Then

Re: [PATCH] c++: non-dependent variable template-id [PR108848]

On 2/23/23 16:52, Patrick Palka wrote: Here we're incorrectly treating the non-dependent variable template-id tag as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR an empty type which causes the call to finish_template_variable from finish_id_expression_1 to be dead code at template

Re: [PATCH] c++: ICE with constexpr variable template [PR107938]

On 2/23/23 18:51, Marek Polacek wrote: Since r11-557, cp_finish_decl can call check_initializer even in a template for a constexpr initializer. That ultimately leads to convert_for_assignment and check_address_or_pointer_of_packed_member, where we crash, because it doesn't expect that the

Re: [PATCH] Skip module_cmi_p and related unsupported module test

On 2/17/23 22:55, Alexandre Oliva wrote: When a multi-source module is found to be unsupported, we fail module_cmi_p and subsequent sources. Override proc unsupported to mark the result in module_do, and test it to skip module_cmp_p and subsequent related tests. Hmm, I guess the problem that

Re: [PATCH 1/2] c++: factor out TYPENAME_TYPE substitution

On 2/15/23 12:11, Patrick Palka wrote: On Wed, 15 Feb 2023, Jason Merrill wrote: On 2/15/23 09:21, Patrick Palka wrote: On Tue, 14 Feb 2023, Jason Merrill wrote: On 2/13/23 09:23, Patrick Palka wrote: [N.B. this is a corrected version of

Re: [PATCH] c++: ICE with -fno-elide-constructors and trivial fn [PR101073]

On 2/15/23 13:37, Marek Polacek wrote: On Wed, Feb 15, 2023 at 02:39:16PM -0500, Jason Merrill wrote: On 2/9/23 09:39, Marek Polacek wrote: In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide the Y::Y(const Y&) call used to initialize o.c. So store_init_value ->

Re: [PATCH v3] c++: ICE with redundant capture [PR108829]

On 2/17/23 14:42, Marek Polacek wrote: On Fri, Feb 17, 2023 at 04:32:50PM -0500, Patrick Palka wrote: On Fri, 17 Feb 2023, Patrick Palka wrote: On Fri, 17 Feb 2023, Marek Polacek wrote: On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote: On Fri, 17 Feb 2023, Marek Polacek via

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