]> git.ipfire.org Git - thirdparty/gcc.git/commit
c: Fix ICE in c_type_tag on va_list [PR121506]
authorJakub Jelinek <jakub@redhat.com>
Thu, 27 Nov 2025 19:18:57 +0000 (20:18 +0100)
committerJakub Jelinek <jakub@gcc.gnu.org>
Thu, 27 Nov 2025 19:18:57 +0000 (20:18 +0100)
commitca19686a6b87696c0ecea5e9fce825b5e5e10144
treec48d0c669a25eaa4e09dc925a68f486ed6b33a0c
parentf768b1543c36d3d0557dfb07d3c27746ee7058a7
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.
gcc/c/c-typeck.cc
gcc/testsuite/gcc.dg/pr121506.c [new file with mode: 0644]