Re: [PATCH] ubsan: Add -fsanitize-trap= support

On 6/17/22 11:34, Jakub Jelinek via Gcc-patches wrote: On Thu, Jun 16, 2022 at 09:32:02PM +0100, Jonathan Wakely wrote: It looks like clang has addressed this deficiency now: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage Thanks, that is roughly what I'd implement anyway

Re: [PATCH] c++: Use fold_non_dependent_expr rather than maybe_constant_value in __builtin_shufflevector handling [PR106001]

On 6/17/22 03:28, Jakub Jelinek wrote: Hi! In this case the STATIC_CAST_EXPR expressions in the call aren't type nor value dependent, but maybe_constant_value still ICEs on those when processing_template_decl. Calling fold_non_dependent_expr on it instead fixes the ICE and folds them to

[pushed] opts: fix opts_set->x_flag_sanitize

While working on PR104642 I noticed this wasn't getting set. Tested x86_64-pc-linux-gnu, applying to trunk as obvious. gcc/ChangeLog: * opts.cc (common_handle_option) [OPT_fsanitize_]: Set opts_set->x_flag_sanitize. --- gcc/opts.cc | 1 + 1 file changed, 1 insertion(+) diff

Re: [PATCH RFA] ubsan: default to trap on unreachable at -O0 and -Og [PR104642]

On 6/14/22 07:44, Jakub Jelinek wrote: On Mon, Jun 13, 2022 at 03:53:13PM -0400, Jason Merrill via Gcc-patches wrote: When not optimizing, we can't do anything useful with unreachability in terms of code performance, so we might as well improve debugging by turning __builtin_unreachable

[PATCH RFA] ubsan: default to trap on unreachable at -O0 and -Og [PR104642]

When not optimizing, we can't do anything useful with unreachability in terms of code performance, so we might as well improve debugging by turning __builtin_unreachable into a trap. In the PR richi suggested introducing an -funreachable-traps flag for this, but this functionality is already

[PATCH RFA] ubsan: -Wreturn-type and ubsan trap-on-error

I noticed that -fsanitize=undefined -fsanitize-undefined-trap-on-error was omitting the usual -Wreturn-type warning for control flowing off the end of a function. This was because the warning code was looking for calls either to __builtin_unreachable or the UBSan function, but these flags produce

Re: [PATCH] c++: Add support for __real__/__imag__ modifications in constant expressions [PR88174]

On 6/9/22 04:37, Jakub Jelinek wrote: Hi! We claim we support P0415R1 (constexpr complex), but e.g. #include constexpr bool foo () { std::complex a (1.0, 2.0); a += 3.0; a.real (6.0); return a.real () == 6.0 && a.imag () == 2.0; } static_assert (foo ()); fails with test.C:12:20:

Re: [PATCH] c++: optimize specialization of nested class templates

On 6/10/22 12:00, Patrick Palka wrote: On Fri, 10 Jun 2022, Patrick Palka wrote: On Thu, 9 Jun 2022, Patrick Palka wrote: On Thu, 9 Jun 2022, Jason Merrill wrote: On 6/8/22 14:21, Patrick Palka wrote: When substituting a class template specialization, tsubst_aggr_type substitutes the

Re: [PATCH 2/1] c++: optimize specialization of templated member functions

On 6/9/22 15:37, Patrick Palka wrote: On Thu, 9 Jun 2022, Jason Merrill wrote: On 6/9/22 09:00, Patrick Palka wrote: This performs one of the optimizations added by the previous patch to lookup_template_class, to instantiate_template as well. (For the libstdc++ ranges tests this optimization

Re: [PATCH] c++: improve TYPENAME_TYPE hashing [PR65328]

On 6/10/22 09:40, Patrick Palka wrote: The reason compiling the testcase in this PR is so slow is ultimately due to our poor hashing of TYPENAME_TYPE causing a huge amount of hash table collisions in the spec_hasher and typename_hasher tables. In spec_hasher, we don't hash the components of a

Re: [PATCH] c++: optimize specialization of nested class templates

On 6/8/22 14:21, Patrick Palka wrote: When substituting a class template specialization, tsubst_aggr_type substitutes the TYPE_CONTEXT before passing it to lookup_template_class. This appears to be unnecessary, however, because the the initial value of lookup_template_class's context parameter

Re: [PATCH 2/1] c++: optimize specialization of templated member functions

On 6/9/22 09:00, Patrick Palka wrote: This performs one of the optimizations added by the previous patch to lookup_template_class, to instantiate_template as well. (For the libstdc++ ranges tests this optimization appears to be effective around 30% of the time, i.e. 30% of the time context of

Re: [PATCH] c++: Fix up ICE on __builtin_shufflevector constexpr evaluation [PR105871]

On 6/8/22 02:08, Jakub Jelinek wrote: Hi! As the following testcase shows, BIT_FIELD_REF result doesn't have to have just integral type, it can also have vector type. And in that case cxx_eval_bit_field_ref just ICEs on it because it is unprepared for that case, creates the initial value with

[pushed] c++: non-templated friends [PR105852]

The previous patch for 105852 avoids copying DECL_TEMPLATE_INFO from a non-templated friend, but it really shouldn't have it in the first place. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105852 gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Change non-templated

[pushed] c++: redeclared hidden friend take 2 [PR105852]

My previous patch for 105761 avoided copying DECL_TEMPLATE_INFO from a friend to a later definition, but in this testcase we have first a non-friend declaration and then a definition, and we need to avoid copying in that case as well. But we do still want to set new_template_info to avoid GC

Re: [PATCH] c++: alias template arguments are evaluated [PR101906]

On 6/7/22 14:25, Patrick Palka wrote: On Wed, 23 Mar 2022, Jason Merrill wrote: On 3/22/22 14:31, Patrick Palka wrote: On Tue, 22 Mar 2022, Patrick Palka wrote: Here we're neglecting to clear cp_unevaluated_operand when substituting into the arguments of the alias template-id skip<(T(), 0),

Re: [PATCH] c++: function NTTP argument considered unused [PR53164, PR105848]

On 6/7/22 15:18, Patrick Palka wrote: On Tue, 7 Jun 2022, Jason Merrill wrote: On 6/7/22 09:24, Patrick Palka wrote: On Mon, 6 Jun 2022, Jason Merrill wrote: On 6/6/22 14:27, Patrick Palka wrote: On Thu, 7 Oct 2021, Jason Merrill wrote: On 10/7/21 11:17, Patrick Palka wrote: On Wed, 6

Re: [PATCH] c++: remove single-parameter version of mark_used

On 6/7/22 10:16, Patrick Palka wrote: gcc/cp/ChangeLog: * cp-tree.h (mark_used): Remove single-parameter overload. Add default argument to the two-parameter overload. * decl2.cc (mark_used): Likewise. OK. --- gcc/cp/cp-tree.h | 3 +-- gcc/cp/decl2.cc | 8

Re: [PATCH] c++: function NTTP argument considered unused [PR53164, PR105848]

On 6/7/22 09:24, Patrick Palka wrote: On Mon, 6 Jun 2022, Jason Merrill wrote: On 6/6/22 14:27, Patrick Palka wrote: On Thu, 7 Oct 2021, Jason Merrill wrote: On 10/7/21 11:17, Patrick Palka wrote: On Wed, 6 Oct 2021, Jason Merrill wrote: On 10/6/21 15:52, Patrick Palka wrote: On Wed, 6

Re: [PATCH] Fix behavior of using enum in dependent contexts [PR105787]

On 6/6/22 15:39, Michael Colavita via Gcc-patches wrote: Per #105787, "using enum" in a dependent context leads to an ICE. This is because the type substitution logic doesn't properly juggle the context and abstract origin for CONST_DECLs introduced via using enum. When we are performing type

Re: [PATCH] c++: function NTTP argument considered unused [PR53164, PR105848]

On 6/6/22 14:27, Patrick Palka wrote: On Thu, 7 Oct 2021, Jason Merrill wrote: On 10/7/21 11:17, Patrick Palka wrote: On Wed, 6 Oct 2021, Jason Merrill wrote: On 10/6/21 15:52, Patrick Palka wrote: On Wed, 6 Oct 2021, Patrick Palka wrote: On Tue, 5 Oct 2021, Jason Merrill wrote: On

Re: [C++ PATCH take #2] PR c++/96442: Improved error recovery in enumerations.

On 6/5/22 06:09, Roger Sayle wrote: Hi Jason, My apologies for the long delay, but I've finally got around to implementing your suggested improvements (implied by your review): https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591504.html of my patch for PR c++/96442:

Re: [PATCH] c++: Allow mixing GNU/std-style attributes [PR69585]

On 6/3/22 20:05, Marek Polacek wrote: cp_parser_attributes_opt doesn't accept GNU attributes followed by [[]] attributes and vice versa; only a sequence of attributes of the same kind. That causes grief for code like: struct __attribute__ ((may_alias)) alignas (2) struct S { }; or

Re: [PATCH] c++: value-dep but not type-dep decltype operand [PR105756]

On 6/3/22 14:13, Patrick Palka wrote: On Thu, 2 Jun 2022, Patrick Palka wrote: On Thu, 2 Jun 2022, Jason Merrill wrote: On 6/1/22 14:20, Patrick Palka wrote: r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent decltype operands by relaxing instantiate_non_dependent_expr

[pushed] c++: redeclared hidden friend [PR105761]

Here, when we see the second declaration of f we match it with the first one, copy over DECL_TEMPLATE_INFO, and then try to use it when parsing the definition, leading to confusion. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105761 gcc/cp/ChangeLog: * decl.cc

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On 6/3/22 11:04, Patrick Palka wrote: On Fri, 3 Jun 2022, Jason Merrill wrote: On 6/3/22 10:46, Patrick Palka wrote: On Thu, 2 Jun 2022, Jason Merrill wrote: On 6/2/22 15:57, Patrick Palka wrote: On Thu, 2 Jun 2022, Jason Merrill wrote: On 5/27/22 09:57, Patrick Palka wrote: On Thu, 26

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On 6/3/22 10:46, Patrick Palka wrote: On Thu, 2 Jun 2022, Jason Merrill wrote: On 6/2/22 15:57, Patrick Palka wrote: On Thu, 2 Jun 2022, Jason Merrill wrote: On 5/27/22 09:57, Patrick Palka wrote: On Thu, 26 May 2022, Patrick Palka wrote: On Thu, 26 May 2022, Jason Merrill wrote: On

Re: [PATCH] c++: fix broken copy elision with nested TARGET_EXPRs [PR105550]

On 5/26/22 11:01, Marek Polacek wrote: In this problem, we are failing to properly perform copy elision with a conditional operator, so this: constexpr A a = true ? A{} : A{}; fails with: error: 'A{((const A*)(&))}' is not a constant expression The whole initializer is TARGET_EXPR

Re: [PATCH] c++: find_template_parameters and PARM_DECLs [PR105797]

On 6/1/22 12:44, Patrick Palka wrote: As explained in r11-4959-gde6f64f9556ae3, the atom cache assumes two equivalent expressions (according to cp_tree_equal) must use the same template parameters (according to find_template_parameters). This assumption turned out to not hold for TARGET_EXPR,

Re: [PATCH] c++: ICE with template NEW_EXPR [PR105803]

On 6/2/22 16:33, Marek Polacek wrote: On Thu, Jun 02, 2022 at 04:26:27PM -0400, Jason Merrill wrote: On 6/2/22 16:10, Marek Polacek wrote: index 1346a1d4c10..2bbd8785627 100644 --- a/gcc/cp/constexpr.cc +++ b/gcc/cp/constexpr.cc @@ -9039,10 +9039,18 @@ potential_constant_expression_1 (tree t,

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On 6/2/22 15:57, Patrick Palka wrote: On Thu, 2 Jun 2022, Jason Merrill wrote: On 5/27/22 09:57, Patrick Palka wrote: On Thu, 26 May 2022, Patrick Palka wrote: On Thu, 26 May 2022, Jason Merrill wrote: On 5/26/22 14:57, Patrick Palka wrote: On Thu, 26 May 2022, Patrick Palka wrote:

Re: [PATCH] c++: ICE with template NEW_EXPR [PR105803]

On 6/2/22 16:10, Marek Polacek wrote: On Thu, Jun 02, 2022 at 03:42:15PM -0400, Jason Merrill wrote: On 6/2/22 10:03, Marek Polacek wrote: On Thu, Jun 02, 2022 at 08:42:36AM -0400, Patrick Palka wrote: On Wed, 1 Jun 2022, Marek Polacek via Gcc-patches wrote: Here we ICE because

Re: [PATCH] c++: value-dep but not type-dep decltype operand [PR105756]

On 6/1/22 14:20, Patrick Palka wrote: r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent decltype operands by relaxing instantiate_non_dependent_expr to check instantiation_dependent_uneval_expression_p. But as the testcase below demonstrates, this predicate is too

Re: [PATCH] c++: don't substitute TEMPLATE_PARM_CONSTRAINT [PR100374]

On 6/2/22 11:40, Patrick Palka wrote: On Tue, 31 May 2022, Jason Merrill wrote: On 5/31/22 08:56, Patrick Palka wrote: On Sun, 29 May 2022, Jason Merrill wrote: On 5/29/22 22:10, Jason Merrill wrote: On 5/27/22 14:05, Patrick Palka wrote: This makes us avoid substituting into the

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On 5/27/22 09:57, Patrick Palka wrote: On Thu, 26 May 2022, Patrick Palka wrote: On Thu, 26 May 2022, Jason Merrill wrote: On 5/26/22 14:57, Patrick Palka wrote: On Thu, 26 May 2022, Patrick Palka wrote: Here we expect the calls to BaseClass::baseDevice resolve to the second, third and

Re: [PATCH] c++: ICE with template NEW_EXPR [PR105803]

On 6/2/22 10:03, Marek Polacek wrote: On Thu, Jun 02, 2022 at 08:42:36AM -0400, Patrick Palka wrote: On Wed, 1 Jun 2022, Marek Polacek via Gcc-patches wrote: Here we ICE because value_dependent_expression_p gets a NEW_EXPR whose operand is a type, and we go to the default case which just

[pushed] c++: more constexpr empty base [PR105795]

Following on from the previous patch, for trunk let's consistently set ctx->ctor to NULL_TREE for empty subobjects. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105795 gcc/cp/ChangeLog: * constexpr.cc (init_subob_ctx): Clear ctx->ctor for empty subob.

[pushed] c++: constexpr empty aggr [PR105795]

In this testcase, leaving ctx->ctor pointing to the enclosing object meant that evaluating the initializer for the subobject clobbered previous initializers for the enclosing object. So do update ctx->ctor, just don't add it to the enclosing object ctor. Tested x86_64-pc-linux-gnu, applying to

[pushed] c++: auto and dependent member name [PR105734]

In r12-3643 I improved our handling of type names after . or -> when unqualified lookup doesn't find anything, but it needs to handle auto specially. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105734 gcc/cp/ChangeLog: * parser.cc

[pushed] c++: auto function as function argument [PR105779]

This testcase demonstrates that the issue in PR105623 is not limited to templates, so we should do the marking in a less template-specific place. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105779 gcc/cp/ChangeLog: * call.cc (resolve_args): Call mark_single_function

[pushed] build: TAGS and .cc transition

A few globs missed in the .c -> .cc transition. Some targets were looking at both *.c and *.cc, but there are no longer any .c files to scan. Applying as obvious. gcc/ChangeLog: * Makefile.in (TAGS): Look at libcpp/*.cc. gcc/c/ChangeLog: * Make-lang.in (c.tags): Look at *.cc.

Re: [PATCH] c++: use auto_timevar instead of timevar_push/pop

On 5/31/22 13:47, Patrick Palka wrote: On Tue, 31 May 2022, Patrick Palka wrote: r12-5487-g9bf69a8558638c replaced uses of timevar_cond_push/pop with auto_cond_timevar and removed now unnecessary wrapper functions. This patch does the same for timevar_push/pop and auto_timevar. Bootstrapped

Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491]

On 5/31/22 12:41, Patrick Palka wrote: On Wed, 18 May 2022, Jason Merrill wrote: On 5/17/22 12:34, Patrick Palka wrote: On Sat, May 7, 2022 at 5:18 PM Jason Merrill wrote: On 5/6/22 16:46, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 16:10, Patrick Palka

Re: [PATCH] c++: squash cp_build_qualified_type/_real

On 5/31/22 13:13, Patrick Palka wrote: This replaces the two differently named versions of the same function with a single function using a default function argument. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. gcc/cp/ChangeLog: * cp-tree.h

Re: [PATCH] c++: non-dep call with empty TYPE_BINFO [PR105758]

On 5/31/22 12:28, Patrick Palka wrote: Here the out-of-line definition of Z::z causes duplicate_decls to change z's type to use the implicit instantiation Z rather than the corresponding primary template type (which is also the type of the injected class name), and the former, being a dependent

Re: [PATCH] c++: don't substitute TEMPLATE_PARM_CONSTRAINT [PR100374]

On 5/31/22 08:56, Patrick Palka wrote: On Sun, 29 May 2022, Jason Merrill wrote: On 5/29/22 22:10, Jason Merrill wrote: On 5/27/22 14:05, Patrick Palka wrote: This makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINT of each template parameter except as necessary for (friend)

Re: [PATCH] c++: don't substitute TEMPLATE_PARM_CONSTRAINT [PR100374]

On 5/29/22 22:10, Jason Merrill wrote: On 5/27/22 14:05, Patrick Palka wrote: This makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINT of each template parameter except as necessary for (friend) declaration matching, like we already do for the overall TEMPLATE_PARMS_CONSTRAINTS of a

Re: [PATCH] c++: don't substitute TEMPLATE_PARM_CONSTRAINT [PR100374]

On 5/27/22 14:05, Patrick Palka wrote: This makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINT of each template parameter except as necessary for (friend) declaration matching, like we already do for the overall TEMPLATE_PARMS_CONSTRAINTS of a template parameter list. Bootstrapped

Re: [PATCH] c++: Add !TYPE_P assert to type_dependent_expression_p [PR99080]

On 5/27/22 12:43, Marek Polacek wrote: On Fri, May 27, 2022 at 11:52:12AM -0400, Jason Merrill wrote: On 5/26/22 20:33, Marek Polacek wrote: As discussed here: , type_dependent_expression_p should not be called with a type

Re: [PATCH] c++: use current_template_constraints more

On 5/27/22 14:05, Patrick Palka wrote: gcc/cp/ChangeLog: * decl.cc (grokvardecl): Use current_template_constraints. (xref_tag): Likewise. * semantics.cc (finish_template_template_parm): Likewise. OK. --- gcc/cp/decl.cc | 13 +++-- gcc/cp/semantics.cc

Re: [PATCH] c++: document comp_template_args's default args

On 5/27/22 14:07, Patrick Palka wrote: In passing, use bool for its return type. OK. gcc/cp/ChangeLog: * cp-tree.h (comp_template_args): Change return type to bool. * pt.cc (comp_template_args): Document default arguments. Change return type to bool and adjust

Re: [PATCH] libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]

On 5/27/22 04:16, Jakub Jelinek wrote: Hi! The first part of the following testcase (m1-m3 macros and its use) regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows, the problem isn't new, we can emit a CPP_PADDING token to avoid it from being adjacent to whatever comes

[pushed] c++: lambda in concept [PR105652]

We currently check satisfaction in the context of the constrained declaration (which may be wrong, see PR104111). When checking C for S, we currently substitute into the lambda in the context of S (rather than S, which seems wrong if the above isn't wrong), so the new closure type thinks its

Re: [PATCH] c++: Fix ICE with -Wmismatched-tags [PR105725]

On 5/27/22 11:46, Marek Polacek wrote: Here we ICE with -Wmismatched-tags on something like template bool B>>; Specifically, the "class T::foo" bit. There, class_decl_loc_t::add gets a TYPENAME_TYPE as TYPE, rather than a class/union type, so checking TYPE_BEING_DEFINED will crash. I

Re: [PATCH] c-family: fix attribute constructor ICE [PR90658]

On 5/26/22 20:34, Marek Polacek wrote: Here the C compiler crashes because a FUNCTION_DECL got into get_priority -> default_conversion, and the C FE's version of d_c specifically asserts that it doesn't get a FUNCTION_DECL. All uses of default_conversion in c-attribs.cc are guarded by !=

Re: [PATCH] c++: Add !TYPE_P assert to type_dependent_expression_p [PR99080]

On 5/26/22 20:33, Marek Polacek wrote: As discussed here: , type_dependent_expression_p should not be called with a type argument. I promised I'd add an assert so here it is. One place needed adjusting, the comment explains

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

On 5/26/22 14:57, Patrick Palka wrote: On Thu, 26 May 2022, Patrick Palka wrote: Here we expect the calls to BaseClass::baseDevice resolve to the second, third and fourth overloads respectively in light of the cv-qualifiers of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the

Re: [PATCH v2] c++: suppress -Waddress warnings with *_cast [PR105569]

On 5/26/22 09:33, Marek Polacek wrote: On Thu, May 26, 2022 at 09:26:16AM -0400, Jason Merrill wrote: On 5/25/22 16:25, Marek Polacek wrote: On Wed, May 18, 2022 at 09:43:47AM -0400, Jason Merrill wrote: On 5/16/22 13:06, Marek Polacek wrote: dynamic_cast can legally return nullptr, so I

Re: [PATCH v2] c++: suppress -Waddress warnings with *_cast [PR105569]

On 5/25/22 16:25, Marek Polacek wrote: On Wed, May 18, 2022 at 09:43:47AM -0400, Jason Merrill wrote: On 5/16/22 13:06, Marek Polacek wrote: dynamic_cast can legally return nullptr, so I don't think it's helpful for -Waddress to warn for if (dynamic_cast()) // ... More generally,

Re: [PATCH] c++: constrained partial spec forward decl [PR96363]

On 5/25/22 13:24, Patrick Palka wrote: Here during cp_parser_single_declaration for #2, we were calling associate_classtype_constraints for TPL (the primary template type) before maybe_process_partial_specialization could get a chance to notice that we're in fact declaring a distinct constrained

Re: [PATCH] c++: fix ICE on invalid attributes [PR96637]

On 5/25/22 14:49, Marek Polacek wrote: On Tue, May 24, 2022 at 08:22:22AM -0400, Jason Merrill wrote: On 4/29/22 10:12, Marek Polacek wrote: This patch fixes crashes with invalid attributes. Arguably it could make sense to assert seen_error() too. So in this testcase we have TREE_CHAIN of a

[pushed] c++: CTAD with alias and nested template [PR105655]

Here, alias_ctad_tweaks expect tsubst_decl of a FUNCTION_DECL to return a FUNCTION_DECL. A reasonable expectation, but in this case we were replacing the template args of the class-scope deduction guide with equivalent args, so looking in the hash table we found the partial instantiation stored

[pushed] c++: deduction from auto fn [PR105623]

Since my patch for PR90451, we defer mark_used of single functions as late as possible. And since my r12-1273, we keep BASELINK from lookup around rather than reconstruct it later. These both made us try to instantiate g with a function type that still had 'auto' as its return type. Tested

[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

[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

Re: [PATCH v5] c++: ICE with temporary of class type in DMI [PR100252]

On 5/24/22 16:21, Marek Polacek wrote: On Tue, May 24, 2022 at 04:01:37PM -0400, Jason Merrill wrote: On 5/24/22 09:55, Marek Polacek wrote: On Tue, May 24, 2022 at 08:36:39AM -0400, Jason Merrill wrote: On 5/16/22 11:36, Marek Polacek wrote: +static tree

[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

[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

Re: [PATCH v5] c++: ICE with temporary of class type in DMI [PR100252]

On 5/24/22 09:55, Marek Polacek wrote: On Tue, May 24, 2022 at 08:36:39AM -0400, Jason Merrill wrote: On 5/16/22 11:36, Marek Polacek wrote: +static tree +replace_placeholders_for_class_temp_r (tree *tp, int *, void *data) +{ + tree t = *tp; + tree full_expr = *static_cast(data); + + /*

[pushed] c++: *this folding in constexpr call

The code in cxx_eval_call_expression to fold *this was doing the wrong thing for array decay; we can use cxx_fold_indirect_ref instead. This didn't end up being necessary to fix anything, but still seems like an improvement. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog:

[pushed] c++: discarded-value and constexpr

I've been thinking for a while that the 'lval' parameter needed a third value for discarded-value expressions; most importantly, cxx_eval_store_expression does extra work for an lvalue result, and we also don't want to do the l->r conversion. Mostly this is pretty mechanical. Apart from the

[pushed] c++: constexpr empty base redux [PR105622]

Here calling the constructor for s.__size_ had ctx->ctor for s itself because cxx_eval_store_expression doesn't create a ctor for the empty field. Then cxx_eval_call_expression returned the s initializer, and my empty base overhaul in r13-160 got confused because the type of init is not an empty

Re: [PATCH v5] c++: ICE with temporary of class type in DMI [PR100252]

On 5/16/22 11:36, Marek Polacek wrote: On Sat, May 14, 2022 at 11:13:28PM -0400, Jason Merrill wrote: On 5/13/22 19:41, Marek Polacek wrote: --- a/gcc/cp/typeck2.cc +++ b/gcc/cp/typeck2.cc @@ -1371,6 +1371,70 @@ digest_init_flags (tree type, tree init, int flags, tsubst_flags_t complain)

Re: [PATCH] c++: fix ICE on invalid attributes [PR96637]

On 4/29/22 10:12, Marek Polacek wrote: This patch fixes crashes with invalid attributes. Arguably it could make sense to assert seen_error() too. So in this testcase we have TREE_CHAIN of a TREE_LIST pointing to error_mark_node? Can we avoid that? Bootstrapped/regtested on

Re: [PATCH] c++: set TYPE_CANONICAL for most templated types

On 5/23/22 16:25, Patrick Palka wrote: On 5/18/22, Jason Merrill wrote: On 5/16/22 15:58, Patrick Palka wrote: When processing a class template specialization, lookup_template_class uses structural equality for the specialized type whenever one of its template arguments uses structural

Re: [PATCH] c++: fix SIGFPE with -Wclass-memaccess [PR105634]

On 5/17/22 19:57, Marek Polacek wrote: Here we crash because we attempt to % by 0. Thus fixed. While at it, I've moved the -Wclass-memaccess tests into warn/. I've checked that the # of expected passes is the same before/after the move. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for

Re: [PATCH v3] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

On 5/17/22 19:55, Marek Polacek wrote: On Tue, May 10, 2022 at 09:54:12AM -0400, Marek Polacek wrote: On Tue, May 10, 2022 at 08:58:46AM -0400, Jason Merrill wrote: On 5/7/22 18:26, Marek Polacek wrote: Corrected version that avoids an uninitialized warning: This PR complains that we emit

Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491]

On 5/17/22 12:34, Patrick Palka wrote: On Sat, May 7, 2022 at 5:18 PM Jason Merrill wrote: On 5/6/22 16:46, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 16:10, Patrick Palka wrote: On Fri, 6 May 2022, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill

Re: [PATCH] c++: set TYPE_CANONICAL for most templated types

On 5/16/22 15:58, Patrick Palka wrote: When processing a class template specialization, lookup_template_class uses structural equality for the specialized type whenever one of its template arguments uses structural equality. This the sensible thing to do in a vacuum, but given that we already

Re: [PATCH] c++: suppress -Waddress warnings with *_cast [PR105569]

On 5/16/22 13:06, Marek Polacek wrote: dynamic_cast can legally return nullptr, so I don't think it's helpful for -Waddress to warn for if (dynamic_cast()) // ... More generally, it's likely not useful to warn for the artificial POINTER_PLUS_EXPRs created by build_base_path. Normally

[pushed] c++: constexpr ref to array of array [PR102307]

The problem here is that first check_initializer calls build_aggr_init_full_exprs, which does overload resolution, but then in the case of failed constexpr throws away the result and does it again in build_functional_cast. But in the first overload resolution, reshape_init_array_1 decided to

PING#2 Re: [PATCH RFA] attribs: fix typedefs in generic code [PR105492]

Ping. On 5/10/22 16:48, Jason Merrill wrote: Ping? On 5/5/22 14:07, Jason Merrill wrote: In my patch for PR100545 I added an assert to check for broken typedefs in set_underlying_type, and it found one in this case: rs6000_handle_altivec_attribute had the same problem as

[pushed] c++: hidden friend access [DR1699]

It has come up several times that Clang considers hidden friends of a class to be sufficiently memberly to be covered by a friend declaration naming the class. This is somewhat unclear in the standard: [class.friend] says "Declaring a class to be a friend implies that private and protected

[pushed] c++: parsing injected-class-name as template

While I was backporting the patch for PR102300, it occurred to me that it would be cleaner to look through the injected-class-name earlier in the function. I don't think this changes any test results. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog: * parser.cc

[pushed] c++: array {}-init [PR105589]

My patch for 105191 made us use build_value_init more frequently from build_vec_init_expr, but build_value_init doesn't like to be called to initialize a class in a template. That's caused trouble in the past, and seems like a strange restriction, so let's fix it. Tested x86_64-pc-linux-gnu,

Re: [PATCH v4] c++: ICE with temporary of class type in DMI [PR100252]

On 5/13/22 19:41, Marek Polacek wrote: On Sat, May 07, 2022 at 06:02:13PM -0400, Jason Merrill wrote: On 5/7/22 15:11, Marek Polacek wrote: On Tue, May 03, 2022 at 04:59:38PM -0400, Jason Merrill wrote: Does this testcase still work with this patch? struct A { const A* p = this; };

Re: [PATCH] c++: improve a couple of TMPL_ARGS_* accessor macros

On 5/12/22 14:14, Patrick Palka wrote: On Thu, 12 May 2022, Patrick Palka wrote: After r13-332-g88459c3965e2a2, it looks like we can safely remove the NULL test from TMPL_ARGS_HAVE_MULTIPLE_LEVELS, which simplifies its semantics. And TMPL_ARGS_LEVEL should verify the level argument is sane in

[pushed] c++: lambda template in requires [PR105541]

Since the patch for PR103408, the template parameters for the lambda in this test have level 1 instead of 2, and we were treating null template args as 1 level of arguments, so tsubst_template_parms decided it had nothing to do. Fixed by distinguishing between <> and no args at all, which is what

Re: [PATCH] tree: introduce range adaptor for TREE_VEC

On 5/11/22 15:20, Patrick Palka wrote: This patch implements a simple tree wrapper, named tree_vec_range, which lets us idiomatically iterate over all the elements of a TREE_VEC using a C++11 range-based for loop: // v is a TREE_VEC for (tree e : tree_vec_range (v)) ... This is

[pushed] c++: fix arm-eabi bootstrap [PR105567]

Since my r13-112, in the template we were changing 'return' to 'return this' on cdtor_returns_this targets, and then getting confused by that when instantiating. So only make that change at instantiation time. Tested x86_64-pc-linux-gnu and arm-eabi sim, applying to trunk. PR

PING Re: [PATCH RFA] attribs: fix typedefs in generic code [PR105492]

Ping? On 5/5/22 14:07, Jason Merrill wrote: In my patch for PR100545 I added an assert to check for broken typedefs in set_underlying_type, and it found one in this case: rs6000_handle_altivec_attribute had the same problem as handle_mode_attribute. So let's move the fixup into

Re: [PATCH 2/2] c++: Remove SET_PACK_EXPANSION_PATTERN / SET_ARGUMENT_PACK_ARGS

On 5/10/22 09:40, Patrick Palka wrote: Unlike in C, in C++ the conditional operator yields an lvalue if both branches are lvalues, so we can just assign to PACK_EXPANSION_PATTERN and ARGUMENT_PACK_ARGS directly. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?

Re: [PATCH 1/2] c++: Harden *_PACK_EXPANSION and *_ARGUMENT_PACK macros

On 5/10/22 09:40, Patrick Palka wrote: The accessor macros for TYPE_PACK_EXPANSION/EXPR_PACK_EXPANSION and TYPE_ARGUMENT_PACK/NONTYPE_ARGUMENT_PACK should check the tree code of the argument. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK.

Re: [PATCH v2] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

On 5/7/22 18:26, Marek Polacek wrote: Corrected version that avoids an uninitialized warning: This PR complains that we emit the "enumeration value not handled in switch" warning even though the enumerator was marked with the [[maybe_unused]] attribute. The first snag was that I couldn't just

[pushed] c++: fix arm-eabi crash building libstdc++ [PR105529]

My recent change to cxx_eval_store_expression asserts that the target and value can only end up having different types in the case of an empty base; this was crashing arm-eabi compilers because in that ABI [cd]tors return *this, and weren't converting it to void* first. This also shares the

Re: [PATCH] c++: ICE with constexpr dtor on ARM [PR105529]

On 5/9/22 18:41, Marek Polacek wrote: When compiling this test on ARM with -O, we ICE in cxx_eval_store_expression while evaluating a CALL_EXPR allocator::~allocator (). Its body has this store: = this The RHS is evaluated into of type allocator *. The object, , is of type void *.

Re: [PATCH] c++: Implement P2324R2, labels at the end of compound-stmts [PR103539]

On 5/8/22 20:26, Marek Polacek wrote: This patch implements C++23 , which allows labels at the end of a compound statement. Its C FE counterpart was already implemented in r11-4813. In cp_parser_statement I rely on in_compound to determine whether we're in a

Re: [PATCH v3] c++: ICE with temporary of class type in DMI [PR100252]

On 5/7/22 15:11, Marek Polacek wrote: On Tue, May 03, 2022 at 04:59:38PM -0400, Jason Merrill wrote: Does this testcase still work with this patch? struct A { const A* p = this; }; struct B { A a = A{}; }; constexpr B b; static_assert (b.a.p == ); Ouch, no. Thanks for catching this,

Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491]

On 5/6/22 16:46, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 16:10, Patrick Palka wrote: On Fri, 6 May 2022, Patrick Palka wrote: On Fri, 6 May 2022, Jason Merrill wrote: On 5/6/22 14:00, Patrick Palka wrote: On Fri, 6 May 2022, Patrick Palka wrote: On Fri,

[pushed] c++: empty base constexpr adjustment [PR105245]

While looking at PR105245 in stage 4, I wanted to reorganize the code a bit, but it seemed prudent to defer that to stage 1. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/105245 PR c++/100111 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_store_expression):

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