https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66668
--- Comment #5 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- The linked page from comment #2 mentions a discussion about this issue which I'm unable to find. Any hints where it is? Anyway, we've looked into it, and it seems that this bit of code generated a duplicate DIE: char a; char * _Atomic restrict h; char * _Atomic i; When handling "h", the algorithm in dwarf2out.c:get_nearest_type_subqualifiers() finds "char *" as the nearest existing type. Then the for-loop in modified_type_die (line 11254) generates an "intermediate" DIE for "char * _Atomic", and the required DIE for "char * _Atomic restrict". Eventually, only the latter one is linked to it's type with "equate_type_number_to_die()", but the intermediate type is not. When the code handles "i", and tries to lookup an existing DIE for "char * _Atomic" (line 11199) it does not find the "intermediate" DIE and generates another one. This is the additional "DW_TAG_atomic" that makes the test case fail. Without looking at the patches that cause this, I believe that with the "early debug" stuff the DIEs are now generated before the list of used types is available to the loop in get_nearest_type_subqualifiers: for (t = TYPE_MAIN_VARIANT (type); t && best_rank < max_rank; t = TYPE_NEXT_VARIANT (t)) It's probably just called earlier now. So, the algorithm to eliminate duplicate type DIEs does not work because it requires a complete and correct list of used types.