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

On 5/26/23 19:18, Marek Polacek wrote: Since r8-509, we'll no longer create a static temporary var for the initializer '{ 1, 2 }' for num in the attached test because the code in finish_compound_literal is now guarded by '&& fcl_context == fcl_c99' but it's fcl_functional here. This causes us to

Re: [PATCH] c++: mangle noexcept-expr [PR70790]

On 5/19/23 15:10, Patrick Palka wrote: On Fri, 19 May 2023, Patrick Palka wrote: This implements noexcept-expr mangling (and demangling) as per the Itanium ABI. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? PR c++/70790 gcc/cp/ChangeLog: * m

Re: [PATCH] tree: Fix up save_expr [PR52339]

On 5/13/23 06:58, Eric Botcazou wrote: I think we really need Eric (as one who e.g. introduced the DECL_INVARIANT_P apparently for this kind of stuff) to have a look at that on the Ada side. I have been investigating this for a few days and it's no small change for Ada and probably for other la

Re: [PATCH] tree: Fix up save_expr [PR52339]

On 5/30/23 04:23, Jakub Jelinek wrote: On Tue, May 30, 2023 at 10:03:05AM +0200, Eric Botcazou wrote: We want to be able to treat such things as invariant somehow even if we can't do that for references to user data that might be changed by intervening code. That is, indicate that we know that

Re: [PATCH] tree: Fix up save_expr [PR52339]

On 5/30/23 16:51, Jakub Jelinek wrote: On Tue, May 30, 2023 at 04:36:34PM -0400, Jason Merrill wrote: Note that it is fine to treat p->fld as invariant in C++ if fld is TREE_READONLY and p is itself invariant. The implementation is allowed to assume that other code didn't destroy *p and create

[PATCH] libstdc++: optimize EH phase 2

Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- In the ABI's two-phase EH model, first we walk the stack looking for a handler, then we walk the stack running cleanups until we reach that handler. In the cleanup phase, we shouldn't redundantly check the handlers along the way, e.g. when walki

[pushed] c++: make -fpermissive avoid -Werror=narrowing

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Currently we make -Wnarrowing an error by default by forcing pedantic_errors on, but for consistency -fpermissive should prevent that. In general I'm inclined to move away from using permerror in favor of this kind of model, with specific f

[PATCH] doc: improve docs for -pedantic{,-errors}

Tested by looking at the makeinfo output. OK for trunk? -- 8< -- Recent discussion of -Wimplicit led me to want to clarify this section of the documentation, and mark which diagnostics other than -Wpedantic are affected by -pedantic-errors. gcc/ChangeLog: * doc/invoke.texi (-Wpedantic)

[PATCH RFA] c++: make initializer_list array static again [PR110070]

I ended up deciding not to apply the DECL_NOT_OBSERVABLE patch that you approved in stage 3 because I didn't feel like it was fully baked; I'm happy with this version now, which seems like a more broadly useful flag. Tested x86_64-pc-linux-gnu. OK for trunk? -- 8< -- After the maybe_init_list_a

[PATCH RFA] varasm: check float size

Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- In PR95226, the testcase was failing because we tried to output_constant a NOP_EXPR to float from a double REAL_CST, and so we output a double where the caller wanted a float. That doesn't happen anymore, but with the output_constant hunk we wil

[pushed] c++: fix explicit/copy problem [PR109247]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In the testcase, the user wants the assignment to use the operator= declared in the class, but because [over.match.list] says that explicit constructors are also considered for list-initialization, as affirmed in CWG1228, we end up choosing

Re: [PATCH] c++: bad 'this' conversion for nullary memfn [PR106760]

On 6/2/23 11:55, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for trunk? -- >8 -- Here we notice the 'this' conversion for the call f() is bad, so we correctly defer instantiating it, but we end up never adding it to 'bad_fns' since missing_conversio

Re: [PATCH] c++: replace in_template_function

On 6/2/23 11:15, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- All uses of in_template_function besides the one in cp_make_fname_decl seem like they could be generalized to apply to all template contexts, not just function t

Re: [PATCH] c++: simplify TEMPLATE_TEMPLATE_PARM hashing

On 6/2/23 10:29, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- r10-7815-gaa576f2a860c82 added special hashing for TEMPLATE_TEMPLATE_PARM since non-lowered ttps had TYPE_CANONICAL but level lowered ttps did not. But this is n

Re: [PATCH] c++: is_specialization_of_friend confusion [PR109923]

On 6/2/23 10:29, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- The check for a non-template member function of a class template in is_specialization_of_friend is overbroad, and accidentally holds for a non-template hidden fr

PING Re: [PATCH RFA (tree-eh)] c++: use __cxa_call_terminate for MUST_NOT_THROW [PR97720]

Since Jonathan approved the library change, I'm looking for middle-end approval for the tree-eh change, even without advice on the potential follow-up. On 5/24/23 14:55, Jason Merrill wrote: Middle-end folks: any thoughts about how best to make the change described in the last paragraph below?

Re: PING Re: [PATCH RFA (tree-eh)] c++: use __cxa_call_terminate for MUST_NOT_THROW [PR97720]

On 6/5/23 02:09, Richard Biener wrote: On Fri, Jun 2, 2023 at 6:57 PM Jason Merrill via Gcc-patches wrote: Since Jonathan approved the library change, I'm looking for middle-end approval for the tree-eh change, even without advice on the potential follow-up. On 5/24/23 14:55, Jason Me

Re: [PATCH] c++: extend lookup_template_class shortcut [PR110122]

On 6/5/23 17:26, Patrick Palka wrote: Here when substituting the injected class name A during regeneration of the lambda, we find ourselves in lookup_template_class for A with V=_ZTAXtl3BarEE (i.e. the template parameter object for Foo{}). The call to coerce_template_parms within then undesirabl

[pushed] c++: add NRV testcase [PR58050]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- This was fixed in GCC 10. PR c++/58050 gcc/testsuite/ChangeLog: * g++.dg/opt/nrv24.C: New test. --- gcc/testsuite/g++.dg/opt/nrv24.C | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 gcc/testsu

[pushed] c++: fix contracts with NRV

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The NRV implementation was blindly replacing the operand of RETURN_EXPR, clobbering anything that check_return_expr might have added on to the actual initialization, such as checking the postcondition. gcc/cp/ChangeLog: * semantics

[pushed] c++: fix throwing cleanup with label

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While looking at PR92407 I noticed that the expectations of maybe_splice_retval_cleanup weren't being met; an sk_cleanup level was confusing its attempt to recognize the outer block of the function. And even if I fixed the detection, it fai

[pushed] c++: enable NRVO from inner block [PR51571]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Our implementation of the named return value optimization has been limited to variables declared in the outermost block of the function, to avoid needing to handle the case where the variable needs to be destroyed due to going out of scope.

[pushed] c++: Add -Wnrvo

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While looking at PRs about cases where we don't perform the named return value optimization, it occurred to me that it might be useful to have a warning for that. This does not fix PR58487, but might be interesting to people watching it.

[pushed] c++: NRV and goto [PR92407]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here our named return value optimization was breaking the required destructor when the goto takes 'a' out of scope. The simplest fix is to disable the optimization in the presence of user labels. We could do better by disabling the optimiz

Re: [PATCH] c++: unsynthesized defaulted constexpr fn [PR110122]

On 6/6/23 14:29, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- In the second testcase of PR110122, during regeneration of the generic lambda with V=Bar{}, substitution followed by coerce_template_parms for A's template argument nat

[pushed] c++: allow NRV and non-NRV returns [PR58487]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Now that we support NRV from an inner block, we can also support non-NRV returns from other blocks, since once the NRV is out of scope a later return expression can't possibly alias it. This fixes 58487 and half-fixes 53637: now one of the

Re: [PATCH RFC] c++: use __cxa_call_terminate for MUST_NOT_THROW [PR97720]

On Thu, Jun 8, 2023 at 9:13 AM Jonathan Wakely wrote: > > On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote: > >> >> >> On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ < >> libstd...@gcc.gnu.org> wrote: >> >>> Middle-end folks: any thoughts about how best to make the change >>> descri

Re: [PATCH][RFC] c++: Accept elaborated-enum-base in system headers

On 6/8/23 07:06, Alex Coplan wrote: Hi, macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code of the form: typedef enum T : BaseType T; i.e. an elaborated-type-specifier with an additional enum-base. Upstream LLVM can be made to accept the above construct with -Wno-error=ela

Re: [PATCH] c++: unsynthesized defaulted constexpr fn [PR110122]

On 6/8/23 15:54, Patrick Palka wrote: On Wed, 7 Jun 2023, Jason Merrill wrote: On 6/6/23 14:29, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- In the second testcase of PR110122, during regeneration of the generic lambda with V=B

[pushed] c++: init-list of uncopyable type [PR110102]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The maybe_init_list_as_range optimization is a form of copy elision, but we can only elide well-formed copies. PR c++/110102 gcc/cp/ChangeLog: * call.cc (maybe_init_list_as_array): Check that the element type is co

[pushed] c++: diagnose auto in template arg

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were failing to diagnose this Concepts TS feature that didn't make it into C++20 because the 'auto' was getting converted to a template parameter before we checked for it. So also check in cp_parser_simple_type_specifier. The code in cp

[pushed] c++: fix 32-bit spaceship failures [PR110185]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Various spaceship tests failed after r14-1624. This turned out to be because the comparison category classes return in memory on 32-bit targets, and the synthesized operator<=> looks something like if (auto v = a.x <=> b.x, v == 0); else r

[pushed] c++: build initializer_list in a loop [PR105838]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- I previously applied this change in r13-4565 but reverted it due to PR108071. That PR was then fixed by r13-4712, but I didn't re-apply this change then because we weren't making the array static; since r14-1500 for PR110070 we now make the

Re: [r14-1624 Regression] FAIL: std/time/year_month_day_last/1.cc (test for excess errors) on Linux/x86_64

This should be fixed by r14-1660-g953bbeaeff050f On Sun, Jun 11, 2023 at 11:33 PM haochen.jiang wrote: > On Linux/x86_64, > > 28db36e2cfca1b7106adc8d371600fa3a325c4e2 is the first bad commit > commit 28db36e2cfca1b7106adc8d371600fa3a325c4e2 > Author: Jason Merrill > Date: Wed Jun 7 05:15:02 2

Re: [PATCH] c, c++: Accept __builtin_classify_type (typename)

On 6/12/23 15:57, Jakub Jelinek wrote: Hi! As mentioned in my stdckdint.h mail, __builtin_classify_type has a problem that argument promotion (the argument is passed to ... prototyped builtin function) means that certain type classes will simply never appear. I think it is too late to change how

[pushed] c++: mutable temps in rodata

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- If the type of a temporary has mutable members, we can't set TREE_READONLY on the VAR_DECL; this is parallel to the check in cp_apply_type_quals_to_decl. gcc/cp/ChangeLog: * tree.cc (build_target_expr): Check TYPE_HAS_MUTABLE_P. g

[PATCH] c++: tweak c++17 ctor/conversion tiebreaker [DR2327]

In discussion of this issue CWG decided that the change of behavior on well-formed code like overload-conv-4.C is undesirable. In further discussion of possible resolutions, we discovered that we can avoid that change while still getting the desired behavior on overload-conv-3.C by making this a t

Re: [PATCH v2] c++: Accept elaborated-enum-base in system headers

On 6/14/23 09:31, Alex Coplan wrote: Hi, This is a v2 patch addressing feedback for: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621050.html macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code of the form: typedef enum T : BaseType T; i.e. an elaborated-type-speci

Re: [PATCH] libcpp: Diagnose #include after failed __has_include [PR80753]

On 6/13/23 12:29, Jakub Jelinek wrote: Hi! As can be seen in the testcase, we don't diagnose #include/#include_next of a non-existent header if __has_include/__has_include_next is done for that header first. The problem is that we normally error the first time some header is not found, but in th

Re: [PATCH] c++: redundant targ coercion for var/alias tmpls

On 7/13/23 11:48, Patrick Palka wrote: On Wed, 28 Jun 2023, Patrick Palka wrote: On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote: On 6/23/23 12:23, Patrick Palka wrote: On Fri, 23 Jun 2023, Jason Merrill wrote: On 6/21/23 13:19, Patrick Palka wrote: When stepping through the variabl

Re: [PATCH v3 1/3] c++: Track lifetimes in constant evaluation [PR70331,PR96630,PR98675]

On 6/30/23 23:28, Nathaniel Shead via Gcc-patches wrote: This adds rudimentary lifetime tracking in C++ constexpr contexts, Thanks! I'm not seeing either a copyright assignment or DCO certification for you; please see https://gcc.gnu.org/contribute.html#legal for more information. diff --

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

On 7/13/23 14:54, Marek Polacek wrote: On Fri, May 26, 2023 at 09:47:10PM -0400, Jason Merrill wrote: On 5/26/23 19:18, Marek Polacek wrote: The is_really_empty_class check is sort of non-obvious but the comment should explain why I added it. + /* When there's nothing to initializ

Re: [PATCH] c++: redundant targ coercion for var/alias tmpls

On 7/14/23 14:07, Patrick Palka wrote: On Thu, 13 Jul 2023, Jason Merrill wrote: On 7/13/23 11:48, Patrick Palka wrote: On Wed, 28 Jun 2023, Patrick Palka wrote: On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote: On 6/23/23 12:23, Patrick Palka wrote: On Fri, 23 Jun 2023, Jason Merril

Re: [PATCH] c++: copy elision of object arg in static memfn call [PR110441]

On 7/13/23 14:49, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- Here the call A().f() is represented as a COMPOUND_EXPR whose first operand is the otherwise unused object argument A() and second operand is the call result (b

Re: [PATCH] c++: mangling template-id of unknown template [PR110524]

On 7/13/23 09:20, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 13? OK for both. -- >8 -- This fixes a crash when mangling an ADL-enabled call to a template-id naming an unknown template (as per P0846R0). PR c++/11052

[pushed] c++: c++26 regression fixes

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Apparently I wasn't actually running the testsuite in C++26 mode like I thought I was, so there were some failures I wasn't seeing. The constexpr hunk fixes regressions with the P2738 implementation; we still need to use the old handling fo

Re: [PATCH v3 1/3] c++: Track lifetimes in constant evaluation [PR70331,PR96630,PR98675]

On 7/14/23 11:16, Jason Merrill wrote: I'm not seeing either a copyright assignment or DCO certification for you; please see https://gcc.gnu.org/contribute.html#legal for more information. Oops, now I see the DCO sign-off, not sure how I was missing it. Jason

Re: [WIP RFC] Add support for keyword-based attributes

On Sun, Jul 16, 2023 at 6:50 AM Richard Sandiford wrote: > Jakub Jelinek writes: > > On Fri, Jul 14, 2023 at 04:56:18PM +0100, Richard Sandiford via > Gcc-patches wrote: > >> Summary: We'd like to be able to specify some attributes using > >> keywords, rather than the traditional __attribute__ o

Re: [PATCH v3 1/3] c++: Track lifetimes in constant evaluation [PR70331,PR96630,PR98675]

On 7/16/23 09:47, Nathaniel Shead wrote: On Fri, Jul 14, 2023 at 11:16:58AM -0400, Jason Merrill wrote: What if, instead of removing the variable from one hash table and adding it to another, we change the value to, say, void_node? I have another patch I'm working on after this which does see

Re: [PATCH] c++: non-standalone surrogate call template

On 7/12/23 14:47, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? There might be an existing PR for this issue but Bugzilla search seems to be timing out for me currently. OK. -- >8 -- I noticed we were accidentally preventing ourselves f

Re: [PATCH] c++: constrained surrogate calls [PR110535]

On 7/12/23 11:54, Patrick Palka wrote: On Wed, 12 Jul 2023, Patrick Palka wrote: We're not checking constraints of pointer/reference-to-function conversion functions during overload resolution, which causes us to ICE on the first testcase and incorrectly reject the second testcase. Er, I noti

[pushed] c++: only cache constexpr calls that are constant exprs

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In reviewing Nathaniel's patch for PR70331, it occurred to me that instead of looking for various specific problematic things in the result of a constexpr call to decide whether to cache it, we should use reduced_constant_expression_p. The

[PATCH RFA (fold)] c++: constexpr bit_cast with empty field

Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- The change to only cache constexpr calls that are reduced_constant_expression_p tripped on bit-cast3.C, which failed that predicate due to the presence of an empty field in the result of native_interpret_aggregate, which reduced_constant_expressi

[FYI] c++: check for trying to cache non-constant expressions

Just for reference, not applying. -- 8< -- This is what I used to check for what non-constant results we were previously caching. After the previous two patches it's just address of a local and a partially-uninitialized COMPLEX_EXPR. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_call_expr

Re: [PATCH] c++: deducing empty type vs non-type argument pack

On 7/18/23 11:18, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Also verified by way of gcc_assert that we never see TEMPLATE_PARM_INDEX here. OK. -- >8 -- Within a template parameter list, a non-type template parameter pack is represen

Re: [PATCH RFA (fold)] c++: constexpr bit_cast with empty field

On 7/18/23 07:31, Richard Biener wrote: On Mon, Jul 17, 2023 at 11:20 PM Jason Merrill via Gcc-patches wrote: Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- The change to only cache constexpr calls that are reduced_constant_expression_p tripped on bit-cast3.C, which failed t

Re: [PATCH] c++: redundant targ coercion for var/alias tmpls

On 7/17/23 17:29, Patrick Palka wrote: On Fri, 14 Jul 2023, Jason Merrill wrote: On 7/14/23 14:07, Patrick Palka wrote: On Thu, 13 Jul 2023, Jason Merrill wrote: On 7/13/23 11:48, Patrick Palka wrote: On Wed, 28 Jun 2023, Patrick Palka wrote: On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill

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

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

Re: [PATCH v2] libcpp: Handle extended characters in user-defined literal suffix [PR103902]

On 3/2/23 18:07, Lewis Hyatt wrote: The PR complains that we do not handle UTF-8 in the suffix for a user-defined literal, such as: bool operator ""_π (unsigned long long); In fact we don't handle any extended identifier characters there, whether UTF-8, UCNs, or the $ sign. We do handle it fine

Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies

On 6/25/23 12:36, Ben Boeckel wrote: On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote: On 6/22/23 22:45, Ben Boeckel wrote: On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote: On 1/25/23 16:06, Ben Boeckel wrote: They affect the build, so report them via `-MF` mechanisms.

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

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

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

On 7/19/23 15:20, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. We might also improve the diagnostic for base classes, perhaps by teaching dump_simple_decl about DECL_FIELD_IS_BASE? -- >8 -- Let's suppress -Wmissing-field-initializers for empty clas

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

On 7/19/23 17:51, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK, thanks. -- >8 -- This patch changes warning: missing initializer for member 'D::' [-Wmissing-field-initializers] to warning: missing initializer for member 'D::B' [-Wmissing-fiel

Re: [PATCH] c++: passing partially inst tmpl as ttp [PR110566]

On 7/19/23 14:05, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13? -- >8 -- Since the arguments 'pargs' passed to the coerce_template_parms from coerce_template_template_parms are always a full set, we need to make sure we always pass the p

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

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

Re: [PATCH v4 1/3] c++: Track lifetimes in constant evaluation [PR70331,PR96630,PR98675]

On 7/20/23 05:35, Nathaniel Shead wrote: This adds rudimentary lifetime tracking in C++ constexpr contexts, allowing the compiler to report errors with using values after their backing has gone out of scope. We don't yet handle other ways of accessing values outside their lifetime (e.g. following

Re: [PATCH v4 2/3] c++: Improve constexpr error for dangling local variables [PR110619]

On 7/20/23 05:36, Nathaniel Shead wrote: Currently, when typeck discovers that a return statement will refer to a local variable it rewrites to return a null pointer. This causes the error messages for using the return value in a constant expression to be unhelpful, especially for reference retur

Re: [PATCH v4 3/3] c++: Improve location information in constant evaluation

On 7/20/23 05:37, Nathaniel Shead wrote: This patch updates 'input_location' during constant evaluation to ensure that errors in subexpressions that lack location information still provide accurate diagnostics. By itself this change causes some small regressions in diagnostic quality for circums

Re: [PATCH] c++: passing partially inst tmpl as ttp [PR110566]

On 7/20/23 12:00, Patrick Palka wrote: On Wed, 19 Jul 2023, Jason Merrill wrote: On 7/19/23 14:05, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13? -- >8 -- Since the arguments 'pargs' passed to the coerce_template_parms from coerce_temp

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

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

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

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

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

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

Re: [PATCH 2/1] c++: passing partially inst ttp as ttp [PR110566]

On 7/21/23 14:34, Patrick Palka wrote: (This is a follow-up of https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624951.html) Bootstrapped and regtested on x86_64-pc-linux-gnu, how does this look? -- >8 -- The previous fix doesn't work for partially instantiated ttps primarily because most_g

Re: [PATCH v4 2/3] c++: Improve constexpr error for dangling local variables [PR110619]

On 7/21/23 01:39, Nathaniel Shead wrote: On Thu, Jul 20, 2023 at 11:46:47AM -0400, Jason Merrill wrote: On 7/20/23 05:36, Nathaniel Shead wrote: Currently, when typeck discovers that a return statement will refer to a local variable it rewrites to return a null pointer. This causes the error me

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

On 7/21/23 18:38, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- This code in cxx_eval_array_reference has been hard to get right. In r12-2304 I added some code; in r13-5693 I removed some of it. Here the problematic line is "S s = arr[0];" which

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

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

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

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

Re: [PATCH 2/1] c++: passing partially inst ttp as ttp [PR110566]

On 7/24/23 13:03, Patrick Palka wrote: On Fri, 21 Jul 2023, Jason Merrill wrote: On 7/21/23 14:34, Patrick Palka wrote: (This is a follow-up of https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624951.html) Bootstrapped and regtested on x86_64-pc-linux-gnu, how does this look? -- >8 -- The

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

On 7/25/23 15:59, Marek Polacek wrote: On Fri, Jul 21, 2023 at 01:44:17PM -0400, Jason Merrill wrote: On 7/20/23 17:58, Marek Polacek wrote: On Thu, Jul 20, 2023 at 03:51:32PM -0400, Marek Polacek wrote: On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote: On 7/20/23 14:13, Marek Po

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

On 7/25/23 15:55, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- In we concluded that we might clear all flags except tf_warning_or_error when performing instantiate_template

Re: [PATCH 1/2][frontend] Add novector C++ pragma

On 7/19/23 11:15, Tamar Christina wrote: Hi All, FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should not be applied to a particular loop. ICC/ICX also has such a pragma for C and C++ called #pragma novector. As part of this patch series I need a way to easily turn

[pushed] testsuite: run C++11 tests in C++11 mode

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- A recent change missed updating constexpr-mutable3.C because it wasn't run in C++11 mode even though it checks the behavior for { target c++11_only }. gcc/testsuite/ChangeLog: * lib/g++-dg.exp (g++-dg-runtest): Check for c++11_only

Re: [PATCH v5 0/3] c++: Track lifetimes in constant evaluation [PR70331, ...]

On 7/22/23 11:12, Nathaniel Shead wrote: This is an update of the patch series at https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625050.html I applied the patches, with an addition to the first patch to fix constexpr-mutable3.C in C++11 mode, which was not part of the default std set. A

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

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

Re: [PATCH] - Devirtualization of array destruction (C++) - 110057

On 7/12/23 10:10, Ng YongXiang via Gcc-patches wrote: Component: c++ Bug ID: 110057 Bugzilla link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057 Description: Array should not call virtual destructor of object when array is destructed ChangeLog: 2023-07-12 Ng YongXiang PR c++

Re: [PATCH] c++: devirtualization of array destruction [PR110057]

On 7/26/23 12:00, Ng YongXiang wrote: Hi Jason, Thanks for the reply and review. I've attached an updated patch with the change log and sign off. The change made in gcc/testsuite/g++.dg/warn/pr83054.C is because I think there is no more warning since we have already devirtualized the destru

[pushed] c++: member vs global template [PR106310]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- For backward compatibility we still want to allow patterns like this->A::foo, but the template keyword in a qualified name is specifically to specify that a dependent name is a template, so don't look in the enclosing scope at all. Also fix

Re: [PATCH] c++: unifying REAL_CSTs [PR110809]

On 7/26/23 12:57, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13 (after the branch is unfrozen)? OK. -- >8 -- This teaches unify how to compare two REAL_CSTs. PR c++/110809 gcc/cp/ChangeLog: * pt.cc (unify) : Generali

Re: [PATCH] c++: constexpr empty subobject confusion [PR110197]

On 7/26/23 12:57, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13 (later)? OK. -- >8 -- Now that init_subob_ctx no longer sets new_ctx.ctor for a subobject of empty type, it seems we need to ensure its callers cxx_eval_bare_aggregate and

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

On 6/28/23 06:35, Alex Coplan wrote: Hi, This patch implements clang's __has_feature and __has_extension in GCC. This is a v2 of the original RFC posted here: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617878.html Changes since v1: - Follow the clang behaviour where -pedantic-errors

Re: [PATCH 1/2][frontend] Add novector C++ pragma

On 7/26/23 15:32, Tamar Christina wrote: + + cp_token *tok = pragma_tok; + + do { - tok = cp_lexer_consume_token (parser->lexer); - ivdep = cp_parser_pragma_ivdep (parser, tok); - tok = cp_lexer_peek_token (the_parser->lexer); + switch

Re: [PATCH] c-family: Implement pragma_lex () for preprocess-only mode

On 6/30/23 18:59, Lewis Hyatt wrote: In order to support processing #pragma in preprocess-only mode (-E or -save-temps for gcc/g++), we need a way to obtain the #pragma tokens from libcpp. In full compilation modes, this is accomplished by calling pragma_lex (), which is a symbol that must be exp

Re: [PATCH] c++: Fix ICE with parameter pack of decltype(auto) [PR103497]

On 6/30/23 03:05, Nathaniel Shead wrote: On Thu, Jun 29, 2023 at 01:43:07PM -0400, Jason Merrill wrote: On 6/24/23 09:24, Nathaniel Shead wrote: On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote: Hi, On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote: Bootstrapped and te

Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies

On 7/23/23 20:26, Ben Boeckel wrote: On Fri, Jul 21, 2023 at 16:23:07 -0400, Nathan Sidwell wrote: It occurs to me that the model I am envisioning is similar to CMake's object libraries. Object libraries are a convenient name for a bunch of object files. IIUC they're linked by naming the indivi

Re: [PATCH v2] c-family: Implement pragma_lex () for preprocess-only mode

On 7/27/23 18:59, Lewis Hyatt wrote: In order to support processing #pragma in preprocess-only mode (-E or -save-temps for gcc/g++), we need a way to obtain the #pragma tokens from libcpp. In full compilation modes, this is accomplished by calling pragma_lex (), which is a symbol that must be exp

Re: [PATCH] c++: devirtualization of array destruction [PR110057]

On 7/26/23 20:06, Ng YongXiang wrote: Hi Jason, I've made the following changes. 1. Add pr83054-2.C 2. Move the devirt tests to tree-ssa. 3. Remove dg do run for devirt tests 4. Add // PR c++/110057 5. Generate commit message with git gcc-commit-mklog 6. Check commit format with git gcc-verify

Re: [PATCH v2] c-family: Implement pragma_lex () for preprocess-only mode

On 7/28/23 07:14, Lewis Hyatt wrote: On Thu, Jul 27, 2023 at 06:18:33PM -0700, Jason Merrill wrote: On 7/27/23 18:59, Lewis Hyatt wrote: In order to support processing #pragma in preprocess-only mode (-E or -save-temps for gcc/g++), we need a way to obtain the #pragma tokens from libcpp. In ful

[pushed] c++: dependent generic lambda template-id [PR106024]

We were wrongly looking up the generic lambda op() in a dependent scope, and then trying to look up its instantiation at substitution time, but lambdas aren't instantiated, so we crashed. The fix is to not look into dependent class scopes. But this created trouble with wrongly trying to use a tem

[pushed] c++: add fixup to missing .template warning

I experimented with giving this diagnostic in another place, which didn't work out, but we can still benefit from adding the fixup. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * parser.cc (missing_template_diag): Split out... (cp_parser_id_expression): ...fro

[pushed] c++: tweak resolve_args change

I don't know why I used tf_error instead of complain here. PR c++/105779 gcc/cp/ChangeLog: * call.cc (resolve_args): Use complain. --- gcc/cp/call.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc index f1dd8377628..fc98552fda

  1   2   3   4   5   6   7   8   9   10   >