Yes.
On Fri, Sep 21, 2018 at 1:40 PM, Marek Polacek <pola...@redhat.com> wrote:
> On Fri, Sep 21, 2018 at 11:19:34AM -0400, Jason Merrill wrote:
>> On Fri, Sep 21, 2018 at 11:04 AM, Marek Polacek <pola...@redhat.com> wrote:
>> > On Fri, Sep 21, 2018 at 09:37:53AM +0200, Jakub Jelinek wrote:
>> >> On Thu, Sep 20, 2018 at 11:56:37PM -0400, Marek Polacek wrote:
>> >> > The patch for P0595R1 - is_constant_evaluated had this hunk:
>> >> >
>> >> > @@ -5279,7 +5315,9 @@ maybe_constant_init_1 (tree t, tree decl, bool
>> >> > allow_non_constant)
>> >> > else if (CONSTANT_CLASS_P (t) && allow_non_constant)
>> >> > /* No evaluation needed. */;
>> >> > else
>> >> > - t = cxx_eval_outermost_constant_expr (t, allow_non_constant,
>> >> > false, decl);
>> >> > + t = cxx_eval_outermost_constant_expr (t, allow_non_constant,
>> >> > + !allow_non_constant,
>> >> > + pretend_const_required, decl);
>> >> > if (TREE_CODE (t) == TARGET_EXPR)
>> >> > {
>> >> > tree init = TARGET_EXPR_INITIAL (t);
>> >> >
>> >> > the false -> !allow_non_constant change means that when calling
>> >> > cxx_constant_init strict will be true because cxx_constant_init does
>> >> > not allow
>> >> > non constants. That means that for VAR_DECLs such as __func__ we'll
>> >> > call
>> >> > decl_really_constant_value instead of decl_constant_value. But only
>> >> > the latter
>> >> > can evaluate __func__ to "foo()".
>> >> >
>> >> > Jakub, was there a specific reason for this change? Changing it back
>> >> > still
>> >> > regtests cleanly and the attached test compiles again.
>> >>
>> >> It just didn't feel right that cxx_constant_init which looks like a
>> >> function
>> >> that requires strict conformance still passes false as strict.
>> >> If there is a reason to pass false, I think we need a comment that
>> >> explains
>> >> it.
>> >
>> > I think we use strict = true for *_constant_value, but *_constant_init
>> > should
>> > get strict = false.
>>
>> Right. In _init we try to get constant values for more than just C++
>> constant expressions.
>
> Is the patch OK then?
>
> Marek
