On 04/19/2017 08:28 AM, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE in modified_type_die, because the
search for a non-qualified variant type with the same rvalue quals
etc. finds pretty randomly qualified type, while modified_type_die
expects that it is either an unqualified type or (if there is no such a
type) type itself. When we are looking for const qualified FUNCTION_TYPE
and find instead volatile qualified FUNCTION_TYPE, then we die on an
assertion that we can't subtract qualifiers from the chosen type to
get to the desired type (only can add them).
The following patch makes sure we pick only the unqualified types.
Bootstrapped/regtested on x86_64-linux and i686-linux with additional
statistics collection which found that both the loops found such an
unqualified type in all cases except for a single fntype in each of the
following testcases:
libstdc++-v3/testsuite/20_util/add_lvalue_reference/value.cc
libstdc++-v3/testsuite/20_util/add_rvalue_reference/value.cc
libstdc++-v3/testsuite/20_util/is_assignable/value.cc
where we didn't find any unqualified types among the variants;
previously we found type itself that way, which is what the patched
compiler does too in that case (see the return lookup_type_die (type)
after it or that type remains the old type).
Ok for trunk?
2017-04-19 Jakub Jelinek <ja...@redhat.com>
PR debug/80461
* dwarf2out.c (modified_type_die, gen_type_die_with_usage):
Check for t with zero TYPE_QUALS_NO_ADDR_SPACE.
* g++.dg/debug/pr80461.C: New test.
I'm going to assume your use of TYPE_QUALS_NO_ADDR_SPACE vs TYPE_QUALS
or TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC is correct.
OK.
jeff
