On Thu, Nov 29, 2012 at 5:30 PM, Stephen Canon <span dir="ltr"><<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Nov 29, 2012, at 8:23 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
<br>
> On Nov 29, 2012, at 4:23 PM, Stephen Canon <<a href="mailto:scanon@apple.com">scanon@apple.com</a>> wrote:<br>
><br>
>> On Nov 29, 2012, at 7:16 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>><br>
>>> 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?<br>

>><br>
>> 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:<br>

>><br>
>> • libc needs to be able to printf/scanf intmax_t via SCN*MAX / PRI*MAX, and needs to support strtoimax, etc.<br>
>> • libc needs to support imaxdiv and imaxabs.<br>
>><br>
>> 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.<br>
><br>
> I agree, it's a great goal, but it will be a massive undertaking.<br>
<br>
</div></div>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).<br></blockquote></div>
<br><div>We need __int128 to support recent versions of libstdc++.</div><div><br></div><div>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.</div>