C++ PATCH for c++/91740 - ICE with constexpr call and ?: in ARRAY_REF

Jason Merrill jason@redhat.com
Sun Sep 15 14:26:00 GMT 2019


On 9/11/19 4:15 PM, Marek Polacek wrote:
> This ICEs since r267272 - more location wrapper nodes, but not because we can't
> cope with new location wrappers, but because that commit introduced a call to
> maybe_constant_value in cp_build_array_ref.  In this testcase we call it with
> 
>    f (VIEW_CONVERT_EXPR<const char[4]>("BAR")) ? 1 : 0
> 
> argument and that crashes in fold_convert because we end up trying to convert
> "BAR" of type const char[4] to const char * when evaluating the call.  At this
> point, decay_conversion hasn't turned the argument into (const char *) "BAR"
> yet.
> 
> The ICE doesn't occur without :?, because then the call will be wrapped in
> NON_DEPENDENT_EXPR and constexpr throws its hands (I'm anthropomorphizing) up
> when it encounters such an expression.
> 
> I noticed that build_non_dependent_expr doesn't wrap op0 of ?: in N_D_E.  This
> is so since r70606 -- Nathan, is there a reason not to do it?  Doing it fixes
> this problem.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2019-09-11  Marek Polacek  <polacek@redhat.com>
> 
> 	PR c++/91740 - ICE with constexpr call and ?: in ARRAY_REF.
> 	* pt.c (build_non_dependent_expr): Call build_non_dependent_expr for
> 	the first operand.
> 
> 	* g++.dg/cpp1y/var-templ63.C: New test.
> 
> diff --git gcc/cp/pt.c gcc/cp/pt.c
> index c5915a5ecd0..775389d8245 100644
> --- gcc/cp/pt.c
> +++ gcc/cp/pt.c
> @@ -26709,7 +26709,7 @@ build_non_dependent_expr (tree expr)
>     if (TREE_CODE (expr) == COND_EXPR)
>       return build3 (COND_EXPR,
>   		   TREE_TYPE (expr),
> -		   TREE_OPERAND (expr, 0),
> +		   build_non_dependent_expr (TREE_OPERAND (expr, 0)),
>   		   (TREE_OPERAND (expr, 1)
>   		    ? build_non_dependent_expr (TREE_OPERAND (expr, 1))
>   		    : build_non_dependent_expr (TREE_OPERAND (expr, 0))),

OK.  I wonder why this code copies op0 for the ?: extension rather than 
leave it null?

Jason



More information about the Gcc-patches mailing list