[pushed] c++: strict constexpr and local vars

A change I was working on made constexpr_searcher.cc start to fail, and when I looked at it I wondered why it had been accepted before. This turned out to be because we try to be more flexible about constant-evaluation of static initializers, as allowed, but we were wrongly doing the same for non-

[pushed] c++: constexpr returning deallocated ptr

In constexpr-new3.C, the f7 function returns a deleted pointer, which we were happily caching because the new and delete are balanced. Don't. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_call_expression): Check for heap vars in the re

Re: [PATCH] c++: Don't purge the satisfaction caches

On 11/2/20 9:03 AM, Patrick Palka wrote: On Tue, 27 Oct 2020, Patrick Palka wrote: The adoption of P2104 means we can memoize the result of satisfaction indefinitely and no longer have to clear the satisfaction caches on various events that would affect satisfaction. To that end, this patch re

Re: [PATCH] c++: Implement DR2303 [PR97453]

On 11/2/20 10:10 AM, kamlesh kumar wrote: addressed jason comments. no regression due to this, tested on x86_64 linux. On Tue, Oct 27, 2020 at 11:09 PM Jason Merrill wrote: On 10/22/20 1:31 PM, kamlesh kumar wrote: Attaching the patch file. >>Instead of building a hash table, would it wor

Re: [PATCH] c++: Don't try to parse a function declaration as deduction guide [PR97663]

On 11/2/20 2:13 PM, Jakub Jelinek wrote: Hi! While these function declarations have NULL decl_specifiers->type, they have still type specifiers specified from which the default int in the return type is added, so we shouldn't try to parse those as deduction guides. Bootstrapped/regtested on x86

Re: [PATCH] c++: Implement DR2303 [PR97453]

On 11/3/20 3:11 AM, kamlesh kumar wrote: Here is the copyright assignment under which i will be contributing. Ah, great. I've now committed the patch. On Mon, Nov 2, 2020 at 10:50 PM kamlesh kumar wrote: Do you see a reason this wouldn't work? No, I do not see any.This is good. so it's

[PATCH] c++: Not all character types are byte-access types.

The patch for 94923 that introduced is_byte_access_type mistakenly changed build_cplus_array_type to treat even arrays of char16_t as typeless storage, which is wrong; only arrays of char and unsigned char have the special alias semantics in C++. G++ used to treat signed char the same way, as C do

Re: Avoid char[] array in tree_def

On Sat, Oct 31, 2020 at 6:35 PM Jan Hubicka wrote: > > On 10/29/20 1:40 PM, Richard Biener wrote: > > > On Thu, 29 Oct 2020, Jakub Jelinek wrote: > > > > > > > On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote: > > > > > > > > > > > > That's ugly and will for sure defeat warning / acces

Re: [00/32] C++ 20 Modules

On Wed, Nov 4, 2020 at 8:50 AM Nathan Sidwell wrote: > On 11/4/20 7:30 AM, Nathan Sidwell wrote: > > > rechecking the compile-farm page, I see gcc45 is a 686 machine, I'll try > > that. > > yeah, that didn't work. There's compilation errors in > ../../../src/gcc/config/i386/x86-tune-costs.h abou

Re: [PATCH v4] c++: Implement -Wvexing-parse [PR25814]

On 11/5/20 10:46 AM, Marek Polacek wrote: On Fri, Oct 30, 2020 at 04:33:48PM -0400, Jason Merrill wrote: On 10/29/20 11:00 PM, Marek Polacek wrote: Gotcha. Now we do most of the work in warn_about_ambiguous_parse. Thanks, just a few tweaks left. --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -4

Re: [PATCH] c++: Reuse identical ATOMIC_CONSTRs during normalization

On 11/3/20 3:43 PM, Patrick Palka wrote: Profiling revealed that sat_hasher::equal accounts for nearly 40% of compile time in some cmcstl2 tests. This patch eliminates this bottleneck by caching the ATOMIC_CONSTRs returned by normalize_atom. This in turn allows us to replace the expensive atomi

Re: [PATCH] c++: Add -Wexceptions warning option [PR97675]

On 11/5/20 11:03 AM, Marek Polacek wrote: This PR asks that we add a warning option for an existing (very old) warning, so that it can be disabled selectively. clang++ uses -Wexceptions for this, so I added this new option rather than using e.g. -Wnoexcept. OK. gcc/c-family/ChangeLog:

Re: [PATCH] c++: Fix decltype(auto) deduction with rvalue ref [PR78209]

On 11/5/20 3:52 PM, Marek Polacek wrote: Here's a small deficiency in decltype(auto). [dcl.type.auto.deduct]/5: If the placeholder-type-specifier is of the form decltype(auto), [...] the type deduced for T is determined [...] as though E had been the operand of the decltype. So: int &&i = 0

Re: [PATCH] c++: Use two levels of caching in satisfy_atom

On 11/4/20 2:19 PM, Patrick Palka wrote: [ This patch depends on c++: Reuse identical ATOMIC_CONSTRs during normalization https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557929.html ] This improves the effectiveness of caching in satisfy_atom by querying the cache again after we

Re: [PATCH] c++: Consider only relevant template arguments in sat_hasher

On 11/5/20 11:18 AM, Patrick Palka wrote: [ This patch depends on c++: Use two levels of caching in satisfy_atom https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558096.html ] A large source of cache misses in satisfy_atom is caused by the identity of an (atom,args) pair within t

Re: [PATCH] c++: DR 1914 - Allow duplicate standard attributes.

On 11/6/20 2:06 PM, Marek Polacek wrote: Following Joseph's change for C to allow duplicate C2x standard attributes , this patch does a similar thing for C++. This is DR 1914, to be resolved by , which is not part of the standar

Re: [PATCH] c++: Propagate attributes to clones in duplicate_decls [PR67453]

On 11/6/20 4:07 AM, Jakub Jelinek wrote: Hi! On the following testcase where the cdtor attributes aren't on the in-class declaration but on an out-of-class definition, the cdtors have their clones created from the in-class declaration, and later on duplicate_decls updates attributes on the abstr

Re: [PATCH] c++: Small tweak to can_convert_eh [PR81660]

On 11/6/20 1:15 AM, Marek Polacek wrote: While messing with check_handlers_1, I spotted this bug report which complains that we don't warn about the case when we have two duplicated handlers of type int. can_convert_eh implements [except.handle] and that says: A handler is a match for an excepti

Re: [PATCH 1/4] c++: Fix ICE with variadic concepts and aliases [PR93907]

On 11/5/20 8:40 PM, Patrick Palka wrote: This patch (naively) extends the PR93907 fix to also apply to variadic concepts invoked with a type argument pack. Without this, we ICE on the below testcase (a variadic version of concepts-using2.C) in the same manner as we used to on concepts-using2.C b

Re: [PATCH] c++: DR 1914 - Allow duplicate standard attributes.

On 11/6/20 2:34 PM, Marek Polacek wrote: On Fri, Nov 06, 2020 at 02:23:10PM -0500, Jason Merrill via Gcc-patches wrote: On 11/6/20 2:06 PM, Marek Polacek wrote: Following Joseph's change for C to allow duplicate C2x standard attributes <https://gcc.gnu.org/pipermail/gcc-patches/2020

Re: [PATCH] c++: Reuse identical ATOMIC_CONSTRs during normalization

On 11/5/20 8:31 PM, Patrick Palka wrote: On Thu, 5 Nov 2020, Patrick Palka wrote: On Thu, 5 Nov 2020, Jason Merrill wrote: On 11/3/20 3:43 PM, Patrick Palka wrote: Profiling revealed that sat_hasher::equal accounts for nearly 40% of compile time in some cmcstl2 tests. This patch eliminates

Re: [PATCH 3/4 v2] c++: Use two levels of caching in satisfy_atom

On 11/5/20 8:40 PM, Patrick Palka wrote: This improves the effectiveness of caching in satisfy_atom by querying the cache again after we've instantiated the atom's parameter mapping. Before instantiating its mapping, the identity of an (atom,args) pair within the satisfaction cache is determined

Re: [PATCH 4/4 v2] c++: Consider only relevant template arguments in sat_hasher

On 11/5/20 8:40 PM, Patrick Palka wrote: A large source of cache misses in satisfy_atom is caused by the identity of an (atom,args) pair within the satisfaction cache being determined by the entire set of supplied template arguments rather than by the subset of template arguments that the atom ac

Re: [PATCH] c++: Don't purge the satisfaction caches

On 11/2/20 9:03 AM, Patrick Palka wrote: On Tue, 27 Oct 2020, Patrick Palka wrote: The adoption of P2104 means we can memoize the result of satisfaction indefinitely and no longer have to clear the satisfaction caches on various events that would affect satisfaction. To that end, this patch re

Re: Enable MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for march=tremont

This patch was also applied to the GCC 9 and 10 branches and breaks those builds, because PTA_CLDEMOTE is not defined. On Mon, Nov 9, 2020 at 4:03 AM Uros Bizjak via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Mon, Nov 9, 2020 at 9:50 AM Cui, Lili wrote: > > > > Hi Uros, > > > > This patc

Re: [PATCH] c, c++: Fix up -Wunused-value on COMPLEX_EXPRs [PR97748]

On 11/9/20 4:51 AM, Jakub Jelinek wrote: Hi! The -Wunused-value warning in both C and C++ FEs (implemented significantly differently between the two) sees the COMPLEX_EXPRs created e.g. for complex pre/post increment and many other expressions as useless and warns about it. For the C warning im

Re: [PATCH] c++: Fix -Wvexing-parse ICE with omitted int [PR97762]

On 11/9/20 11:47 AM, Marek Polacek wrote: For declarations like long f(); decl_specifiers->type will be NULL, but I neglected to handle this case, therefore we ICE. So handle this case by pretending we've seen 'int', which is good enough for -Wvexing-parse's purposes. Bootstrapped/regteste

Re: [PATCH v2] c++: DR 1914 - Allow duplicate standard attributes.

On 11/9/20 12:05 PM, Marek Polacek wrote: On Fri, Nov 06, 2020 at 03:01:56PM -0500, Jason Merrill via Gcc-patches wrote: On 11/6/20 2:34 PM, Marek Polacek wrote: On Fri, Nov 06, 2020 at 02:23:10PM -0500, Jason Merrill via Gcc-patches wrote: On 11/6/20 2:06 PM, Marek Polacek wrote: Following

Re: [PATCH 1/4] c++: Fix ICE with variadic concepts and aliases [PR93907]

On 11/7/20 10:59 AM, Patrick Palka wrote: On Fri, 6 Nov 2020, Jason Merrill wrote: On 11/5/20 8:40 PM, Patrick Palka wrote: This patch (naively) extends the PR93907 fix to also apply to variadic concepts invoked with a type argument pack. Without this, we ICE on the below testcase (a variadic

[PATCH] c++: Call tsubst_pack_expansion from tsubst.

This was unnecessary (and incomplete) code duplication. gcc/cp/ChangeLog: * pt.c (tsubst): Replace *_ARGUMENT_PACK code with a call to tsubst_argument_pack. --- gcc/cp/pt.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/gcc/cp/pt.c b/gcc/cp/pt

[pushed] c++: Call tsubst_pack_expansion from tsubst.

This was unnecessary (and incomplete) code duplication. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * pt.c (tsubst): Replace *_ARGUMENT_PACK code with a call to tsubst_argument_pack. --- gcc/cp/pt.c | 15 +-- 1 file changed, 1 insertion(+), 14 de

[pushed] c++: Improve error location for class using-decl.

We should use the location of the using-declaration, not the location of the class. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * class.c (handle_using_decl): Add an iloc_sentinel. gcc/testsuite/ChangeLog: * g++.dg/lookup/using26.C: Adjust location.

Re: [PATCH] c, c++: Fix up -Wunused-value on COMPLEX_EXPRs [PR97748]

On 11/10/20 3:48 AM, Jakub Jelinek wrote: On Mon, Nov 09, 2020 at 10:34:00PM +0100, Jakub Jelinek via Gcc-patches wrote: On Mon, Nov 09, 2020 at 02:35:58PM -0500, Jason Merrill wrote: How about calling warn_if_unused_value instead of the new warn_if_unused_value_p? That seems to work if I jus

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On 11/9/20 7:21 PM, Marek Polacek wrote: Currently, when a static_assert fails, we only say "static assertion failed". It would be more useful if we could also print the expression that evaluated to false; this is especially useful when the condition uses template parameters. Consider the motiva

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On 11/10/20 1:59 PM, Marek Polacek wrote: On Tue, Nov 10, 2020 at 11:32:04AM -0500, Jason Merrill wrote: On 11/9/20 7:21 PM, Marek Polacek wrote: Currently, when a static_assert fails, we only say "static assertion failed". It would be more useful if we could also print the expression that eval

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On 11/10/20 2:28 PM, Marek Polacek wrote: On Tue, Nov 10, 2020 at 02:15:56PM -0500, Jason Merrill wrote: On 11/10/20 1:59 PM, Marek Polacek wrote: On Tue, Nov 10, 2020 at 11:32:04AM -0500, Jason Merrill wrote: On 11/9/20 7:21 PM, Marek Polacek wrote: Currently, when a static_assert fails, we

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On 11/10/20 8:13 PM, Marek Polacek wrote: On Tue, Nov 10, 2020 at 02:30:30PM -0500, Jason Merrill via Gcc-patches wrote: On 11/10/20 2:28 PM, Marek Polacek wrote: On Tue, Nov 10, 2020 at 02:15:56PM -0500, Jason Merrill wrote: On 11/10/20 1:59 PM, Marek Polacek wrote: On Tue, Nov 10, 2020 at

Re: [PATCH] c++: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling [PR97790]

On 11/11/20 10:26 AM, Jakub Jelinek wrote: Hi! As the testcase shows, CLEANUP_POINT_EXPR (and I think TRY_FINALLY_EXPR too) suffer from the same problem that I was trying to fix in r10-3597-g1006c9d4395a939820df76f37c7b085a4a1a003f for CLEANUP_STMT, namely that if in the middle of the body expre

Re: [PATCH 2/2] c++: Change the mangling of __alignof__ [PR88115]

On 11/11/20 1:21 PM, Patrick Palka wrote: This patch changes the mangling of __alignof__ to v111__alignof__, making the mangling distinct from that of alignof(type) and alignof(expr). How we mangle ALIGNOF_EXPR now depends on its ALIGNOF_EXPR_STD_P flag, which after the previous patch gets consi

Re: [PATCH] c++, v2: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling [PR97790]

On 11/11/20 3:04 PM, Jakub Jelinek wrote: On Wed, Nov 11, 2020 at 02:11:14PM -0500, Jason Merrill via Gcc-patches wrote: Would it make sense to always use a NULL jump_target when evaluating cleanups? I was afraid of that, especially for TRY_FINALLY_EXPR, but it seems that during constexpr

[pushed] dwarf2: Set DW_AT_declaration for undefined fns [PR97060]

If DECL_INITIAL isn't set, we can't emit anything about the body of the function, so add the declaration attribute. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/ChangeLog: PR debug/97060 * dwarf2out.c (gen_subprogram_die): It's a declaration if DECL_INITIAL isn't se

Re: [PATCH] system: Add WARN_UNUSED_RESULT

On 11/11/20 10:03 PM, Marek Polacek wrote: I'd like to have the option of marking functions with __attribute__ ((__warn_unused_result__)), so this patch adds a macro. And use it for maybe_wrap_with_location, it's always a bug if the return value is not used, which happened to me and got me confus

Re: [PATCH] c++: Don't form a templated TARGET_EXPR in finish_compound_literal

On 11/12/20 1:27 PM, Patrick Palka wrote: The atom_cache in normalize_atom relies on the assumption that two equivalent (templated) trees (in the sense of cp_tree_equal) must use the same template parameters (according to find_template_parameters). This assumption unfortunately doesn't always ho

[pushed] c++: Implement C++20 'using enum'. [PR91367]

This feature allows the programmer to import enumerator names into the current scope so later mentions don't need to use the fully-qualified name. These usings are not subject to the usual restrictions on using-declarations: in particular, they can move between class and non-class scopes, and betwe

[pushed] c++: Add feature test macro for C++20 using enum.

Missing piece from the 'using enum' implementation patch. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/c-family/ChangeLog: * c-cppbuiltin.c (c_cpp_builtins): Define __cpp_using_enum. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/feat-cxx2a.C: Check it. --- gcc/c-family/c-cppbu

Re: [PATCH] c++: Predefine __STDCPP_THREADS__ in the compiler if thread model is not single

On 11/13/20 2:20 PM, Tom Tromey wrote: "Jakub" == Jakub Jelinek via Gcc-patches writes: Jakub> 2020-11-13 Jakub Jelinek Jakub> * c-cppbuiltin.c: Include configargs.h. Jakub> (c_cpp_builtins): For C++11 and later if THREAD_MODEL_SPEC is not Jakub> defined, predefine __STDC

Re: [PATCH] c++: Predefine __STDCPP_THREADS__ in the compiler if thread model is not single

On 11/13/20 4:46 PM, Jakub Jelinek wrote: On Fri, Nov 13, 2020 at 04:39:25PM -0500, Jason Merrill wrote: On 11/13/20 2:20 PM, Tom Tromey wrote: "Jakub" == Jakub Jelinek via Gcc-patches writes: Jakub> 2020-11-13 Jakub Jelinek Jakub> * c-cppbuiltin.c: Include configargs.h. Jakub>

[pushed] c++: Check abstract type only on object creation. [PR86252]

Abstract checking has been problematic for a while; when I implemented an earlier issue resolution to do more checking it led to undesirable instantiations, and so backed some of it out. During the C++20 process we decided with P0929R2 that we should go the other way, and only check abstractness w

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On 11/16/20 12:42 PM, Martin Sebor wrote: On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: This patch implements the long-desired -Wuninitialized warning for member initializer lists, so that the front end can detect bugs like    struct A { int a; int b; A() : b(1), a(b)

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On 11/16/20 2:24 PM, Marek Polacek wrote: On Mon, Nov 16, 2020 at 02:02:00PM -0500, Jason Merrill via Gcc-patches wrote: On 11/16/20 12:42 PM, Martin Sebor wrote: On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: This patch implements the long-desired -Wuninitialized warning for

Re: [PATCH] c++: Extend -Wrange-loop-construct for binding-to-temp [PR94695]

On 11/15/20 10:34 PM, Marek Polacek wrote: [ This year's end-of-stage1 I'm working virtually from American Samoa. ] This patch finishes the second half of -Wrange-loop-construct I promised to implement: it warns when a loop variable in a range-based for-loop is initialized with a value of a diff

Re: [PATCH] c++: Don't form a templated TARGET_EXPR in finish_compound_literal

On 11/13/20 10:43 AM, Patrick Palka wrote: On Thu, 12 Nov 2020, Jason Merrill wrote: On 11/12/20 1:27 PM, Patrick Palka wrote: The atom_cache in normalize_atom relies on the assumption that two equivalent (templated) trees (in the sense of cp_tree_equal) must use the same template parameters (

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On 11/16/20 10:13 PM, Martin Sebor wrote: On 11/16/20 12:02 PM, Jason Merrill wrote: On 11/16/20 12:42 PM, Martin Sebor wrote: On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: This patch implements the long-desired -Wuninitialized warning for member initializer lists, so that the fron

Re: [PATCH] use TYPE_SIZE instead of DECL_SIZE for classes (PR 97595)

On 11/16/20 9:41 PM, Martin Sebor wrote: The result of DECL_SIZE_UNIT doesn't always reflect the size of data members of virtual classes.  This can lead to objects of such types appearing smaller than they are to warnings like -Warray-bounds or -Wstringop-overflow, causing false positives. To av

[pushed] c++: Various small fixes

A copy-paste error, a couple of missed checks to guard undefined accesses, and we don't need to use type_uses_auto to extract the auto node we just built. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * coroutines.cc (flatten_await_stmt): Fix copyo. * decl.c (r

Re: [PATCH] warn for more impossible null pointer tests

On 8/31/21 10:08 PM, Martin Sebor wrote: A Coverity run recently uncovered a latent bug in GCC that GCC should be able to detect itself: comparing the address of a declared object for equality to null, similar to:   int f (void)   {     int a[2][2];     return &a == 0;   } GCC issues -Wadd

Re: C++ patch ping

On 8/30/21 3:11 AM, Jakub Jelinek wrote: Hi! I'd like to ping the following patches libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html together with your https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html incr

Re: [PATCH] c++, abi: Set DECL_FIELD_ABI_IGNORED on C++ zero width bitfields [PR102024]

On 8/31/21 5:15 AM, Richard Biener wrote: On Tue, 31 Aug 2021, Jakub Jelinek wrote: On Tue, Aug 31, 2021 at 09:57:44AM +0200, Richard Biener wrote: Just to clarify - in the C++ FE these fields are meaningful for layout purposes but they are only supposed to influence layout but not ABI (but wh

Re: [PATCH] warn for more impossible null pointer tests

On 9/1/21 4:33 PM, Martin Sebor wrote: On 9/1/21 1:21 PM, Jason Merrill wrote: On 8/31/21 10:08 PM, Martin Sebor wrote: A Coverity run recently uncovered a latent bug in GCC that GCC should be able to detect itself: comparing the address of a declared object for equality to null, similar to:  

Re: C++ patch ping

On 9/1/21 4:11 PM, Jakub Jelinek wrote: On Wed, Sep 01, 2021 at 03:25:17PM -0400, Jason Merrill wrote: On 8/30/21 3:11 AM, Jakub Jelinek wrote: Hi! I'd like to ping the following patches libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488] https://gcc.gnu.org/pipermail/gcc-patches/2021-J

Re: [PATCH] warn for more impossible null pointer tests

On 9/1/21 6:27 PM, Martin Sebor wrote: On 9/1/21 3:39 PM, Jason Merrill wrote: On 9/1/21 4:33 PM, Martin Sebor wrote: On 9/1/21 1:21 PM, Jason Merrill wrote: On 8/31/21 10:08 PM, Martin Sebor wrote: A Coverity run recently uncovered a latent bug in GCC that GCC should be able to detect itself

[PATCH RFA] tree: Change error_operand_p to an inline function

I've thought for a while that many of the macros in tree.h and such should become inline functions. This one in particular was confusing Coverity; the null check in the macro made it think that all code guarded by error_operand_p would also need null checks. Tested x86_64-pc-linux-gnu. OK for tr

Re: [PATCH] c++, abi: Set DECL_FIELD_ABI_IGNORED on C++ zero width bitfields [PR102024]

On 9/2/21 4:49 AM, Jakub Jelinek wrote: On Thu, Sep 02, 2021 at 12:19:03AM +0200, Jakub Jelinek via Gcc-patches wrote: Ah, thanks for the archeology. So it indeed seems like in theory an ABI change between GCC 3.4 and 4.0 for C then on some of the targets like x86_64 which already existed in 3.

Re: [PATCH] c++: shortcut bad convs during overload resolution [PR101904]

On 8/31/21 3:15 PM, Patrick Palka wrote: On Mon, 30 Aug 2021, Patrick Palka wrote: In the context of overload resolution we have the notion of a "bad" argument conversion, which is a conversion that "would be a permitted with a bending of the language standards", and we handle such bad conversi

Re: [PATCH] c++: parameter pack inside constexpr if [PR101764]

On 8/30/21 10:05 PM, Patrick Palka wrote: Here when partially substituting into the pack expansion, substitution into the constexpr if yields a still-dependent tree, so tsubst_expr returns an IF_STMT with an unsubstituted IF_COND and with IF_STMT_EXTRA_ARGS added to. Hence after partial substitu

Re: [PATCH 1/8] coroutines : Use DECL_VALUE_EXPR instead of rewriting vars.

On 9/1/21 6:52 AM, Iain Sandoe wrote: Hi, Variables that need to persist over suspension expressions must be preserved by being copied into the coroutine frame. The initial implementations do this manually in the transform code. However, that has various disadvantages - including that the debu

Re: [PATCH 2/8] coroutines: Add a helper for creating local vars.

On 9/1/21 6:53 AM, Iain Sandoe wrote: This is primarily code factoring, but we take this opportunity to rename some of the implementation variables (which we intend to expose to debugging) so that they are in the implementation namespace. Signed-off-by: Iain Sandoe gcc/cp/ChangeLog:

Re: PATCH 3/8] coroutines: Support for debugging implementation state.

On 9/1/21 6:53 AM, Iain Sandoe wrote: Some of the state that is associated with the implementation is of interest to a user debugging a coroutine. In particular items such as the suspend point, promise object, and current suspend point. These variables live in the coroutine frame, but we can i

Re: [PATCH 4/8] coroutines: Make some of the artificial names more debugger-friendly.

On 9/1/21 6:54 AM, Iain Sandoe wrote: Some of the compiler-generated entries are of interest to a user debugging - keep variables in the implementation namespace but avoid using periods as separators (which is not compatible with visible symbols for some assemblers). Partial improvement to debu

Re: [PATCH 5/8] coroutines: Define and populate accessors for debug state.

On 9/1/21 6:54 AM, Iain Sandoe wrote: This is an efficiency measure and repeats the pattern used for other identifiers used in the coroutine implementation. In support of debugging, the user might well need to look at some of the variables that the implementation manipulates in lowering the cor

Re: [PATCH 5/8] coroutines: Define and populate accessors for debug state.

On 9/3/21 9:42 AM, Iain Sandoe wrote: On 3 Sep 2021, at 14:39, Jason Merrill wrote: On 9/1/21 6:54 AM, Iain Sandoe wrote: This is an efficiency measure and repeats the pattern used for other identifiers used in the coroutine implementation. In support of debugging, the user might well need

Re: [PATCH 6/8] coroutines: Convert implementation variables to debug-friendly form.

On 9/1/21 6:55 AM, Iain Sandoe wrote: The user might well wish to inspect some of the state that represents the implementation of the coroutine machine. In particular: The promise object. The function pointers for the resumer and destroyer. The current resume index (suspend point).

Re: [PATCH 7/8] coroutines: Make proxy vars for the function arg copies.

On 9/1/21 6:56 AM, Iain Sandoe wrote: This adds top level proxy variables for the coroutine frame copies of the original function args. These are then available in the debugger to refer to the frame copies. We rewrite the function body to use the copies, since the original parms will no longer

Re: [PATCH 6/8] coroutines: Convert implementation variables to debug-friendly form.

On 9/3/21 9:56 AM, Iain Sandoe wrote: On 3 Sep 2021, at 14:52, Jason Merrill wrote: On 9/1/21 6:55 AM, Iain Sandoe wrote: The user might well wish to inspect some of the state that represents the implementation of the coroutine machine. In particular: The promise object. The function

Re: [PATCH 8/8] coroutines: Make the continue handle visible to debug.

On 9/1/21 6:56 AM, Iain Sandoe wrote: When we have a suspend method that returns a coroutine handle we transfer (hopefully symmetrically, i.e. with a tailcall) to that new coroutine instead of returning to our resumer. This adds the variable to the outer block for the actor function which means

[pushed] c++: Avoid bogus -Wunused with recent change

My change to make limit_bad_template_recursion avoid instantiating members of erroneous classes produced a bogus "used but not defined" warning for 23_containers/unordered_set/instantiation_neg.cc; it's not defined because we decided not to instantiate it. So we need to suppress that warning. Tes

Re: [PATCH 6/8] coroutines: Convert implementation variables to debug-friendly form.

On 9/5/21 3:47 PM, Iain Sandoe wrote: Hello Jason, The patch below is a squashed version of: (approved) [PATCH 4/8] coroutines: Make some of the artificial names more debugger-friendly. [PATCH 5/8] coroutines: Define and populate accessors for debug state.

Re: [PATCH 7/8 v2] coroutines: Make proxy vars for the function arg copies.

On 9/5/21 3:50 PM, Iain Sandoe wrote: Hello Jason, On 3 Sep 2021, at 15:23, Iain Sandoe wrote: On 3 Sep 2021, at 15:07, Jason Merrill via Gcc-patches wrote: On 9/1/21 6:56 AM, Iain Sandoe wrote: This adds top level proxy variables for the coroutine frame + add_decl_expr

Re: [PATCH] c++: Fix up constexpr evaluation of deleting dtors [PR100495]

On 9/7/21 3:56 AM, Jakub Jelinek wrote: Hi! We do not save bodies of constexpr clones and instead evaluate the bodies of the constexpr functions they were cloned from. I believe that is just fine for constructors because complete vs. base ctors differ only in classes that have virtual bases and

Re: [PATCH v2] c-family: Add __builtin_assoc_barrier

On 9/6/21 8:21 AM, Matthias Kretz wrote: Hi, On Tuesday, 20 July 2021 22:22:02 CEST Jason Merrill wrote: The C++ front end already uses PAREN_EXPR in templates to indicate parenthesized initializers in cases where that matters for decltype(auto). It should be fine to use it for both that and _

Re: [PATCH v2] c++: Fix cp_tree_equal for template value args using dependent sizeof/alignof/noexcept expressions

On 9/2/21 8:10 PM, Barrett Adair wrote: Thanks for the feedback, Jason. Coming back to this today, The problem appears much deeper than I realized. I've attached another WIP version of the patch, including a couple of new test cases based on your feedback (for now, please excuse any misformatte

Re: [PATCH v2] c++: Fix cp_tree_equal for template value args using dependent sizeof/alignof/noexcept expressions

By the way, please avoid using non-ASCII characters in testcases unless that's specifically what you're testing: +// { dg-error "name ‘A::foo’" } Here, change the smart quotes to . to match whatever the output locale uses for quotes. And the error comments in dependent-name16.C seem to be

Re: [PATCH v4] c++: Add gnu::diagnose_as attribute

On 7/23/21 4:58 AM, Matthias Kretz wrote: Hi Jason, I found a few regressions from the last patch in the meantime. Version 4 of the patch is attached. Questions: 1. I simplified the condition for calling dump_template_parms in dump_function_name. !DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (t)

Re: [PATCH v2] c-family: Add __builtin_assoc_barrier

On 9/8/21 5:37 AM, Matthias Kretz wrote: On Tuesday, 7 September 2021 19:36:22 CEST Jason Merrill wrote: case PAREN_EXPR: - RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t, 0; + if (REF_PARENTHESIZED_P (t)) + RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND (t

Re: [PATCH] c++/102228 - make lookup_anon_field O(1)

On 9/8/21 5:13 AM, Richard Biener wrote: For the testcase in PR101555 lookup_anon_field takes the majority of parsing time followed by get_class_binding_direct/fields_linear_search which is PR83309. The situation with anon aggregates is particularly dire when we need to build accesses to their m

Re: [PATCH] c++: Fix docs on assignment of virtual bases [PR60318]

On 9/8/21 3:52 PM, Jonathan Wakely via Gcc-patches wrote: Ping (and remember to CC a maintainer this time). OK, thanks. On 31/08/21 09:53 +0100, Jonathan Wakely wrote: The description of behaviour is incorrect, the virtual base gets assigned before entering the bodies of A::operator= and B:

Re: [PATCH] warn for more impossible null pointer tests [PR102103]

On 9/2/21 7:53 PM, Martin Sebor wrote: @@ -4622,28 +4622,94 @@ warn_for_null_address (location_t location, tree op, tsubst_flags_t complain) if (!warn_address || (complain & tf_warning) == 0 || c_inhibit_evaluation_warnings != 0 - || warning_suppressed_p (op, OPT_Waddres

Re: [PATCH] Remove dbx.h, do not set PREFERRED_DEBUGGING_TYPE from dbxcoff.h, lynx.h

On 9/9/21 9:19 AM, Richard Biener via Gcc-patches wrote: The following removes the unused config/dbx.h file and removes the setting of PREFERRED_DEBUGGING_TYPE from dbxcoff.h which is overridden by all users (djgpp/mingw/cygwin) via either including config/i386/djgpp.h or config/i386/cygming.h T

Re: [PATCH] c++tools : Add a simple handler for ModuleCompiledRequest.

On 8/18/21 3:13 PM, Iain Sandoe wrote: Hi, I have found it useful when working with modules stuff to have the completed set of command/responses available (some people working with the interfaces for more sophisticated tools are using them). This message is a hand-shake telling the server that

[PATCH RFC] c++: implement C++17 hardware interference size

OK, time to finish this up. The main change relative to the last patch I sent to the list is dropping the -finterference-tune flag and making that behavior the default. Any more comments? The last missing piece of the C++17 standard library is the hardware intereference size constants. Mu

Re: [PATCH] c++: parameter pack inside constexpr if [PR101764]

On 9/12/21 7:48 PM, Patrick Palka wrote: On Thu, 2 Sep 2021, Jason Merrill wrote: On 8/30/21 10:05 PM, Patrick Palka wrote: Here when partially substituting into the pack expansion, substitution into the constexpr if yields a still-dependent tree, so tsubst_expr returns an IF_STMT with an unsu

Re: [PATCH] c++: Update DECL_*SIZE for objects with flexible array members with initializers [PR102295]

On 9/14/21 5:02 AM, Jakub Jelinek wrote: Hi! The C FE updates DECL_*SIZE for vars which have initializers for flexible array members for many years, but C++ FE kept DECL_*SIZE the same as the type size (i.e. as if there were zero elements in the flexible array member). This results e.g. in ELF

Re: [PATCH] c++: Fix __is_*constructible/assignable for templates [PR102305]

On 9/14/21 4:48 AM, Jakub Jelinek wrote: is_xible_helper returns error_mark_node (i.e. false from the traits) for abstract classes by testing ABSTRACT_CLASS_TYPE_P (to) early. Unfortunately, as the testcase shows, that doesn't work on class templates that haven't been instantiated yet, ABSTRACT_C

Re: [PATCH] c++: empty union member activation during constexpr [PR102163]

On 9/13/21 3:54 PM, Patrick Palka wrote: Here, the union's constructor is defined to activate its empty data member _M_rest, but during constexpr evaluation of this constructor the subobject constructor call to O::O(&_M_rest, 42) produces no side effects that actually activates the member, so the

Re: [PATCH RFC] c++: don't call 'rvalue' in coroutines code

On 9/14/21 11:21 AM, Iain Sandoe wrote: Hi Jason, I was looking at handling some backports to 11.x and 10.x for coroutines code-gen fixes ... On 7 May 2021, at 04:11, Jason Merrill wrote: A change to check glvalue_p rather than specifically for TARGET_EXPR revealed issues with the coroutines

[pushed] c++: tweak C++20 destructor template-id rule

While working on a larger change to destructor lookup I noticed that this rule talks about declarators, but we weren't limiting the error to the case where we're parsing a declarator. I don't know if this actually broke anything, since a CPP_TEMPLATE_ID would have to have been parsed once before,

[pushed] c++: correct object scope handling

The way cp_parser_lookup_name handles object scope (i.e. the scope on the RHS of a . or -> expression) is a bit subtle: before the lookup it's in parser->context->object type, and after the lookup it's in parser->object_scope. But a couple of places that elide lookups were failing to do the same t

[pushed] c++: don't predeclare std::type_info [PR48396]

We've always predeclared std::type_info, which has been wrong for a while, but now with modules it becomes more of a practical problem, if we want to declare it in the purview of a module. So don't predeclare it. For building up the type_info information to write out with the vtable, we can use v

[pushed] c++: don't warn about internal interference sizes

Most any compilation on ARM/AArch64 was warning because the default L1 cache line size of 32B was smaller than the default std::hardware_constructive_interference_size of 64B. This is mostly due to inaccurate --param l1-cache-line-size, but it's not helpful to complain to a user that didn't set th

Re: [PATCH RFC] c++: implement C++17 hardware interference size

On 9/15/21 8:31 AM, Martin Liška wrote: On 9/14/21 09:56, Christophe LYON via Gcc-patches wrote: So adjustment is needed for both arm and aarch64 targets Hello. I noticed the same problem and I've got a patch candidate for it. What do you think about it? I've now silenced the warning for i

<    8   9   10   11   12   13   14   15   16   17   >