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

[Jason Merrill <jason at redhat dot com>]

On Thu, Jan 18, 2018 at 5:53 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> I'm finishing testing on x86_64-linux the below - which anyway seems very
> unlikely to cause regressions because we aren't really stress testing the
> relevant checks in potential_constant_expression_1 much, if at all (surely
> stmtexpr19.C tests static).
>
> Anyway, the issue is the following. In 239268 aka "Implement C++17 constexpr
> lambda" Jason added some checks to potential_constant_expression_1 covering
> static, thread_local and uninitialized var declaration in constexpr function
> context. Then extended to constexpr context more generally in 249382 aka
> "constexpr and static var in statement-expression", with ext/stmtexpr19.C
> covering the static case. Now, it looks like the check for uninitialized
> vars in constexpr functions context is more correctly carried out by
> check_for_uninitialized_const_var instead, because the simple check in
> potential_constant_expression_1 as-is causes the regression pointed out by
> this bug. Thus the fix below which just restricts the check in
> potential_constant_expression_1, and the testcases, one for this bug proper,
> plus one, very similar to stmtexpr19.C, double checking that we are still
> diagnosing in the statement-expression context. I also verified under the
> debugger how for constexpr-83921.C we are actually running
> check_for_uninitialized_const_var on 'f' - which obviously passes.

Seems like this code should either be removed because it's covered by
check_for_uninitialized_const_var, or it should be fixed to check
default_init_uninitialized_part.

So this code is still needed for stmtexpr19.C?  Why doesn't
check_for_... handle that case?

Jason