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


Reply via email to