Re: [PATCH v2] c-family: ICE with [[gnu::nocf_check]] [PR106937]

On 10/4/22 19:06, Marek Polacek wrote: On Fri, Sep 30, 2022 at 09:12:24AM -0400, Jason Merrill wrote: On 9/29/22 18:49, Marek Polacek wrote: When getting the name of an attribute, we ought to use get_attribute_name, which handles both [[ ]] and __attribute__(()) forms. Failure to do so may res

Re: [PATCH] c++, v3: Improve handling of foreigner namespace attributes

On 10/6/22 14:29, Jakub Jelinek wrote: On Thu, Oct 06, 2022 at 01:30:18PM -0400, Jason Merrill wrote: Yes, except I was thinking the new function would take the attribute TREE_LIST as its parameter so that all the callers don't have to also call get_attribute_namespace. Ok, here it is in patch

[PATCH RFA] gimplify: prevent some C++ temporary elision

Tested x86_64-pc-linux-gnu, OK for trunk? -- >8 -- In this testcase, we were optimizing away the temporary for f(), but C++17 and above are clear that there is a temporary, and because its destructor has visible side-effects we can't optimize it away under the as-if rule. So disable this optimiz

Re: [PATCH v2] c++: fixes for derived-to-base reference binding [PR107085]

On 10/6/22 13:51, Marek Polacek wrote: On Thu, Oct 06, 2022 at 10:58:44AM -0400, Jason Merrill wrote: On 10/6/22 10:49, Marek Polacek wrote: On Wed, Oct 05, 2022 at 08:25:29PM -0400, Jason Merrill wrote: On 10/5/22 17:27, Marek Polacek wrote: This PR reports that struct Base {}; st

Re: [RFC] c++: parser - Support for target address spaces in C++

On 10/6/22 10:34, Paul Iannetta wrote: Hi, Presently, GCC supports target address spaces as a GNU extension (cf. `info -n "(gcc)Named Address Spaces"`). This is however supported only by the C frontend, which is a bit sad, since all the GIMPLE machinery is readily available and, moreover, LLVM

Re: [PATCH] c++, v2: Improve handling of foreigner namespace attributes

On 10/6/22 13:20, Jakub Jelinek wrote: On Thu, Oct 06, 2022 at 09:42:47AM -0400, Jason Merrill wrote: - tree t = lookup_attribute ("fallthrough", attr); + tree t = lookup_attribute (NULL, "fallthrough", attr); + if (t == NULL_TREE) +t = lookup_attribute ("gnu", "fallthrough", attr); May

Re: [PATCH v2] c++: fixes for derived-to-base reference binding [PR107085]

On 10/6/22 10:49, Marek Polacek wrote: On Wed, Oct 05, 2022 at 08:25:29PM -0400, Jason Merrill wrote: On 10/5/22 17:27, Marek Polacek wrote: This PR reports that struct Base {}; struct Derived : Base {}; static_assert(__reference_constructs_from_temporary(Base const&, Derived)); d

Re: [PATCH] c++: Improve handling of foreigner namespace attributes

On 10/5/22 08:04, Jakub Jelinek wrote: Hi! The following patch uses the new lookup_attribute overload and extra tests to avoid emitting weird warnings on foreign namespace attributes which we should just ignore (perhaps with a warning), but shouldn't imply any meaning to them just because they h

Re: [PATCH] c++: remove optimize_specialization_lookup_p

On 10/5/22 22:02, Patrick Palka wrote: Roughly speaking, optimize_specialization_lookup_p returns true for a non-template member function of a class template, e.g. template struct A { int f(); }; The idea behind the optimization in question seems to be that if we want to look up the speciali

Re: [PATCH] c++: fixes for derived-to-base reference binding [PR107085]

On 10/5/22 17:27, Marek Polacek wrote: This PR reports that struct Base {}; struct Derived : Base {}; static_assert(__reference_constructs_from_temporary(Base const&, Derived)); doesn't pass, which it should: it's just like const Base& b(Derived{}); where we bind 'b' to the Base s

Re: [PATCH] middle-end, c++, i386, libgcc: std::bfloat16_t and __bf16 arithmetic support

On 10/5/22 09:47, Jakub Jelinek wrote: On Tue, Oct 04, 2022 at 05:50:50PM -0400, Jason Merrill wrote: Another question is the suffixes of the builtins. For now I have added bf16 suffix and enabled the builtins with !both_p, so one always needs to use __builtin_* form for them. None of the GCC

[pushed] c++: lvalue_kind tweak

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- I was wondering how lvalue_kind handles VIEW_CONVERT_EXPR; in cases where the type actually changes, it should have the same prvalue->xvalue effect as ARRAY_REF, since we need to materialize a temporary to get an object we can reinterpret as

Re: [PATCH] c++, c, v3: Implement C++23 P1774R8 - Portable assumptions [PR106654]

On 10/5/22 05:55, Jakub Jelinek wrote: On Tue, Oct 04, 2022 at 04:42:04PM -0400, Jason Merrill wrote: It could choose which function to call based on whether the constexpr_ctx parameter is null? Done, though it needs to be in constexpr.cc then because struct constexpr_ctx and cxx_eval_constant

[pushed] c++: fix debug info for array temporary [PR107154]

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- In the testcase the elaboration of the array init that happens at genericize time was getting the location info for the end of the function; fixed by doing the expansion at the location of the original expression. PR c++/107154 gcc

Re: [PATCH] Set discriminators for call stmts on the same line within the same basic block

On 10/3/22 02:08, Eugene Rozenfeld wrote: This change is based on commit 1e6c4a7a8fb8e20545bb9f9032d3854f3f794c18 by Dehao Chen in vendors/google/heads/gcc-4_8. Tested on x86_64-pc-linux-gnu. Brief rationale for the change? gcc/ChangeLog: * tree-cfg.cc (assign_discriminators): Set d

Re: [PATCH] middle-end, c++, i386, libgcc: std::bfloat16_t and __bf16 arithmetic support

On 10/4/22 05:06, Jakub Jelinek wrote: On Fri, Sep 30, 2022 at 04:08:10PM +0200, Jakub Jelinek via Gcc-patches wrote: On Fri, Sep 30, 2022 at 09:49:08AM -0400, Jason Merrill wrote: The comment from Apple on the ABI mangling proposal suggests to me that we might want to delay enabling C++ std::b

Re: [PATCH] fixincludes: Deal also with the _Float128x cases [PR107059]

On 9/30/22 03:20, Jakub Jelinek wrote: On Wed, Sep 28, 2022 at 08:19:43PM +0200, Jakub Jelinek via Gcc-patches wrote: Another case are the following 3 snippets: # if !__GNUC_PREREQ (7, 0) || defined __cplusplus # error "_Float128X supported but no constant suffix" # else # define __f128x(x

Re: [PATCH] c++, c, v2: Implement C++23 P1774R8 - Portable assumptions [PR106654]

On 10/3/22 15:22, Jakub Jelinek wrote: On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote: * fold-const.h (simple_operand_p_2): Declare. This needs a better name if it's going to be a public interface. The usage also needs rationale for why this is the right predicate for a

Re: [PATCH] c++: install cp-trait.def as part of plugin headers [PR107136]

On 10/3/22 20:42, Patrick Palka wrote: This is apparently needed since we include cp-trait.def from cp-tree.h (in order to define the cp_trait_kind enum), as with operators.def. Tested on x86_64-pc-linux-gnu by doing make install and verifying cp-trait.def appears in $prefix/lib/gcc/x86_64-p

Re: [PATCH RFC] c++: fix broken conversion in coroutines

On 9/30/22 18:50, Iain Sandoe wrote: Hi Jason, On 30 Sep 2022, at 23:06, Jason Merrill wrote: You can't use CONVERT_EXPR to convert between two class types, and it was breaking copy elision. Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where susp_type is Loopy::handle_type

Re: [PATCH RFC] c++: streamline process for adding new builtin trait

On 10/3/22 08:48, Patrick Palka wrote: On Fri, 30 Sep 2022, Jason Merrill wrote: On 9/30/22 11:14, Patrick Palka wrote: On Thu, 29 Sep 2022, Jason Merrill wrote: On 9/29/22 11:05, Patrick Palka wrote: Adding a new builtin trait currently involves some boilerplate (as can be seen in r13-2956

Re: [PATCH] c++: Disallow jumps into statement expressions

On 10/2/22 07:35, Jakub Jelinek wrote: On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote: --- gcc/cp/decl.cc.jj 2022-09-22 00:14:55.478599363 +0200 +++ gcc/cp/decl.cc 2022-09-22 00:24:01.121178256 +0200 @@ -223,6 +223,7 @@ struct GTY((for_user)) named_label_entry bool in_

[pushed] c++: loop through array CONSTRUCTOR

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- I noticed that we were ignoring all the special rules for when to use a simple INIT_EXPR for array initialization from a CONSTRUCTOR, because split_nonconstant_init_1 was also passing 1 to the from_array parameter. Arguably that's the real b

[pushed] c++: cast split_nonconstant_init return val to void

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- We were already converting the result of expand_vec_init_expr to void; we need to do the same for split_nonconstant_init. The test that I noticed this with no longer fails without it. gcc/cp/ChangeLog: * cp-gimplify.cc (cp_generic

[PATCH RFC] c++: fix broken conversion in coroutines

You can't use CONVERT_EXPR to convert between two class types, and it was breaking copy elision. Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where susp_type is Loopy::handle_type. How is this supposed to work? gcc/cp/ChangeLog: * coroutines.cc (expand_one_await_expre

Re: [PATCH] c++, c: Implement C++23 P1774R8 - Portable assumptions [PR106654]

On 9/22/22 05:55, Jakub Jelinek wrote: Hi! The following patch implements C++23 P1774R8 - Portable assumptions paper, by introducing support for [[assume (cond)]]; attribute for C++. In addition to that the patch adds [[gnu::assume (cond)]]; and __attribute__((assume (cond))); support to both C

Re: [PATCH RFC] c++: streamline process for adding new builtin trait

On 9/30/22 11:14, Patrick Palka wrote: On Thu, 29 Sep 2022, Jason Merrill wrote: On 9/29/22 11:05, Patrick Palka wrote: Adding a new builtin trait currently involves some boilerplate (as can be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and CPTK_ enumerators and adding th

Re: [PATCH] c++: make some cp_trait_kind switch statements exhaustive

On 9/30/22 13:37, Patrick Palka wrote: On Fri, 30 Sep 2022, Patrick Palka wrote: This replaces the unreachable default case in some cp_trait_kind switches with an exhaustive listing of the _unexpected_ trait codes, so that when adding a new trait we'll get a -Wswitch diagnostic if we forget to

Re: [PATCH] arm, aarch64, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

On 9/30/22 13:13, Jakub Jelinek wrote: On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote: Note, there is one further problem on aarch64/arm, types with HFmode (_Float16 and __fp16) are there mangled as Dh (which is standard Itanium mangling: ::= Dh # IEEE 754r half

Re: [PATCH] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]

On 9/29/22 06:01, Jakub Jelinek wrote: Hi! The following testcase ICEs on x86 as well as ppc64le (the latter with -mabi=ieeelongdouble), because _Float64x there isn't mangled as DF64x but e or u9__ieee128 instead. Those are the mangling that should be used for the non-standard types with the sam

Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support

On 9/29/22 11:55, Jakub Jelinek wrote: Hi! Here is more complete patch to add std::bfloat16_t support on x86, AArch64 and (only partially) on ARM 32-bit. No BFmode optabs are added by the patch, so for binops/unops it extends to SFmode first and then truncates back to BFmode. For {HF,SF,DF,XF,T

Re: [PATCH] c-family: ICE with [[gnu::nocf_check]] [PR106937]

On 9/29/22 18:49, Marek Polacek wrote: When getting the name of an attribute, we ought to use get_attribute_name, which handles both [[ ]] and __attribute__(()) forms. Failure to do so may result in an ICE, like here. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? How do we prin

[pushed] c++: reduce redundant TARGET_EXPR

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- An experiment led me to notice that in some cases we were ending up with TARGET_EXPR initialized by TARGET_EXPR, which isn't useful. The target_expr_needs_replace change won't make a difference in most cases, since cp_genericize_init will h

Re: [PATCH RFC] c++: streamline process for adding new builtin trait

On 9/29/22 11:05, Patrick Palka wrote: Adding a new builtin trait currently involves some boilerplate (as can be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and CPTK_ enumerators and adding them to various switch statements across many files. The exact switch statements we n

[pushed] c++: fix triviality of class with unsatisfied op=

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- cxx20_pair is trivially copyable because it has a trivial copy constructor and only a deleted copy assignment operator; the non-triviality of the unsatisfied copy assignment overload is not considered. gcc/cp/ChangeLog: * class.cc

[pushed] c++: check DECL_INITIAL for constexpr

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- We were overlooking non-potentially-constant bits in variable initializer because we didn't walk into DECL_INITIAL. gcc/cp/ChangeLog: * constexpr.cc (potential_constant_expression_1): Look into DECL_INITIAL. Use location w

[pushed] c++: fix class-valued ?: extension

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- When the gimplifier encounters the same TARGET_EXPR twice, it evaluates TARGET_EXPR_INITIAL the first time and clears it so that the later evaluation is just the temporary. With this testcase, using the extension to treat an omitted middle

[pushed] c++: reduce temporaries in ?:

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- When the sides of ?: are class prvalues, we wrap the COND_EXPR in a TARGET_EXPR so that both sides will initialize the same temporary. But in this case we were stripping the outer TARGET_EXPR and conditionally creating different temporaries

Re: [PATCH 1/2] c++: introduce TRAIT_TYPE alongside TRAIT_EXPR

On 9/28/22 12:36, Patrick Palka wrote: On Tue, 27 Sep 2022, Jason Merrill wrote: On 9/27/22 15:50, Patrick Palka wrote: We already have generic support for predicate-like traits that yield a boolean via TRAIT_EXPR, but we lack the same support for transform-like traits that yield a type. Such

Re: [PATCH v3] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On 9/27/22 16:26, Marek Polacek wrote: On Mon, Sep 26, 2022 at 01:29:35PM -0400, Jason Merrill wrote: On 9/20/22 14:19, Marek Polacek wrote: There's one FIXME in elision1.C:five, which we should compile but reject with "passing 'Mutt' as 'this' argument discards qualifiers". That looks bogus t

Re: [PATCH 2/2] c++: implement __remove_cv, __remove_reference and __remove_cvref

On 9/27/22 15:50, Patrick Palka wrote: This uses TRAIT_TYPE from the previous patch to implement efficient built-ins for std::remove_cv, std::remove_reference and std::remove_cvref. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK once the previous patch goes

Re: [PATCH 1/2] c++: introduce TRAIT_TYPE alongside TRAIT_EXPR

On 9/27/22 15:50, Patrick Palka wrote: We already have generic support for predicate-like traits that yield a boolean via TRAIT_EXPR, but we lack the same support for transform-like traits that yield a type. Such support would be useful for implementing efficient built-ins for std::decay and std

Re: [PATCH v2] c++: Don't quote nothrow in diagnostic

On 9/27/22 04:41, Richard Biener wrote: On Mon, Sep 26, 2022 at 9:54 PM Marek Polacek wrote: On Mon, Sep 26, 2022 at 12:34:04PM -0400, Jason Merrill wrote: On 9/26/22 03:50, Richard Biener wrote: On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via Gcc-patches wrote: In

Re: [PATCH] c++: Make __is_{,nothrow_}convertible SFINAE on access [PR107049]

On 9/27/22 06:35, Jonathan Wakely wrote: Tested powerpc64le-linux. OK for trunk? OK, thanks. -- >8 -- The is_convertible built-ins should return false if the conversion fails an access check, not report an error. PR c++/107049 gcc/cp/ChangeLog: * method.cc (is_convertible_

Re: [PATCH] c++, v2: Implement C++23 P1169R4 - static operator() [PR106651]

On 9/19/22 08:25, Jakub Jelinek wrote: Hi! On Sat, Sep 17, 2022 at 01:30:08PM +0200, Jason Merrill wrote: Below is an updated patch on top of the https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601788.html patch. Ah, OK. I don't think you need to check for C++23 or CALL_EXPR at all,

Re: [PATCH] c++: Improve diagnostics about conflicting specifiers

On 9/19/22 03:24, Jakub Jelinek wrote: Hi! On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote: I wonder why we don't give an error when setting the conflicting_specifiers_p flag in cp_parser_set_storage_class? We should be able to give a better diagnostic at that point. I didn't h

Re: [PATCH] Avoid depending on destructor order

On 9/23/22 10:12, Thomas Neumann wrote:     +static const bool in_shutdown = false; I'll let Jason or others decide if this is the right solution.  It seems that in_shutdown also could be declared outside the #ifdef and initialized as "false". sure, either is fine. Moving it outside the #if

Re: [EXTERNAL] Re: [PING][PATCH] Add instruction level discriminator support.

On 9/8/22 20:45, Eugene Rozenfeld wrote: Jason, Thank for your suggestion. The patch is updated (attached). @@ -467,12 +471,19 @@ lto_location_cache::apply_location_cache () current_loc = set_block (current_loc, loc.block); else current_loc = LOCATION_LOCUS (

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

On 9/19/22 12:39, Jakub Jelinek wrote: On Sat, Sep 17, 2022 at 10:58:54AM +0200, Jason Merrill wrote: I thought it is fairly important because __float128 has been around in GCC for 19 years already. To be precise, I think e.g. for x86_64 GCC 3.4 introduced it, but mangling was implemented only

Re: [PATCH v2] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On 9/20/22 14:19, Marek Polacek wrote: On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote: On 9/3/22 12:42, Marek Polacek wrote: This patch implements https://wg21.link/p2266, which, once again, changes the implicit move rules. Here's a brief summary of various changes in this area:

Re: [PATCH] c++: P2513R4, char8_t Compatibility and Portability Fix [PR106656]

On 9/23/22 21:16, Marek Polacek wrote: P0482R6, which added char8_t, didn't allow const char arr[] = u8"howdy"; because it said "Declarations of arrays of char may currently be initialized with UTF-8 string literals. Under this proposal, such initializations would become ill-formed." This c

Re: [PATCH v2] c++: Instantiate less when evaluating __is_convertible

On 9/26/22 12:25, Marek Polacek wrote: On Mon, Sep 26, 2022 at 11:51:30AM -0400, Patrick Palka wrote: On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote: Jon reported that evaluating __is_convertible in this test leads to instantiating char_traits::eq, which is invalid (because we are tr

Re: [PATCH] c++: Don't quote nothrow in diagnostic

On 9/26/22 03:50, Richard Biener wrote: On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via Gcc-patches wrote: In Jason noticed that we quote "nothrow" in diagnostics even though it's not a keyword in C++. Just removing the

Re: [PATCH] c++: Instantiate less when evaluating __is_convertible

On 9/26/22 11:51, Patrick Palka wrote: On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote: Jon reported that evaluating __is_convertible in this test leads to instantiating char_traits::eq, which is invalid (because we are trying to call a member function on a char) and so we fail to comp

Re: [PATCH] c++: Implement __is_{nothrow_,}convertible [PR106784]

On 9/23/22 10:34, Marek Polacek wrote: On Thu, Sep 22, 2022 at 06:14:44PM -0400, Jason Merrill wrote: On 9/22/22 09:39, Marek Polacek wrote: To improve compile times, the C++ library could use compiler built-ins rather than implementing std::is_convertible (and _nothrow) as class templates. Th

Re: [PATCH] Avoid depending on destructor order

On 9/19/22 12:20, Thomas Neumann wrote: In some scenarios (e.g., when mixing gcc and clang code), it can happen that frames are deregistered after the lookup structure has already been destroyed. That in itself would be fine, but it triggers an assert in __deregister_frame_info_bases that expects

Re: [PATCH] c++: ICE-on-invalid with designated initializer [PR106983]

On 9/20/22 17:05, Marek Polacek wrote: We ICE in the code added in r12-7117: type_build_dtor_call gets the error_mark_node because the type of 'prev' wasn't declared. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. PR c++/106983 gcc/cp/ChangeLog: * typeck2.

Re: [PATCH] c++: Implement __is_{nothrow_,}convertible [PR106784]

On 9/22/22 09:39, Marek Polacek wrote: To improve compile times, the C++ library could use compiler built-ins rather than implementing std::is_convertible (and _nothrow) as class templates. This patch adds the built-ins. We already have __is_constructible and __is_assignable, and the nothrow fo

Re: [PATCH] c++: Implement C++23 P1169R4 - static operator() [PR106651]

On 9/17/22 02:42, Jakub Jelinek wrote: On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote: On 9/13/22 12:42, Jakub Jelinek wrote: The following patch attempts to implement C++23 P1169R4 - static operator() paper's compiler side (there is some small library side too not implemented ye

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

On 9/16/22 13:34, Jakub Jelinek wrote: On Fri, Sep 16, 2022 at 01:48:54PM +0200, Jason Merrill wrote: On 9/12/22 04:05, Jakub Jelinek wrote: The following patch implements the compiler part of C++23 P1467R9 - Extended floating-point types and standard names compiler part by introducing _Float{1

Re: [PATCH] c++: constraint matching, TEMPLATE_ID_EXPR, current inst

On 9/16/22 10:59, Patrick Palka wrote: On Fri, 16 Sep 2022, Jason Merrill wrote: On 9/15/22 11:58, Patrick Palka wrote: Here we're crashing during constraint matching for the instantiated hidden friends due to two issues with dependent substitution into a TEMPLATE_ID_EXPR naming a template fro

Re: [PATCH] c++: Implement C++23 P1169R4 - static operator() [PR106651]

On 9/13/22 12:42, Jakub Jelinek wrote: Hi! The following patch attempts to implement C++23 P1169R4 - static operator() paper's compiler side (there is some small library side too not implemented yet). This allows static members as user operator() declarations and static specifier on lambdas wit

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

On 9/16/22 06:19, Thomas Neumann wrote: The __register_frame/__deregister_frame functions are used to register unwinding frames from JITed code in a sorted list. That list itself is protected by object_mutex, which leads to terrible performance in multi-threaded code and is somewhat expensive eve

[pushed] c++: member fn in omp loc list [PR106858]

this->f names a member function, which isn't an addressable lvalue. Give a helpful error instead of crashing. The first hunk makes the error range cover the whole expression. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/106858 gcc/cp/ChangeLog: * parser.cc (cp_parser_

Re: [PATCH] c++: 'mutable' within constexpr [PR92505]

On 9/15/22 14:03, Patrick Palka wrote: This patch permits accessing 'mutable' members of local objects during constexpr evaluation (which other compilers seem to accept in C++14 mode, while we reject), while continuing to reject it for global objects (as in the last line of cpp0x/constexpr-mutabl

Re: [PATCH] c++: constraint matching, TEMPLATE_ID_EXPR, current inst

On 9/15/22 11:58, Patrick Palka wrote: Here we're crashing during constraint matching for the instantiated hidden friends due to two issues with dependent substitution into a TEMPLATE_ID_EXPR naming a template from the current instantiation (as performed from maybe_substitute_reqs_for for C<3> wi

Re: [PATCH] Introduce -nolibstdc++ option

On 9/16/22 07:52, Jason Merrill wrote: On 6/24/22 01:23, Alexandre Oliva via Gcc-patches wrote: On Jun 23, 2022, Alexandre Oliva wrote: Here's the patch.  Regstrapped on x86_64-linux-gnu, also tested with a cross to aarch64-rtems6.  Ok to install? Introduce -nostdlib++ option Uhh, I went

Re: [PATCH] Introduce -nolibstdc++ option

On 6/24/22 01:23, Alexandre Oliva via Gcc-patches wrote: On Jun 23, 2022, Alexandre Oliva wrote: Here's the patch. Regstrapped on x86_64-linux-gnu, also tested with a cross to aarch64-rtems6. Ok to install? Introduce -nostdlib++ option Uhh, I went ahead and installed this. The earlier

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

On 9/12/22 04:05, Jakub Jelinek wrote: Hi! The following patch implements the compiler part of C++23 P1467R9 - Extended floating-point types and standard names compiler part by introducing _Float{16,32,64,128} as keywords and builtin types like they are implemented for C already since GCC 7. It

Re: [PATCH] c++: some missing-SFINAE fixes

On 9/13/22 09:46, Patrick Palka wrote: On Tue, 13 Sep 2022, Jason Merrill wrote: On 9/13/22 07:45, Patrick Palka wrote: It looks like we aren't respecting SFINAE for: * an invalid/non-constant conditional explicit-specifier * a non-constant conditional noexcept-specifier * a non-c

Re: [PATCH] c++: some missing-SFINAE fixes

On 9/13/22 07:45, Patrick Palka wrote: It looks like we aren't respecting SFINAE for: * an invalid/non-constant conditional explicit-specifier * a non-constant conditional noexcept-specifier * a non-constant argument to __integer_pack This patch fixes these issues in the usual way, by

Re: [PATCH] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On 9/8/22 18:54, Marek Polacek wrote: On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote: On 9/3/22 12:42, Marek Polacek wrote: This patch implements https://wg21.link/p2266, which, once again, changes the implicit move rules. Here's a brief summary of various changes in this area:

Re: [PATCH] c++: remove '_sfinae' suffix from functions

On 9/9/22 08:52, Patrick Palka wrote: Each of the following functions instantiate_non_dependent_expr get_target_expr require_complete_type abstract_virtuals_error cxx_constant_value is (presumably for historical reasons) just a non-SFINAE-enabled wrapper for the corresponding SFI

[pushed] c++: auto member function and auto variable [PR106893]

As with PR105623, we need to call mark_single_function sooner to resolve the type of a BASELINK. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/106893 PR c++/90451 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call mark_single_function. gcc/testsuite/ChangeLog:

[pushed] c++: cast to array of unknown bound [PR93259]

We already know to treat a variable of array-of-unknown-bound type as dependent, we should do the same for arr{}. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/93259 gcc/cp/ChangeLog: * pt.cc (type_dependent_expression_p): Treat a compound literal of array-of-unk

[PATCH] c++: lambda capture of array with deduced bounds [PR106567]

We can't use the type of an array variable directly if we haven't deduced its length yet. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/106567 gcc/cp/ChangeLog: * lambda.cc (type_deducible_expression_p): Check array_of_unknown_bound_p. gcc/testsuite/ChangeLog:

Re: [PATCH] c++: Refer to internal linkage for -Wsubobject-linkage [PR86491]

Oops, failed to CC the list. Forwarded Message Subject: Re: [PATCH] c++: Refer to internal linkage for -Wsubobject-linkage [PR86491] Date: Mon, 12 Sep 2022 12:09:38 -0400 From: Jason Merrill To: Jonathan Wakely On 7/23/22 07:31, Jonathan Wakely wrote: I'll try that on Mon

Re: [PATCH v3] eliminate mutex in fast path of __register_frame

On 6/26/22 05:13, Thomas Neumann via Gcc-patches wrote: NOTE: A stress test program and a detailed walkthrough that breaks this patch into manageable parts can be found here: https://databasearchitects.blogspot.com/2022/06/making-unwinding-through-jit-ed-code.html The __register_frame/__deregist

Re: [PATCH] optc-save-gen.awk: adjust generated array compare

On 9/8/22 14:01, Martin Liška wrote: On 9/8/22 18:23, Jason Merrill wrote: It seems to me that the warning is pointing out that comparing the address of the array is nonsensical, and we should remove it and just have the memcmp. Yes, thanks for the pointer. We should always compare the array

Re: [EXTERNAL] Re: [PING][PATCH] Add instruction level discriminator support.

On 9/1/22 18:22, Eugene Rozenfeld wrote: Jason, I made another small change in addressing your feedback (attached). Thanks, Eugene -Original Message- From: Gcc-patches On Behalf Of Eugene Rozenfeld via Gcc-patches Sent: Thursday, September 01, 2022 1:49 PM To: Jason Merrill ; gcc-pa

Re: [PATCH] optc-save-gen.awk: adjust generated array compare

On 9/8/22 11:29, Chung-Lin Tang wrote: Hi Joseph, Jan-Benedict reported a build-bot error for the nios2 port under --enable-werror-always: options-save.cc: In function 'bool cl_target_option_eq(const cl_target_option*, const cl_target_option*)': options-save.cc:9291:38: error: comparison betwe

Re: [PATCH v2] c++: Fix type completeness checks for type traits [PR106838]

On 9/8/22 08:56, Jonathan Wakely wrote: On Wed, 7 Sept 2022 at 16:11, Jason Merrill wrote: On 9/7/22 08:18, Jonathan Wakely wrote: @@ -12080,23 +12098,37 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, tree type1, tree type2) case CPTK_HAS_TRIVIAL_COPY: case CPTK_HAS_T

Re: [PATCH] c++: unnecessary instantiation of constexpr var [PR99130]

On 9/7/22 16:40, Patrick Palka wrote: On Wed, 7 Sep 2022, Jason Merrill wrote: On 9/7/22 15:41, Patrick Palka wrote: Here the use of the constexpr member/variable specialization 'value' from within an unevaluated context causes us to overeagerly instantiate it, via maybe_instantiate_decl calle

Re: [PATCH] c++: unnecessary instantiation of constexpr var [PR99130]

On 9/7/22 15:41, Patrick Palka wrote: Here the use of the constexpr member/variable specialization 'value' from within an unevaluated context causes us to overeagerly instantiate it, via maybe_instantiate_decl called from mark_used, despite only its declaration not its definition being needed.

[pushed] c++: diagnostic for template placeholder in parm [PR106793]

Talking about the declarator form doesn't help when fixing that would get you a different error about placeholders not being valid in a parameter. This also adds a <> fixit, which isn't enough for most templates, but is a start. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/10679

Re: [PATCH v2] coroutines: Ensure there's a top level bind when rewriting [PR106188]

On 9/4/22 15:04, Arsen Arsenović wrote: In the edge case of a coroutine not containing any locals, the ifcd/swch temporaries would get added to the coroutine frame, corrupting its layout. To prevent this, we can make sure there is always a BIND_EXPR at the top of the function body, and thus, alwa

Re: [PATCH] c++: Fix type completeness checks for type traits [PR106838]

On 9/7/22 08:18, Jonathan Wakely wrote: Tested powerpc64le-linux. OK for trunk? -- >8 -- The check_trait_type function is used for a number of different type traits that have different requirements on their arguments. For example, __is_constructible allows arrays of unknown bound even if the ar

Re: [PATCH] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On 9/3/22 12:42, Marek Polacek wrote: This patch implements https://wg21.link/p2266, which, once again, changes the implicit move rules. Here's a brief summary of various changes in this area: r125211: Introduced moving from certain lvalues when returning them r171071: CWG 1148, enable move fro

[PATCH RFA] libstdc++: small dynamic_cast optimization

An email discussion of optimizing EH led me to wonder why we weren't doing this already. Not that this change affects EH at all. Tested x86_64-pc-linux-gnu. Does this seem worthwhile? libstdc++-v3/ChangeLog: * libsupc++/dyncast.cc (__dynamic_cast): Avoid virtual function call i

Re: [PATCH] libcpp, v3: Named universal character escapes and delimited escape sequence tweaks

On 9/3/22 06:54, Jakub Jelinek wrote: On Sat, Sep 03, 2022 at 12:29:52PM +0200, Jakub Jelinek wrote: On Thu, Sep 01, 2022 at 03:00:28PM -0400, Jason Merrill wrote: We might as well use the same flag name, and document it to mean what it currently means for GCC. Ok, following patch introduces

[wwdocs PATCH RFA] contribute: link to kernel doc about patch email

It occurred to me that it would be useful to link to the kernel's documentation for emailing patches. OK? --- htdocs/contribute.html | 5 + 1 file changed, 5 insertions(+) diff --git a/htdocs/contribute.html b/htdocs/contribute.html index c985b87d..60bcf3f8 100644 --- a/htdocs/contribute.ht

[pushed] c++: C++23 operator[] allows default arguments

This usage was intended to be allowed by P2128, but it didn't make it into the final wording. Fixed by CWG 2507. Tested x86_64-pc-linux-gnu, applying to trunk. DR2507 gcc/cp/ChangeLog: * decl.cc (grok_op_properties): Return sooner for C++23 op[]. gcc/testsuite/ChangeLog:

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On 9/1/22 07:14, Jakub Jelinek wrote: On Wed, Aug 31, 2022 at 12:14:22PM -0400, Jason Merrill wrote: On 8/31/22 11:07, Jakub Jelinek wrote: On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote: It could be more explicit, but I think we can assume that from the existing wording; it say

Re: [PATCH] c++: Micro-optimize most_specialized_partial_spec

On 8/31/22 17:15, Patrick Palka wrote: This introduces an early exit test to most_specialized_partial_spec for the common case where we have no partial specializations, which allows us to avoid some unnecessary work. In passing, clean the function up a bit. Bootstrapped and regtested on x86_64-

[pushed] c++: set TYPE_STRING_FLAG for char8_t

While looking at the DWARF handling of char8_t I wondered why we weren't setting TREE_STRING_FLAG on it. I hoped that setting that flag would be an easy fix for PR102958, but it doesn't seem to be sufficicent. But it still seems correct. I also tried setting the flag on char16_t and char32_t, bu

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On 8/31/22 11:07, Jakub Jelinek wrote: On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote: It could be more explicit, but I think we can assume that from the existing wording; it says it designates the named character. If there is no such character, that cannot be satisfied, so it mu

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On 8/31/22 10:35, Jakub Jelinek wrote: On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote: If #define z(x) 0 #define a z( int x = a\NARG); is valid in C and C++ <= 20 then #define z(x) 0 #define a z( int x = a\N{LATIN SMALL LETTER A WITH ACUTE}); is too and shall prepr

Re: [PATCH] libcpp, v4: Add -Winvalid-utf8 warning [PR106655]

On 8/31/22 10:15, Jakub Jelinek wrote: On Wed, Aug 31, 2022 at 09:55:29AM -0400, Jason Merrill wrote: On 8/31/22 07:14, Jakub Jelinek wrote: On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote: This hunk now seems worth factoring out of the four places it occurs. It also seems the c

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On 8/30/22 17:37, Jakub Jelinek wrote: On Tue, Aug 30, 2022 at 11:18:20PM +0200, Jakub Jelinek via Gcc-patches wrote: On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote: I'm seeing build failures of glibc for powerpc64, as illustrated by the following C code: #if 0 \NARG #endif (the

Re: [PATCH] libcpp, v3: Add -Winvalid-utf8 warning [PR106655]

On 8/31/22 07:14, Jakub Jelinek wrote: On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote: This hunk now seems worth factoring out of the four places it occurs. It also seems the comment for _cpp_valid_utf8 needs to be updated: it currently says it's not called when parsing a string.

<    3   4   5   6   7   8   9   10   11   12   >