[PR86218] handle ck_aggr in compare_ics in both and either conversion

[Jason Merrill]

On 1/30/19 10:56 AM, Alexandre Oliva wrote:
> Because of rank compares, and checks for ck_list, we know that if we
> see user_conv_p or ck_list in ics1, we'll also see it in ics2.  This
> reasoning does not extend to ck_aggr, however, so we might have
> ck_aggr conversions starting both ics1 and ics2, which we handle
> correctly, or either, which we likely handle by crashing on whatever
> path we take depending on whether ck_aggr is in ics1 or ics2.
> 
> We crash because, as we search the conversion sequences, we may very
> well fail to find what we are looking for, and reach the end of the
> sequence, which is unexpected in all paths.
> 
> This patch arranges for us to take the same path when ck_aggr is in
> ics2 only that we would if it was in ics1 (regardless of ics2), and it
> deals with not finding the kind of conversion we look for there.
> 
> I've changed the type of the literal constant in the testcase, so as
> to hopefully make it well-formed.  We'd fail to reject the narrowing
> conversion in the original testcase, but that's a separate bug.
> 
> Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?
> 
> 
> for  gcc/cp/ChangeLog
> 
> 	PR c++/86218
> 	* call.c (compare_ics): Deal with ck_aggr in either cs.

OK.

Jason