https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123856
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[15/16 Regression] ICE: in |[15/16 Regression] ICE: in
|c_type_tag, at |c_type_tag, at
|c/c-typeck.cc:609 with -W |c/c-typeck.cc:609 with -W
|and hardbool |and hardbool since r15-9315
CC| |aoliva at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |uecker at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Bet this broke with r15-9315-ga3382d9d675f42db96a51d902afc49a0a4cfadee
Anyway, the TYPE_NAME setting in handle_hardbool_attribute is just weird:
TYPE_NAME (*node) = unqual;
if (TYPE_QUALS (orig) != TYPE_QUALS (*node))
{
*node = build_qualified_type (*node, TYPE_QUALS (orig));
TYPE_NAME (*node) = orig;
}
So, sometimes TYPE_NAME of the hardbool ENUMERAL_TYPE will be INTEGER_TYPE and
sometimes ENUMERAL_TYPE but not a TYPE_DECL or NULL.
Should the function instead differentiate between when orig is a typedef (and
in that
case kind of modify the typedef in place, so set TYPE_NAME (*node) = TYPE_NAME
(orig);) vs. the case when it is not and in that case set TYPE_NAME (*node) =
NULL_TREE; ?
