Hi again, hi Jason,

I can't help further investigating this issue and I have a completely 
different proposal which pursues a different hint of Jason: why the 
TREE_TYPE of such DECL is error_mark_node in the first place? As we 
understand now that is just something that start_decl_1 does when it 
sees an incomplete type. Then why we have that kind of type? The answer 
is this change, back in 2006 (!), for c++/27952:

https://gcc.gnu.org/ml/gcc-patches/2006-10/msg00862.html

which changed the loop in xref_basetypes to early return false after 
error. That implies that the caller skips the body, the type remains 
incomplete. That has non trivial implications: we avoid ICEs but we also 
end up with redundant error messages about incomplete types during error 
recovery. And the inconsistencies shown by the present issue. Thus my 
idea: let's fix that old bug in a different, lighter way and revert the 
bulk of the old fix, just disregard and continue on the erroneous 
duplicate bases in the main xref_basetpes loop. I think at some point 
Jason hinted at that as a general error recovery strategy: we have been 
doing exactly that until 2006!!

In a sense we are also back to my original idea of not zeroing by hand 
the type in cp_parser_class_head.

Anyway, things appear to work fine: no regressions, more terse 
diagnostic, see inherit/crash6.C but also the tweaked 
g++.dg/inherit/virtual1.C (now the diagnostic is *very* similar to that 
produced by clang, by the way, eh, eh) and the new 
g++.dg/inherit/union2.C, no redundant error messages on the declaration 
of u during error recovery.

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?

Ah, there is also another detail: around line 12930 of the decl.c diff, 
I'm also reverting my own 2010 changes to fix c++/30298 (r159637) which 
really had to do with the 2006 change as well: we can have the 
gcc_assert back and still handle correctly inherit/crash1 and crash2 
which I added back then. This is nice, I think.

In conclusion, IMHO this approach is way better than all the other I 
tried so far, modulo the possible need of additional / better error 
recovery measures in build_special_member_call, etc.

Thanks,
Paolo.

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