[Bug c++/71166] [6/7 Regression] ICE with nested constexpr/initializer

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71166

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Nathan Sidwell from comment #4)
> build_vec_init_elt (tree.c) says:
> 
> /* Subroutine of build_vec_init_expr: Build up a single element
>    intialization as a proxy for the full array initialization to get things
>    marked as used and any appropriate diagnostics.
> 
>    Since we're deferring building the actual constructor calls until
>    gimplification time, we need to build one now and throw it away so
>    that the relevant constructor gets mark_used before cgraph decides
>    what functions are needed.  Here we assume that init is either
>    NULL_TREE, void_type_node (indicating value-initialization), or
>    another array to copy.  */
> 
> With constexprs now in play, that appears to be an incorrect approach.   I'm
> not sure why it's even sensible to go building things early only to throw
> them away and redo it.  It would seem better to just build the constructor
> (or whatever) tree and keep it.

I was trying with VEC_INIT_EXPR to get the same "floating initialization of an
object to be determined later" semantics that we have with AGGR_INIT_EXPR, but
indeed deferring all that building until after we've thrown away a lot of front
end information doesn't make sense.

For GCC 6 the minimal fix would be to disable try_const if (at_eof > 1), but
for GCC 7 we should reconsider VEC_INIT_EXPR entirely.