https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263
--- Comment #6 from Pedro Alves <palves at redhat dot com> --- Yes, agreed. I haven't investigated yet why it ends up with that "<invalid type code 8>", but it's likely that the hack was incomplete and that's a red herring. Hopefully GDB won't have some hard-to-eliminate dependency on a lookup by name somewhere related to these subrange types that would be broken by going nameless. I admit I don't fully understand why these types need to be distinct, and why not emit the underlying type instead of "__unknown__". Grepping the gcc tree for SIZETYPE seems to be that it's always defined to SIZE_TYPE (nothing overrides it), and then that looks like always defined to some C built-in type.