[PATCH] Fix PR c++/68948 (wrong code generation due to invalid constructor call)

[Patrick Palka]

On Fri, Feb 19, 2016 at 2:06 PM, Jason Merrill <jason@redhat.com> wrote:
> On 02/19/2016 11:56 AM, Patrick Palka wrote:
>>
>> On Fri, Feb 19, 2016 at 10:41 AM, Jason Merrill <jason@redhat.com> wrote:
>>>
>>> On 02/18/2016 01:25 PM, Patrick Palka wrote:
>>>>
>>>>
>>>> On Wed, Feb 17, 2016 at 10:51 PM, Jason Merrill <jason@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
>