Confirmed.  Both 6.1.0 and 7.0 are affected, 5.3.0 is not.  If my bisection script isn't lying it looks like r235033 introduced the ICE.

Yes, it is indeed r235033.
I have no idea how is constexpr handling meant to work vs. gimplification though, perhaps this is also related to PR68949.
What happens in this PR is that we process some constexpr stuff, then gimplify MakeFoo and then process further constexpr stuff.  But gimplification is destructive, destroys the individual parts of DECL_SAVED_TREE as well as clears DECL_SAVED_TREE at the end.

Created attachment 38514 [details]
slightly more reduced test case

We're invoking constexpr evaluation machinery after parsing is complete -- fini_constexpt has already been called.  This occurs during the emission of BarContainer's constructor, after we've destructively gimplified MakeFoo.  We end up in

0xa05bf2 maybe_constant_init(tree_node*, tree_node*)
	../../../src/gcc/cp/constexpr.c:4457
0x929ce6 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
	../../../src/gcc/cp/init.c:4178
0x9db06b cp_gimplify_expr(tree_node**, gimple**, gimple**)
	../../../src/gcc/cp/cp-gimplify.c:592

and from there we have const_expr_eval (Bar) -> const_expr_eval (MakeFoo) -> ICE
The object we're gimplifying is a vec_init_expr

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.

(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.

Adding an at_eof check into try_const fixes the testcase.  (also) Adding an at_eof <= 1 assert into cxx_eval_outermost_constant_expr causes 261 new fails.  Although many are obviously init & ctor related, they're a fairly widely distributed bunch -- one is even abi name mangling. I don't see any a priori reason as to why those calls to cxx_eval_outermost_constant_expr couldn't end up evaluating a constexpr call.

Author: jason
Date: Tue May 31 21:36:46 2016
New Revision: 236955

URL: https://gcc.gnu.org/viewcvs?rev=236955&root=gcc&view=rev
Log:
	PR c++/71166 - constexpr array init

	* decl2.c (c_parse_final_cleanups): Don't call fini_constexpr.

Added:
    branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-array16.C
Modified:
    branches/gcc-6-branch/gcc/cp/ChangeLog
    branches/gcc-6-branch/gcc/cp/decl2.c

So is this PR now fixed on the branch and still broken on the trunk?
If yes, we should turn it into [7 Regression] then.

Yes.  And we should have added a testcase.

At this point it is getting too late to reconsider VEC_INIT_EXPR for GCC 7, so shall we apply the fix from GCC 7 to trunk too?

I think this ought to be P1, because it is a regression from 6.2/6.3 to 7.

Actually, this seems to be fixed on the trunk too.  Fixed in r238395.  Should I add the testcase from this PR and close it?

Adding the testcase.

Author: mpolacek
Date: Fri Jan 13 17:27:54 2017
New Revision: 244450

URL: https://gcc.gnu.org/viewcvs?rev=244450&root=gcc&view=rev
Log:
	PR c++/71166
	* g++.dg/cpp0x/constexpr-array18.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array18.C
Modified:
    trunk/gcc/testsuite/ChangeLog

Fixed.

But gcc-7-branch and 8.x trunk reverted the Remove?

-fini_constexpr ();