RFA: partially hookize *_TYPE_SIZE

[Joseph S. Myers]

On Mon, 29 Nov 2010, Joern Rennecke wrote:

> This hookizes *_TYPE_SIZE for frontends and tree optimizers, as discussed
> in PR46677.

This is partial in the sense that not all uses are converted (note that 
I'm counting uses in headers such as config/glibc-stdint.h as well, and 
uses in target code including libgcc/config/libbid/bid_gcc_intrinsics.h) 
and so it is not possible to start converting targets to define the hooks 
instead of the macros.  (A comment to make things clear for anyone who 
might want to start the actual conversions of targets, not an objection.)

(Also partial in that it doesn't have hooks for decimal floating-point 
types or fixed-point types, but that's certainly not a problem.  For 
decimal floating-point types there are no non-default definitions of the 
macros and they are used only in one place so that conversion will be 
pretty trivial.)

I'm not convinced it makes sense to be partial in this way for 
BOOL_TYPE_SIZE (a single non-default definition) and ADA_LONG_TYPE_SIZE 
(two non-default definitions) rather than just doing the complete 
conversions for those macros and poisoning them.

> Regarding WCHAR_TYPE_SIZE, it appears this is used to define a constant
> in ttypes.ads.  We can use GET_IDENTIFIER to find the type from WCHAR_TYPE
> only after all the C types have been initialized, so I don't think that
> would be safe in this context.  So i made this into a separate hook, too.

I already said this should not be a hook.  The Fortran front end already 
has support for decoding strings in the form that appear in macros such as 
WCHAR_TYPE: get_typenode_from_name.  You could easily make that return an 
integer_type_kind instead and move it out of the Fortran front end.

> A possible alternative would be to change WCHAR_TYPE to have an
> integer_type_kind value, but that would be quite a big change in itself;

I think that should be separate, a preliminary step before converting all 
the *_TYPE macros to hooks.  First they should be changed to have 
integer_type_kind values, then they should be changed to hooks taking 
suitable enum values and returning suitable enum values.  Maybe one hook 
for size_t and ptrdiff_t, one for wchar_t and wint_t, one for sig_atomic_t 
and one for the stdint.h types.

> +int
> +legacy_integer_type_size (enum integer_type_kind kind)
> +{
> +  switch (kind)
> +    {
> +    case itk_char: case itk_signed_char: case itk_unsigned_char:
> +      return CHAR_TYPE_SIZE;
> +    case itk_short: case itk_unsigned_short:
> +      return SHORT_TYPE_SIZE;
> +    case itk_int: case itk_unsigned_int:
> +      return INT_TYPE_SIZE;
> +    case itk_long: case itk_unsigned_long:
> +      return LONG_TYPE_SIZE;
> +    case itk_long_long: case itk_unsigned_long_long:
> +      return LONG_LONG_TYPE_SIZE;
> +    case itk_int128: case itk_unsigned_int128:
> +      return 128;

I think we should define the hook interface so that only one argument is 
valid for each present macro.  Thus there should be no possibility for 
targets to give char and signed char different sizes, for example, because 
only itk_char should ever be passed for all the character types.

-- 
Joseph S. Myers
joseph@codesourcery.com