128-bit integers and intmax_t

128-bit integers and intmax_t

[Joseph S. Myers]

When HOST_BITS_PER_WIDE_INT >= 64, gcc has some support for 128-bit
integer types (`int __attribute__((__mode__(__TI__)))' and `unsigned int
__attribute__((__mode__(__TI__)))').  Should these count as "extended
integer types" (within the meaning of C99 6.2.5p7)?

If they so count, then intmax_t and uintmax_t would need to be defined
accordingly - which would break existing ABIs (e.g. glibc), and the
dependence on HOST_BITS_PER_WIDE_INT would be rather undesirable.  The
pragmatic solution seems to be to define that these types are not extended
integer types, regardless of the level of support GCC has for them and how
much they look like extended integer types, and to add appropriate
-pedantic warnings, but does anyone see any better solution?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: 128-bit integers and intmax_t

[Geoff Keating]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> When HOST_BITS_PER_WIDE_INT >= 64, gcc has some support for 128-bit
> integer types (`int __attribute__((__mode__(__TI__)))' and `unsigned int
> __attribute__((__mode__(__TI__)))').  Should these count as "extended
> integer types" (within the meaning of C99 6.2.5p7)?
> 
> If they so count, then intmax_t and uintmax_t would need to be defined
> accordingly - which would break existing ABIs (e.g. glibc), and the
> dependence on HOST_BITS_PER_WIDE_INT would be rather undesirable.  The
> pragmatic solution seems to be to define that these types are not extended
> integer types, regardless of the level of support GCC has for them and how
> much they look like extended integer types, and to add appropriate
> -pedantic warnings, but does anyone see any better solution?

This is a libc issue.  They are extended integer types if and only if
the libc defines intmax_t (or some other standard type) as them.
Otherwise, there's no way for a strictly conforming C program to know
they exist.

-- 
- Geoffrey Keating <geoffk@cygnus.com>