[C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446)

[Jakub Jelinek]

On Thu, Dec 20, 2018 at 02:47:01PM -0500, Jason Merrill wrote:
> > --- gcc/cp/constexpr.c.jj	2018-12-12 09:34:17.531736075 +0100
> > +++ gcc/cp/constexpr.c	2018-12-12 11:30:33.986756914 +0100
> > @@ -1198,6 +1198,7 @@ cxx_eval_builtin_function_call (const co
> >        in a constexpr function until we have values for the parameters.  */
> >     if (bi_const_p
> >         && ctx->quiet
> > +      && !ctx->manifestly_const_eval
> 
> I think we want to replace the "quiet" check with manifestly_const_eval,
> rather than adding to it.

Will change that.

> > -	args[i] = cxx_eval_constant_expression (&new_ctx, args[i], false,
> > -						&dummy1, &dummy2);
> > +	{
> > +	  bool non_cst_p = false, ovf_p = false;
> > +	  tree a = cxx_eval_constant_expression (&new_ctx, args[i], false,
> > +						 &non_cst_p, &ovf_p);
> > +	  if ((non_cst_p || ovf_p) && ctx->manifestly_const_eval)
> > +	    {
> > +	      new_ctx.manifestly_const_eval = false;
> > +	      non_cst_p = false;
> > +	      ovf_p = false;
> > +	      a = cxx_eval_constant_expression (&new_ctx, args[i], false,
> > +						&non_cst_p, &ovf_p);
> > +	      new_ctx.manifestly_const_eval = true;
> > +	    }
> 
> Why retry without manifestly_const_eval?  For static initialization we don't
> want to try constant evaluation again with __builtin_is_constant_evaluated
> false if it failed with it true.

The point is that we don't actually require arguments of the builtins to be
constant expressions.  So the above was an attempt - if the argument of a
builtin is a constant expression, then __builtin_is_constant_evaluated
will evaluate to true in there, if it is something different, we can still
try to fold it to something (like maybe_constant_value would be), in
a non-manifestly constant evaluated context; either the whole builtin will
not fold and we give up anyway, or it folds to some constant.
Essentially arguments to the builtin would be treated like separate
constexpr evaluations.

But if you think this is a bad idea, I can remove it, I haven't been
successful in constructing a testcase where this would matter.

	Jakub