Re: [C++ Patch] PR 83921 ("[7/8 Regression] GCC rejects constexpr initialization of empty aggregate")

[Jason Merrill <jason at redhat dot com>]

On Mon, Jan 22, 2018 at 5:08 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 20/01/2018 02:59, Paolo Carlini wrote:
>>
>> Hi again,
>>
>> On 19/01/2018 23:55, Paolo Carlini wrote:
>>>
>>> ...Therefore It seems to me that a way to more cleanly solve the bug
>>> would be moving something like || !DECL_NONTRIVIALLY_INITIALIZED_P to the
>>> the above check in check_for_uninitialized_const_var, and therefore remove
>>> completely the uninitialized case from potential_constant_expression_1, ...
>>
>> Of course this doesn't work. check_for_uninitialized_const would really
>> need to know that the VAR_DECL appears in a statement expression which is
>> initializing a constexpr variable, nothing to do with
>> DECL_NONTRIVIALLY_INITIALIZED_P.

Ah, that makes sense.  And the static/thread_local checks are
similarly duplicates of checks in start_decl.  It might be nice to
factor those three checks out into another function called in both
places, but perhaps that's not necessary given how small they are.

> Thus the below, carefully tested over the we, would be a change completely
> removing the problematic error_at call, plus some testcases checking that we
> would still do the right thing in a few cases (bug submitter added
> constexpr-83921-2.C). The updated stmtexpr20.C shows that we would reject
> anyway a statement expression using an uninitialized inner, simply because
> the whole initializer would still be flagged as non const.

Do we still diagnose it without the use of the variable?

If not, how about adjusting check_for_uninitialized_const_var to
support calling it from potential_constant_expression_1?  I suppose
we'd need to add a couple of parameters, one complain parm and another
to indicate that the variable is in a constexpr context, and then
return something.

Jason