[PR86218] handle ck_aggr in compare_ics in both and either conversion
authorAlexandre Oliva <aoliva@redhat.com>
Thu, 7 Feb 2019 07:50:42 +0000 (07:50 +0000)
committerAlexandre Oliva <aoliva@gcc.gnu.org>
Thu, 7 Feb 2019 07:50:42 +0000 (07:50 +0000)
commitdc51dece7ae902317e9131e153ef53d7bc09c564
tree78f49ebb2065ad6209cb9a5f4a12ee47162ef1c8
parent18591d3ee7c0e22c3f81340fbc0a54d5fb6912ca
[PR86218] handle ck_aggr in compare_ics in both and either conversion

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.

for  gcc/cp/ChangeLog

PR c++/86218
* call.c (compare_ics): Deal with ck_aggr in either cs.

for  gcc/testsuite/ChangeLog

PR c++/86218
* g++.dg/cpp0x/pr86218.C: New.

From-SVN: r268606
gcc/cp/ChangeLog
gcc/cp/call.c
gcc/testsuite/ChangeLog
gcc/testsuite/g++.dg/cpp0x/pr86218.C [new file with mode: 0644]