[cfe-commits] [PATCH] Improved handling of 128-bit integer literals

[Richard Smith]

On Thu, Nov 29, 2012 at 5:30 PM, Stephen Canon <scanon at apple.com> wrote:

> On Nov 29, 2012, at 8:23 PM, Chris Lattner <clattner at apple.com> wrote:
>
> > On Nov 29, 2012, at 4:23 PM, Stephen Canon <scanon at apple.com> wrote:
> >
> >> On Nov 29, 2012, at 7:16 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> >>
> >>> Generally, we still need to handle Eli's observation that the C and
> C++ extended integer type rules require us to make intmax_t be __int128 if
> we're going to allow literals to be of type __int128. I'm inclined to say
> we should bite the bullet here, and treat __int128 as a proper extended
> integer type (and thus change intmax_t, preprocessor constant expressions,
> and so on). Any objections?
> >>
> >> In the long run, I would very much like for intmax_t to be 128-bits
> where we can do so, but it's a *major* undertaking.  In particular, it
> requires considerable platform library support; off the top of my head:
> >>
> >> • libc needs to be able to printf/scanf intmax_t via SCN*MAX / PRI*MAX,
> and needs to support strtoimax, etc.
> >> • libc needs to support imaxdiv and imaxabs.
> >>
> >> This will cause a decent amount of binary-compatibility headaches.
>  It's a goal worth aiming for, but it's a good ways off still.
> >
> > I agree, it's a great goal, but it will be a massive undertaking.
>
> In the meantime, if we're really worried about conformance, here perhaps
> -std=c99,c11,c++11, etc should disable __[u]int128_t?  (Though this would
> likely cause a hassle for some users).
>

We need __int128 to support recent versions of libstdc++.

It seems to me that the best approach is to keep the status quo, that
__int128 is *not* an extended integer type (per the rules of the various
language standards). The proposed change to support __int128 literals is
still a conforming extension.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121129/ce23dc5e/attachment.html>