On Fri, Feb 19, 2016 at 2:06 PM, Jason Merrill <ja...@redhat.com> wrote: > On 02/19/2016 11:56 AM, Patrick Palka wrote: >> >> On Fri, Feb 19, 2016 at 10:41 AM, Jason Merrill <ja...@redhat.com> wrote: >>> >>> On 02/18/2016 01:25 PM, Patrick Palka wrote: >>>> >>>> >>>> On Wed, Feb 17, 2016 at 10:51 PM, Jason Merrill <ja...@redhat.com> >>>> wrote: >>>>> >>>>> >>>>> OK. >>>> >>>> >>>> Is this an approval of the 2nd patch for next stage 1? >>> >>> >>> Actually, I've been looking at this area a lot recently in the context of >>> the 10200 fix, and now I think we can go ahead with the 2nd patch now, >>> but >>> without the assert; I think it would fire if we wrote A::A(). >> >> >> I w ill commit the version without the assert shortly, but... >> >> I haven't been able to get the assert to fire even when the A in >> A::A() is dependent because in that case FN should be dependent, so we >> would already have exited out of finish_call_expr due to the >> type_dependent_expression_p (fn) check near the top of >> finish_call_expr. (In particular for dependent A::A(), FN is a >> SCOPE_REF whose 1st operand is the dependent type A and 2nd operand is >> the identifier node A.) >> >> So it seems to me that the assert at that location is safe, since the >> dummy object should be dependent only if the constructor call FN is >> dependent in which case we would never reach the assert. > > > It might be safe given our current dependency analysis, but I'm planning to > tighten that up in GCC 7, along the lines of my 69753 patch that I ended up > backing out. Why do you want the assert?
No good reason. > > Jason >
