On Thu, 27 Nov 2025, Jakub Jelinek wrote: > Hi! > > The C and C++ FEs disagree on what TYPE_NAME on RECORD_TYPE for > structure/class definition is (rather than typedef/using, for > those both have TYPE_NAME of TYPE_DECL with DECL_ORIGINAL_TYPE), > the C FE just uses IDENTIFIER_NODE as TYPE_NAME on RECORD_TYPE, > while the C++ FE uses TYPE_DECL as TYPENAME on RECORD_TYPE and > only DECL_NAME on the TYPE_DECL provides the IDENTIFIER_NODE. > The reason for the C++ FE way is that there can be type definitions > at class scope (rather than just typedefs) and those need to be > among TYPE_FIELDS (so the corresponding TYPE_DECL is in that chain) > etc. > The middle-end can cope with it, e.g. > if (TREE_CODE (TYPE_NAME (node)) == IDENTIFIER_NODE) > pp_tree_identifier (pp, TYPE_NAME (node)); > else if (TREE_CODE (TYPE_NAME (node)) == TYPE_DECL > && DECL_NAME (TYPE_NAME (node))) > dump_decl_name (pp, TYPE_NAME (node), flags); > and many other places. > Now, the backends on various targets create artificial structure > definitions for va_list, e.g. x86 creates struct __va_list_tag > and they do it the C++ FE way so that the C++ FE can cope with those. > Except the new c_type_tag can't deal with that and ICEs. > > The following patch fixes it so that it can handle it too. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK. -- Joseph S. Myers [email protected]
