From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-167413-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12698 invoked by alias); 6 Mar 2011 14:52:42 -0000
Received: (qmail 12685 invoked by uid 22791); 6 Mar 2011 14:52:41 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,TW_CL,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from sunsite.ms.mff.cuni.cz (HELO sunsite.mff.cuni.cz) (195.113.15.26)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 06 Mar 2011 14:52:35 +0000
Received: from sunsite.mff.cuni.cz (localhost [127.0.0.1])	by sunsite.mff.cuni.cz (8.14.4/8.14.4) with ESMTP id p26EqWMO025439;	Sun, 6 Mar 2011 15:52:32 +0100
Received: (from jj@localhost)	by sunsite.mff.cuni.cz (8.14.4/8.14.4/Submit) id p26EqWH5025438;	Sun, 6 Mar 2011 15:52:32 +0100
Date: Sun, 06 Mar 2011 14:52:00 -0000
From: Jakub Jelinek <jakub@redhat.com>
To: gcc@gcc.gnu.org
Cc: FX <fxcoudert@gmail.com>
Subject: Re: __builtin_clzll and uintmax_t
Message-ID: <20110306145231.GL13037@sunsite.ms.mff.cuni.cz>
Reply-To: Jakub Jelinek <jakub@redhat.com>
References: <AC5CE0DC-41F9-4DD2-86C4-91C92C5FE222@gmail.com> <alpine.DEB.2.02.1103060940020.2498@laptop-mg.saclay.inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1103060940020.2498@laptop-mg.saclay.inria.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2011-03/txt/msg00071.txt.bz2

On Sun, Mar 06, 2011 at 09:56:52AM +0100, Marc Glisse wrote:
> >uintmax_t is the largest of the standard unsigned C types, so it cannot be larger than unsigned long long.
> 
> That's a gcc property then. The C99 standard only guarantees that
> uintmax_t is at least as large as unsigned long long, but it is
> allowed to be some other larger type:

Yeah, it could be larger than unsigned long long.
On no target GCC supports currently it is larger than long long though currently.
Just
grep INTMAX_TYPE gcc/{,config/,config/*/}*.h
to see it.

> >On x86_64, for example:
> >
> >>#include <stdio.h>
> >>#include <stdint.h>
> >>
> >>int main (void)
> >>{
> >>  printf ("%lu ", sizeof (uintmax_t));
> >>  printf ("%lu ", sizeof (int));
> >>  printf ("%lu ", sizeof (long int));
> >>  printf ("%lu ", sizeof (long long int));
> >>  printf ("%lu\n", sizeof (__int128));
> >>}
> >
> >gives : 8 4 8 8 16
> 
> I am not sure how legal that is. __int128 is an extended signed
> integer type, and thus the statement about intmax_t should apply to
> it as well. So gcc is just pretending that __int128 is not really
> there.

It is also an ABI issue, you can't change what uintmax_t was
once you use some particular type in an ABI.

What you could do is use __builtin_clzll if sizeof (uintmax_t) == sizeof (unsigned long long),
for sizeof (uintmax_t) == 2 * sizeof (unsigned long long) perhaps use

int
clzmax (uintmax_t x)
{
  const union
    {
      uintmax_t ll;
#if __BYTE_ORDER__ != __ORDER_LITTLE_ENDIAN__
      struct { unsigned long long high, low; } s;
#else
      struct { unsigned long long low, high; } s;
#endif
    } uu = { .ll = x };
  uintmax_t word;
  unsigned long long add;

  if (uu.s.high)
    word = uu.s.high, add = 0;
  else
    word = uu.s.low, add = sizeof (unsigned long long) * __CHAR_BIT__;

  return __builtin_clzll (word) + add;
}

and give up for other cases.

	Jakub