RFA: Change stdint.h _TYPE macros to have an enum integer_type_kind value

RFA: Change stdint.h _TYPE macros to have an enum integer_type_kind value

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

This patch is a preparation for hookizing these macros and to eliminate the
macros that confer the sizes of these types.

There is one potentially behaviour-changing change to  
config/i386/djgpp-stdint.h,
where I have replaced invalid types names like "signed int" ( that would
  cause a crash when evaluating
  int_fast32_type_node =
    TREE_TYPE (identifier_global_value (c_get_ident (INT_FAST32_TYPE)));
  in c-family/c-common.c:c_common_nodes_and_builtins)
by the integer_type_kind value of the corresponding valid type name.
But AFAICT, contrary to what ChangeLog-2009 says, config/i386/djgpp-stdint.h
is not currently used anywhere - it would have to be included in ${tm_file}
for djgpp.


To avoid further problems downstream, may also use any new documentation added
in this patch under the GNU Public license, version 3 or later.

Bootstrapped & regression tested on x86_64-pc-linux-gnu.

Cross-tested on x86_64-pc-linux-gnu (--enable-languges=all,ada,go) for:
alpha-linux-gnu hppa-linux-gnu mips-elf sh-elf arc-elf ia64-elf  
mmix-knuth-mmixware sparc-elf arm-eabi iq2000-elf mn10300-elf spu-elf  
avr-elf lm32-elf moxie-elf v850-elf bfin-elf m32c-elf pdp11-aout  
vax-linux-gnu cris-elf m32r-elf picochip-elf xstormy16-elf crx-elf  
m68hc11-elf ppc-elf xtensa-elf fr30-elf m68k-elf rx-elf frv-elf  
mcore-elf s390-linux-gnu h8300-elf mep-elf score-elf

microblaze is currently affected by PR 46738 .

[-- Attachment #2: pr46677-itk-macro-patch-1211.bz2 --]
[-- Type: application/x-bzip, Size: 17982 bytes --]

Re: RFA: Change stdint.h _TYPE macros to have an enum integer_type_kind value

[DJ Delorie]

DJGPP's own stdint.h uses the same types.  What's wrong with "signed
int" ?

Re: RFA: Change stdint.h _TYPE macros to have an enum integer_type_kind value

[Joern Rennecke]

Quoting DJ Delorie <dj@redhat.com>:

>
> DJGPP's own stdint.h uses the same types.  What's wrong with "signed
> int" ?

GCC internally has only one name for each C type.  The current *_TYPE
macros must match one of these.  This is explained in tm.texi, albeit a
bit obscure - i.e. init_decl_processing calls build_common_tree_nodes
to create the types, and then it calls
c-family/c-common.c:c_common_nodes_and_builtins to give them their names.

This also demonstrates another reason why it is better to have enum values
for these types: it is immediately apparent what the allowed values are.

Re: RFA: Change stdint.h _TYPE macros to have an enum integer_type_kind value

[DJ Delorie]

Ah, OK, so it's just a syntax-ish change and not a semantic change?

Re: RFA: Change stdint.h _TYPE macros to have an enum integer_type_kind value

[Joern Rennecke]

Quoting DJ Delorie <dj@redhat.com>:

>
> Ah, OK, so it's just a syntax-ish change and not a semantic change?

Yes, except that in djgpp-stdint.h, I translated "signed int" into itk_int;
a semantically equivalent translation would have been
(enum integer_type_kind) 0xdeadbeef, i.e. continue to cause a crash if used.
Likewise for the other explicitly signed types (except signed char) of
djgpp-stdint.h.

Re: RFA: Change stdint.h _TYPE macros to have an enum integer_type_kind value

[DJ Delorie]

I meant semantically equivalent to what we wanted, not to what we got :-)

Re: RFA: Change stdint.h _TYPE macros to have an enum integer_type_kind value

[Joseph S. Myers]

On Sun, 12 Dec 2010, Joern Rennecke wrote:

> +If any of these macros evaluates to itk_none, the corresponding

That should be @code{itk_none}.

The C front-end and documentation changes are OK with that fix.  Obviously 
the back-end changes, which I have not reviewed, will need updating for 
whichever of my svr4.h avoidance patches, involving the affected macros, 
have gone in since the patch was prepared.

-- 
Joseph S. Myers
joseph@codesourcery.com