From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20279 invoked by alias); 21 Mar 2004 18:15:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 20264 invoked from network); 21 Mar 2004 18:15:32 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.6) by sources.redhat.com with SMTP; 21 Mar 2004 18:15:32 -0000 Received: (qmail 14059 invoked from network); 21 Mar 2004 18:15:31 -0000 Received: from taltos.codesourcery.com (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 21 Mar 2004 18:15:31 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Sun, 21 Mar 2004 10:15:31 -0800 To: Scott Robert Ladd Cc: gcc@gcc.gnu.org Subject: Re: 128-bit long long? References: <405DB46B.80208@coyotegulch.com> From: Zack Weinberg Date: Sun, 21 Mar 2004 20:52:00 -0000 In-Reply-To: <405DB46B.80208@coyotegulch.com> (Scott Robert Ladd's message of "Sun, 21 Mar 2004 10:27:39 -0500") Message-ID: <8765cykqws.fsf@egil.codesourcery.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-03/txt/msg01261.txt.bz2 Scott Robert Ladd writes: > On a 64-bit AMD64 architecture, GCC defines long long as 64 bits, the > same as a long. > > Given that certain 64-bit instructions (multiply) produce 128-bit > results, doesn't it seem logical the long long be defined as 128 bits? No, for two reasons: 1) The choice of 64-bit 'long long' has been written into the ABI of most LP64-model operating systems; we can't unilaterally change it. 2) This is actually the correct choice, as it removes the aberration that makes 'long' not the widest basic integral type. There is lots and lots of code in the wild written to the assumption that sizeof(long) >= sizeof(size_t) - this is at least potentially broken by ABIs where long long is wider than long. (This was an extremely contentious topic during the development of C99. As best as I can tell from an outside perspective, 'long long' was only standardized due to pressure from Microsoft who can't for some reason implement an LP64 model. Everyone else hated the idea of making 'long' not necessarily the widest basic integral type.) Best current practice appears to be to provide an "extended integral type" __int128. This doesn't have the problems of 'long long' because it's not a *basic* integral type (in particular, it cannot be used for size_t). zw