This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH to fix ICE in generic lambda with user-defined conversion (PR c++/84125)
- From: Jason Merrill <jason at redhat dot com>
- To: Marek Polacek <polacek at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 1 Feb 2018 14:35:08 -0500
- Subject: Re: C++ PATCH to fix ICE in generic lambda with user-defined conversion (PR c++/84125)
- Authentication-results: sourceware.org; auth=none
- References: <20180130201801.GL2620@redhat.com>
On Tue, Jan 30, 2018 at 3:18 PM, Marek Polacek <polacek@redhat.com> wrote:
> This testcase breaks since r256550 because we end up trying to build_address of
> a CONSTRUCTOR, but that doesn't work because we hit
> gcc_checking_assert (TREE_CODE (t) != CONSTRUCTOR);
>
> finish_static_assert gets {} as 'condition'.
Well, it gets X{}.
> In the testcase we have a
> user-defined conversion, so {} should be turned to false, via
> perform_implicit_conversion_flags -> ... -> build_user_type_conversion_1, but
> that crashes as explained above.
>
> This only happens while processing generic lambda because processing_template_decl is 1,
> so finish_compound_literal returns {} instead of a TARGET_EXPR.
So I think we should disable the above assert if
processing_template_decl; the CONSTRUCTOR is actually fine here.
> Part of r256550 was this change:
>
> @@ -8640,9 +8642,9 @@ finish_static_assert (tree condition, tree message, location_t location,
> }
>
> /* Fold the expression and convert it to a boolean value. */
> - condition = instantiate_non_dependent_expr (condition);
> - condition = cp_convert (boolean_type_node, condition, tf_warning_or_error);
> - condition = maybe_constant_value (condition);
> + condition = perform_implicit_conversion_flags (boolean_type_node, condition,
> + complain, LOOKUP_NORMAL);
> + condition = fold_non_dependent_expr (condition);
>
> if (TREE_CODE (condition) == INTEGER_CST && !integer_zerop (condition))
> /* Do nothing; the condition is satisfied. */
>
> where instantiate_non_dependent_expr turned {} into TARGET_EXPR <D.2369, {}>,
> which we can process just fine. So perhaps we need to put the call back.
The problem with that is that fold_non_dependent_expr does
instantiate_non_dependent_expr, so adding the call back would mean
instantiating twice in a row, which is likely to break.
Let's just adjust the assert.
Jason