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
