tree 64c890d3881b2fc7ea22a136b69602ecd2a55e4d
parent e7399b9d4225f54e000c7252f7aedf7580caa113
author Jakub Jelinek <jakub@redhat.com> 1764271137 +0100
committer Jakub Jelinek <jakub@gcc.gnu.org> 1765177668 +0100

c: Fix ICE in c_type_tag on va_list [PR121506]

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.

2025-11-27  Jakub Jelinek  <jakub@redhat.com>

	PR c/121506
	* c-typeck.cc (c_type_tag): If TYPE_NAME is TYPE_DECL
	with non-NULL DECL_NAME, return that.

	* gcc.dg/pr121506.c: New test.

(cherry picked from commit ca19686a6b87696c0ecea5e9fce825b5e5e10144)