HI,

On 14/06/2016 15:06, Jason Merrill wrote:
> On 06/11/2016 12:06 PM, Paolo Carlini wrote:
>> The remaining issue to be discussed is what to do about that old bug,
>> c++/27952, a crash in decay_conversion during error recovery, when vtt
>> is found null. I propose to simply check for it in
>> build_special_member_call, avoid passing an unusable null argument to
>> decay_conversion and return back an error_mark_node. We could also do
>> gcc_assert (seen_error()) before returning error_mark_node?
>
> Why is vtt null?

It's a mismatch caused by the structure of xref_basetypes, which first 
computes the number of virtual bases, etc, and then possibly errors out 
and then drops the duplicate bases (or other invalid bases, see the 
additional testcases below involving unions). Thus for:

struct B : A, virtual A { }

when the second A is dropped the work done in the first part of the 
function, thus, in particular:

       vec_alloc (CLASSTYPE_VBASECLASSES (ref), max_vbases);

with max_vbases == 1 becomes inconsistent. As an a obvious check, this:

     struct B : virtual A, A { }

does not cause problems.

The below goes the most obvious way: keeps track of the number of 
dropped virtual bases (direct and indirect, that's important for eg, 
unions too) and if so-to-speak nothing virtual remains at the end of the 
xref_basetypes loop, does a vec_free which undoes the vec_alloc above. I 
considered moving the new code to a separate function, but frankly I'm 
not sure it would add much clarity in this case. Also note, vs the patch 
I posted the last time, there are a few minor changes before the 
xref_basetypes, essentially reverting that 2006 commit more precisely 
(ie, no early returns at all).

What do you think?

Thanks,
Paolo.

/////////////