From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8387 invoked by alias); 6 Jul 2004 14:56:48 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 8377 invoked from network); 6 Jul 2004 14:56:46 -0000 Received: from unknown (HELO lon-mail-2.gradwell.net) (193.111.201.126) by sourceware.org with SMTP; 6 Jul 2004 14:56:46 -0000 Received: (qmail 24025 invoked from network); 6 Jul 2004 14:56:23 -0000 Received: from digraph.polyomino.org.uk (postmaster%pop3.polyomino.org.uk@81.187.227.50) by lon-mail-2.gradwell.net with SMTP; 6 Jul 2004 14:56:23 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.34) id 1BhrMr-0003O1-Ts; Tue, 06 Jul 2004 14:56:21 +0000 Date: Tue, 06 Jul 2004 15:07:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Jan Beulich cc: gcc-patches@gcc.gnu.org Subject: Re: enable maximum integer type to be 128 bits In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-07/txt/msg00472.txt.bz2 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 , 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 . __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)