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

Patrick Palka patrick@parcs.ath.cx
Fri Feb 5 21:42:00 GMT 2016


On Fri, Feb 5, 2016 at 12:51 PM, Jason Merrill <jason@redhat.com> wrote:
> On 02/05/2016 09:13 AM, Jason Merrill wrote:
>>
>> On 02/05/2016 07:54 AM, Patrick Palka wrote:
>>>
>>> On Thu, 4 Feb 2016, Patrick Palka wrote:
>>>
>>>> The compiler correctly detects and diagnoses invalid constructor calls
>>>> such as C::C () in a non-template context but it fails to do so while
>>>> processing a class template.  [ Section 3.4.3.1 of the standard is what
>>>> makes these forms of constructor calls illegal -- see
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948#c9  ]
>>>>
>>>> In a non-template context this diagnosis would take place in
>>>> build_new_method_call, called from finish_call_expr, but while
>>>> processing a class template we may exit early out of finish_call_expr
>>>> and never call build_new_method_call.
>>>>
>>>> Thus we never diagnose this invalid constructor call during template
>>>> processing.  So then during instantiation of the enclosing template we
>>>> call tsubst_baselink on this constructor call, during which the call to
>>>> lookup_fnfields returns NULL (because it finds the injected class type C
>>>> not the constructor C).  Because the lookup failed, tsubst_baselink
>>>> returns error_mark_node and this node persists all the way through to
>>>> gimplification where it silently gets discarded.
>>>>
>>>> This patch fixes this problem by diagnosing these invalid constructor
>>>> calls in tsubst_baselink.  Alternatively, we can rewire finish_call_expr
>>>> avoid exiting early while processing a template if the call in question
>>>> is a constructor call.  I'm not sure which approach is better.  This
>>>> approach seems more conservative, since it's just attaching an error
>>>> message to an existing error path.
>>>
>>>
>>> And here is the other approach, which rewires finish_call_expr:
>>
>>
>> I like the second approach better, but you're right that the first is
>> more conservative, so let's go with the first for GCC 6 and switch to
>> the second for GCC 7.
>
>
> I'm also applying this patch so that similar issues ICE rather than silently
> generate bad code.
>

Cool! Good idea.



More information about the Gcc-patches mailing list