Re: proposal to make SIZE_TYPE more flexible

["Joseph S. Myers" <joseph at codesourcery dot com>]

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
joseph@codesourcery.com