On Thu, Nov 29, 2012 at 5:30 PM, Stephen Canon <[email protected]> wrote:
> On Nov 29, 2012, at 8:23 PM, Chris Lattner <[email protected]> wrote: > > > On Nov 29, 2012, at 4:23 PM, Stephen Canon <[email protected]> wrote: > > > >> On Nov 29, 2012, at 7:16 PM, Richard Smith <[email protected]> > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
