On Wed, May 23, 2018 at 9:46 AM, Marek Polacek <pola...@redhat.com> wrote: > The diagnostic code in build_new{,_1} was using maybe_constant_value to fold > the array length, but that breaks while parsing a template, because we might > then leak template codes to the constexpr machinery. > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8? > > 2018-05-23 Marek Polacek <pola...@redhat.com> > > PR c++/85847 > * init.c (build_new_1): Use fold_non_dependent_expr. > (build_new): Likewise. > > * g++.dg/cpp0x/new3.C: New test. > > @@ -2860,7 +2860,7 @@ build_new_1 (vec<tree, va_gc> **placement, tree type, > tree nelts, > /* Lots of logic below. depends on whether we have a constant number of > elements, so go ahead and fold it now. */ > if (outer_nelts) > - outer_nelts = maybe_constant_value (outer_nelts); > + outer_nelts = fold_non_dependent_expr (outer_nelts);
If outer_nelts is non-constant, this will mean that it ends up instantiated but still non-constant, which can lead to problems when the result is used in building up other expressions. I think we want to put the result of folding in a separate variable for use with things that want to know about a constant size, and keep the original outer_nelts for use in building outer_nelts_check. > /* Try to determine the constant value only for the purposes > of the diagnostic below but continue to use the original > value and handle const folding later. */ > - const_tree cst_nelts = maybe_constant_value (nelts); > + const_tree cst_nelts = fold_non_dependent_expr (nelts); ...like we do here. Jason