On Mon, Jan 22, 2018 at 5:08 AM, Paolo Carlini <paolo.carl...@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