On December 31, 2015 10:49:14 PM GMT+01:00, Jason Merrill <ja...@redhat.com> wrote: >On 12/31/2015 11:04 AM, Nathan Sidwell wrote: >> Jason, >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583 >> >> It's noticed that the testcase passes with enable-checking build >but >> fails with enable-checking=release. Looking at what is happening, I >> think the checking build is changing the instantiation point of a >template. >> >> The failure manifests in this snippet: >> >> template<int> struct A // { dg-error "has been parsed" } >> { >> int i = (A<0>(), 0); // { dg-error "has been parsed" } >> }; >> >> with a checking build we get the two diagnostics. That's due to the >> following bit of build_non_dependent_expr (pt.c) >> >> /* Try to get a constant value for all non-dependent expressions >in >> order to expose bugs in *_dependent_expression_p and >constexpr. */ >> if (flag_checking && cxx_dialect >= cxx11) >> fold_non_dependent_expr (expr); >> >> Notice the 'flag_checking' check. It's trying to fold the functional >> cast 'A<0> ()'. That is a non-dependent expression, because 'A<0>' >is >> non-dependent (no no bug in *_D_E_p). The instantiation fails >though, >> because we want the default ctor, but that requires a completed >NSDMI. >> >> Requiring an instantiation (for instance, declaring a global var of >> type 'A<0>') causes the release build to issue a 'recursive >> instantiation' diagnostic (on the NSDMI line). I suppose I can add >> dg-bogus and/or xfails to get the testcase to not fail on either >build, >> but the change in instantiation point worries me. >> >> thoughts? > >Maybe disable the fold if parsing_nsdmi()?
But the flag_checking check definitely warrants a comment - it looks wrong. Richard. >Jason