On Wed, 30 Oct 2013, DJ Delorie wrote: > > > It is a deficiency that SIZE_TYPE is defined to be a string at all (and > > likewise for all the other target macros for standard typedefs including > > all those for <stdint.h>). Separately, it's a deficiency that these > > things are target macros rather than target hooks. > > My thought was that there'd be a set of target hooks that returned a > TREE for various types. But as an interim solution, the checks that > use strcmp() should fail into a type lookup-by-name. I.e. replace the > gcc_unreachables with expensive table lookups.
My reasoning is: * You need to have strings as the expansions of macros such as __SIZE_TYPE__. * You also need to have trees for the types, including in places such as the Fortran front end where converting a C type name into a tree may not be particularly convenient. * So the hook should return a type identifier that can be converted both to strings where those are needed and meaningful (in c-cppbuiltin.c) and into trees where those are needed (somewhere in the language-independent compiler). enum integer_type_kind is, if extended in some way to cover target-specific types, pretty much exactly what's wanted here. * If you do that, you eliminate the fragility of multiple orderings of type specifiers being valid in C but the exact ordering "long unsigned int" being needed in SIZE_TYPE. I hope it might be possible to eliminate the long sequence of record_builtin_type calls with such names, or at least simplify it, given some investigation of how they are used - there's a comment "Define `int' and `char' first so that dbx will output them first.", but since some of the calls use NULL as a type name they can't all be needed in order to provide names for debug info. > > Instead of having an __int128 keyword (target-independent) targets > > would be able to define a set of N for which there are __intN > > keywords and for which everything handling __int128 will equally > > handle __intN. > > That sounds great, and would elide the problem of a target needing to > register their own types for those. I hadn't considered simplifying > the intN_t problem, since you *can* register custom types, I was > mostly just thinking about how to *use* those types for size_t et al. Having a keyword is better than having a built-in typedef registered by the back end (or by c-common.c, in the case of __int128_t and __uint128_t), because a keyword can be used together with "_Complex" and "unsigned" in the same ways you could use "int" or "long", but you can't use a typedef with "_Complex" or "unsigned". -- Joseph S. Myers jos...@codesourcery.com
