On Thu, Jan 18, 2018 at 5:53 PM, Paolo Carlini <paolo.carl...@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
