This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: enable maximum integer type to be 128 bits
- From: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 6 Jul 2004 14:56:21 +0000 (UTC)
- Subject: Re: enable maximum integer type to be 128 bits
- References: <s0eac520.068@emea1-mh.id2.novell.com>
On Tue, 6 Jul 2004, Jan Beulich wrote:
> This enables forcing the internally used maximum integer types to 128
> bits rather than the previous limit of the equivalent of 'long long'.
Configure options need documenting in install.texi. In this case, it
would need documentation warning that this option is ABI-incompatible with
the de facto standard ABIs used by library functions such as printf, which
treat intmax_t as long long. (Which is why it looks like it would make
more sense simply for some new targets to use this by default, rather than
having a configure option, but I presume there's some reason to want
intmax_t different from the usual type on existing targets.)
(When I say ABI-incompatible, of course the option does not by itself
change the user intmax_t type, as GCC doesn't yet provide <stdint.h>, but
as it changes GCC's understanding of the type of the built-in function
imaxabs if nothing else, and of the types expected by printf %jd and %ju,
it makes no sense without corresponding library changes to use such a
bigger intmax_t, and such a library would have a different ABI from the
previous one.)
(By way of clarification, the existing __int128_t is not, on platforms
where intmax_t is narrower, an extended integer type within the meaning of
C99, and as such may not be used to define any standard C or POSIX type in
a standard header; rather it is some random undocumented extension with
only a vague similarity to integer types. Remember also that in C90 mode
long long can't be used to define standard C types either, nor POSIX (up
to 1996) types, if those types are meant to be integer or arithmetic
types.)
Please also update the documentation of the restrictions on the value of
SIZE_TYPE and related macros in tm.texi, as it seems this patch presumes
certain names such as __int128_t are valid in those definitions, which
isn't currently part of the documentated back-end interface.
Instead of the testsuite changes and defining _INTEGRAL_MAX_BITS, please
add predefines of __INTMAX_TYPE__ and __UINTMAX_TYPE__ (like those of
__SIZE_TYPE__ etc.), and __INTMAX_MAX__ (like those of __LONG_LONG_MAX__
etc.). We'll need those defines eventually anyway to implement
<stdint.h>. __INTMAX_MAX__ should have type intmax_t and be usable in
preprocessor conditionals, so some care may be needed to get the correct
suffix for the case where it is one of long and long long, both of which
have the same precision. The testsuite can then be simplified with the
use of the __INTMAX_TYPE__ and __INTMAX_MAX__ definitions.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)