Re: [PATCH] c++: tweaks for explicit conversion fns diagnostic

On 8/25/23 19:37, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- 1) When saying that a conversion is erroneous because it would use an explicit constructor, it might be nice to show where exactly the explicit constructor is located. For example,

Re: [PATCH] c++: Fix up mangling of function/block scope static structured bindings [PR111069]

On 8/22/23 04:12, Jakub Jelinek wrote: As can be seen on the testcase, we weren't correctly mangling static/thread_local structured bindings (C++20 feature) at function/block scope. The following patch fixes that by using what write_local_name does for those cases (note, structured binding

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

On 8/21/23 21:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like a reasonable approach? I didn't observe any compile time/memory impact of this change. -- >8 -- As described in detail in the PR, CWG 2369 has the surprising consequence of

Re: [PATCH] debug/111080 - avoid outputting debug info for unused restrict qualified type

On 8/21/23 05:11, Richard Biener wrote: The following applies some maintainance with respect to type qualifiers and kinds added by later DWARF standards to prune_unused_types_walk. The particular case in the bug is not handling (thus marking required) all restrict qualified type DIEs. I've

Re: [PATCH v7 2/4] p1689r5: initial support

On 7/2/23 12:32, Ben Boeckel wrote: This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Support is communicated through the following three new flags: -

Re: [PATCH v7 1/4] driver: add a spec function to join arguments

extension *also* ends up being its own argument. To perform the desired behavior, the arguments need to be concatenated together. gcc/: * gcc.cc (join_spec_func): Add a spec function to join all arguments. * doc/invoke.texi: Document it. Signed-off-by: Ben Boeckel Co-authored-by: Jason Merrill

[pushed 2/2] c++: maybe_substitute_reqs_for fix

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While working on PR109751 I found that maybe_substitute_reqs_for was doing the wrong thing for a non-template friend, substituting in the template args of the scope's original template rather than those of the instantiation. This didn't end

[pushed 1/2] c++: constrained hidden friends [PR109751]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- r13-4035 avoided a problem with overloading of constrained hidden friends by checking satisfaction, but checking satisfaction early is inconsistent with the usual late checking and can lead to hard errors, so let's not do that after all.

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

On 8/15/23 09:41, Javier Martinez wrote: On Mon, Aug 14, 2023 at 8:32 PM Jason Merrill <mailto:ja...@redhat.com>> wrote: > I think you also want to check for ATTR_FLAG_TYPE_IN_PLACE. > [...] > > +  propagate_class_warmth_attribute (t); > Maybe call this in check_b

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

On 8/11/23 09:18, Javier Martinez wrote: Hi Jason, Regarding the initialization example - no, the set of classes that we consider cold is more loosely defined. On Thu, Aug 10, 2023 at 11:01 PM Jason Merrill <mailto:ja...@redhat.com>> wrote: > Yes, but that's because the implici

Re: [PATCH v1] c++: follow DR 2386 and update implementation of get_tuple_size [PR110216]

On 8/12/23 04:16, gnaggnoyil wrote: DR 2386 updated the tuple_size requirements for structured binding and it now requires tuple_size to be considered only if std::tuple_size names a complete class type with member value. GCC before this patch does not follow the updated requrements, and this

[pushed] c++: -fconcepts and __cpp_concepts

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Since -fconcepts no longer implies -fconcepts-ts, we shouldn't advertise TS support with __cpp_concepts=201507L. Also fix one case where -std=c++14 -fconcepts wasn't working (as found by range-v3 calendar). Fixing other cases is not a

Re: [PATCH] tree-pretty-print: delimit TREE_VEC with braces

On 8/11/23 13:35, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- This makes the generic pretty printer print braces around a TREE_VEC like we do for CONSTRUCTOR. This should improve readability of nested TREE_VECs in particular.

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

On 8/11/23 04:48, Jakub Jelinek wrote: On Fri, Aug 11, 2023 at 01:13:32AM +0200, Jakub Jelinek wrote: Looking at the first uses of the builtin back in 90s in va*.h, it certainly relied on array/function decay there (the macros would abort e.g. on array_type_class, function_type_class and

Re: [PATCH] c++: bogus warning w/ deduction guide in anon ns [PR106604]

On 8/11/23 09:54, Patrick Palka wrote: On Thu, 10 Aug 2023, Jason Merrill wrote: On 8/10/23 16:40, Patrick Palka wrote: On Thu, 10 Aug 2023, Jason Merrill wrote: On 8/10/23 12:09, Patrick Palka wrote: Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk

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

On 8/10/23 11:35, Jakub Jelinek wrote: Hi! I'd like to ping this patch. Reposting it as I found a typo in the documentation - s/builtin-in/built-in/. Bootstrapped/regtested again on x86_64-linux and i686-linux, ok for trunk? On Mon, Jun 12, 2023 at 09:57:17PM +0200, Jakub Jelinek via

Re: [PATCH] c++: dependently scoped template-id in type-req [PR110927]

On 8/10/23 12:08, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 13? OK. -- >8 -- Here we're incorrectly rejecting the first type-requirement at parse time with concepts-requires35.C:14:56: error: ‘typename A::B’ is not a

Re: [PATCH] c++: recognize in-class var tmpl partial spec [PR71954]

On 8/10/23 12:08, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- This makes us recognize variable template partial specializations defined directly inside the class body. It seems to suffice to call

Re: [PATCH] c++: bogus warning w/ deduction guide in anon ns [PR106604]

On 8/10/23 16:40, Patrick Palka wrote: On Thu, 10 Aug 2023, Jason Merrill wrote: On 8/10/23 12:09, Patrick Palka wrote: Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 13? -- >8 -- We shouldn't issue a "declared static but never defined&

Re: [PATCH] c++: improve debug_tree for templated types/decls

On 8/10/23 16:59, Patrick Palka wrote: On Tue, 8 Aug 2023, Jason Merrill wrote: On 7/31/23 20:34, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- gcc/cp/ChangeLog: * ptree.cc (cxx_print_decl): Check for DECL_LANG_SPECI

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

On 8/10/23 14:06, Javier Martinez wrote: Thanks for the comments, Jason. v2: + Fix formatting, remove unnecessarily warning. On Tue, Aug 8, 2023 at 10:28 PM Jason Merrill <mailto:ja...@redhat.com>> wrote: > Seems reasonable, but how do you expect this to be used? We have large

Re: [PATCH] c++: bogus warning w/ deduction guide in anon ns [PR106604]

On 8/10/23 12:09, Patrick Palka wrote: Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 13? -- >8 -- We shouldn't issue a "declared static but never defined" warning for a deduction guide (declared in an anonymous namespace). PR c++/106604

Re: [PATCH] preprocessor: c++: Support `#pragma GCC target' macros [PR87299]

On 7/31/23 22:22, Lewis Hyatt via Gcc-patches wrote: `#pragma GCC target' is not currently handled in preprocess-only mode (e.g., when running gcc -E or gcc -save-temps). As noted in the PR, this means that if the target pragma defines any macros, those macros are not effective in

Re: [PATCH] c++: parser cleanup, remove dummy arguments

On 7/31/23 17:52, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Now that cp_parser_constant_expression accepts a null non_constant_p, we can transitively remove dummy arguments in the call chain. Running dg.exp and counting the # of

Re: [PATCH] c++: improve debug_tree for templated types/decls

On 7/31/23 20:34, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- gcc/cp/ChangeLog: * ptree.cc (cxx_print_decl): Check for DECL_LANG_SPECIFIC and TS_DECL_COMMON only when necessary. Print DECL_TEMPLATE_INFO for all decls that

Re: [PATCH 04/14] c++: use _P() defines from tree.h

On 8/2/23 12:51, Patrick Palka via Gcc-patches wrote: On Thu, Jun 1, 2023 at 2:11 PM Bernhard Reutner-Fischer wrote: Hi David, Patrick, On Thu, 1 Jun 2023 18:33:46 +0200 Bernhard Reutner-Fischer wrote: On Thu, 1 Jun 2023 11:24:06 -0400 Patrick Palka wrote: On Sat, May 13, 2023 at 7:26 

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

On 8/3/23 07:07, Javier Martinez via Gcc-patches wrote: Most code is cold. This patch extends support for attribute ((cold)) to C++ Classes, Unions, and Structs (RECORD_TYPES and UNION_TYPES) to benefit from encapsulation - reducing the verbosity of using the attribute where deserved. The

Re: [PATCH] c++: Report invalid id-expression in decltype [PR100482]

On 8/7/23 22:48, Nathaniel Shead wrote: Sorry, noticed I provided the wrong version of the test. Here is the correct version (not relying on 'namespace std' being implicitly defined). Bootstrapped + regtested on x86_64-pc-linux-gnu. Pushed, thanks! -- 8< -- This patch ensures that any

Re: [PATCH] c++: follow DR 2386 and update implementation of get_tuple_size [PR110216]

On 8/6/23 14:15, gnaggnoyil wrote: DR 2386 updated the tuple_size requirements for structured binding and it now requires tuple_size to be considered only if std::tuple_size names a complete class type with member value. GCC before this patch does not follow the updated requrements, and this

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

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

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

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

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

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); +

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

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) :

[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

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

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++: 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

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.

[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

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

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

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

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? -- &g

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

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

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

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

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

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

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 f

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

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

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.

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

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'

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

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

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

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

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

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 fai

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

[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

[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

[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

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

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

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

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__

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

[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

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

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

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

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

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

Re: [PATCH] c++: coercing variable template from current inst [PR110580]

Ok. On Tue, Jul 11, 2023, 9:16 AM Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk? > > -- >8 -- > > Here during ahead of time coercion of the variable template-id v1, > since we pass only the innermost arguments to coerce_template_parms

Re: [PATCH 2/19][front-end] C/C++ front-end: add pragma GCC novector

On Fri, Jun 30, 2023, 12:18 PM Tamar Christina wrote: > Hi Jason, > > Thanks for the review. I only now realized I should have split them > between C and C++. > > Will do so on the respins. > > > > > On 6/28/23 09:41, Tamar Christina wrote: > > > Hi All, > > > > > > FORTRAN currently has a

Re: [PATCH] c++: fix up caching of level lowered ttps

On 6/1/23 17:42, Patrick Palka wrote: Due to level/depth mismatches between the template parameters of a level lowered ttp and the original ttp, the ttp comparison check added by r14-418-g0bc2a1dc327af9 never actually holds outside of erroneous cases. Moreover, it'd be good to cache the overall

Re: [PATCH 2/19][front-end] C/C++ front-end: add pragma GCC novector

On 6/28/23 09:41, 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

Re: [PATCH] c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

On 6/29/23 11:36, Marek Polacek wrote: On Thu, Jun 29, 2023 at 11:22:55AM -0400, Patrick Palka via Gcc-patches wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13? -- >8 -- cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding a

Re: [PATCH] c++: NSDMI instantiation during overload resolution [PR110468]

On 6/29/23 11:22, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13/12? OK. -- >8 -- Here we find ourselves instantiating the NSDMI for A<1>::m when computing argument conversions during overload resolution, and thus tf_conv is set. This

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

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 tested on x86_64-pc-linux-gnu. -- 8< -- This patch raises an error early when the decltype(auto)

Re: [PATCH] c++: cache partial template specialization selection

On 6/28/23 12:51, Patrick Palka wrote: There's currently no cheap way to obtain the partial template specialization (and arguments relative to it) that was selected for a class or variable template specialization. Our only option is to compute the result from scratch via

Re: [PATCH] c++: fix error reporting routines re-entered ICE [PR110175]

On 6/23/23 18:25, Marek Polacek wrote: Here we get the "error reporting routines re-entered" ICE because of an unguarded use of warning_at. While at it, I added a check for a warning_at just above it. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. PR c++/110175

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

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 variable/alias template specialization code paths, I noticed we perform template argument coercion twice: first from instantiate_alias_template

Re: [PATCH] c++: ahead of time variable template-id coercion [PR89442]

On 6/28/23 11:28, Jason Merrill wrote: On 5/3/23 09:50, Patrick Palka wrote: This patch makes us coerce the arguments of a variable template-id ahead of time, as we do for other template-ids, which allows us to immediately diagnose template parameter/argument kind mismatches and arity

Re: [PATCH] c++: ahead of time variable template-id coercion [PR89442]

On 5/3/23 09:50, Patrick Palka wrote: This patch makes us coerce the arguments of a variable template-id ahead of time, as we do for other template-ids, which allows us to immediately diagnose template parameter/argument kind mismatches and arity mismatches. Unfortunately this causes a

[pushed] c++: inherited constructor attributes

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Inherited constructors are like constructor clones; they don't exist from the language perspective, so they should copy the attributes in the same way. But it doesn't make sense to copy alias or ifunc attributes in either case. Unlike

<    5   6   7   8   9   10   11   12   13   14   >