[cfe-dev] MS 128-bit literals don't always have the correct type

[Stephen Canon]

Following up...

What seems to be the "MS extension" is the UiN and iN style suffixes for N-bit integers (which is nice, as making up progressively longer suffixes "ULLL..." is clearly untenable in the long term).  Unless someone can suggest a better name for __uint128_t and __int128_t literals, it seems like as good an option as any.

Looking at the GCC docs, it seems that the only support for 128b literals in GCC is if you happen to be on a platform where "long long" is 128b.

- Steve

On Sep 23, 2012, at 4:12 PM, Stephen Canon <scanon at apple.com> wrote:

> When I did the work to add support for literals wider than 64b, I simply took the existing implementation in Sema indicating that they were a MS extension at face value (I don't myself have an MS system available to test on).  Regardless of whether or not MS supports them, it would be quite nice if we can continue to support them (and improve on the current state) -- I have a few personal projects that depend on them, which is why I originally implemented this.
> 
> Perhaps support shouldn't be toggled via -fms-extensions, if VC++ doesn't actually support them?
> 
> The issue with "short 128b literals" not having the correct type is something that I noticed a couple weeks ago and have been meaning to take a look at, as it is causing bugs for me.
> 
> - Steve
> 
> On Sep 23, 2012, at 3:51 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 
>> Hi Stephen,
>> 
>> Could you please comment on this thread?  I'm asking you since you
>> implemented part of semantic analysis for this extension.
>> 
>> Dmitri
>> 
>> ---------- Forwarded message ----------
>> From: João Matos <ripzonetriton at gmail.com>
>> Date: Sun, Sep 23, 2012 at 10:48 PM
>> Subject: Re: [cfe-dev] MS 128-bit literals don't always have the correct type
>> To: Dmitri Gribenko <gribozavr at gmail.com>
>> Cc: Aaron Ballman <aaron at aaronballman.com>, Clang Developers
>> <cfe-dev at cs.uiuc.edu>
>> 
>> 
>> I've never heard of this extension before. I tried to compile a simple example:
>> 
>> int main()
>> {
>> auto i = 1i128;
>> return 0;
>> }
>> 
>> 
>>> cl -nologo test.cpp
>> test.cpp
>> test.cpp(3) : error C2059: syntax error : 'bad suffix on number'
>> test.cpp(3) : error C2146: syntax error : missing ';' before identifier 'i128'
>> test.cpp(3) : error C2065: 'i128' : undeclared identifier
>> 
>> I also couldn't find any mention of these literals in MSDN.
>> 
>> On Sun, Sep 23, 2012 at 8:18 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>> 
>>> On Sun, Sep 23, 2012 at 10:15 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>>>> On Sun, Sep 23, 2012 at 2:27 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>>>> On Sun, Sep 23, 2012 at 9:24 PM, Cory Nelson <phrosty at gmail.com> wrote:
>>>>>> On Sun, Sep 23, 2012 at 11:20 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>>>>>> Hello,
>>>>>>> 
>>>>>>> Currently Clang chooses the type of MS 128-bit literals (<digits>i128,
>>>>>>> <digits>ui128) based on their value, as if there was no suffix, but
>>>>>>> also allows an extended 128-bit type.
>>>>>>> 
>>>>>>> For example, on x86_64:
>>>>>>> 
>>>>>>> 1i128 is equivalent to 1,
>>>>>>> 0x100000000i128 is same as 0x100000000L,
>>>>>>> and finally 0x10000000000000000i128 is indeed a 128-bit literal.
>>>>>>> 
>>>>>>> I don't know if it is intended, but i128 is definitely treated
>>>>>>> differently way from other MS literal suffixes we accept (for example,
>>>>>>> i64 is essentially an alias for LL).
>>>>>>> 
>>>>>>> I don't have Visual Studio so I can not check how it handles these literals.
>>>>>> 
>>>>>> VC++ does not support 128-bit literals.
>>>>> 
>>>>> I'm confused.  So why does Clang implement them?
>>>> 
>>>> There's an __int128 supplied by gcc
>>>> (http://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html), but there's
>>>> not one for Visual Studio (at least not one officially documented).
>>> 
>>> That is a 128-bit integer type.  I was asking about 128-bit literals,
>>> like 1i128 (which gcc does not support).
>>> 
>>> Dmitri
>>> 
>>> --
>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> 
>> 
>> 
>> --
>> João Matos
>> 
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120923/32445d85/attachment.html>