[cfe-dev] Clang for windows

[Richard Smith]

On Thu, Aug 21, 2014 at 2:38 PM, Smith, Kevin B <kevin.b.smith at intel.com>
wrote:

> I was playing around with CLANG for windows (clang-cl.exe) and noticed
> that this doesn't support
> _int64, but that it does support __int64.  For Microsoft compiler both
> __int64 and _int64 are recognized
> as a keyword and basic type.  This simple program demonstrates that
>
> $ cat xxy.cpp
> typedef unsigned __int64 bb1;
>
> typedef unsigned _int64 bb2;
>
> when preprocessed with the VS 2012 C++ compiler, using cl -E xxy.cpp, this
> yields:
> $ cl -E xxy.cpp
> Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> xxy.cpp
> #line 1 "xxy.cpp"
> typedef unsigned __int64 bb1;
>
> typedef unsigned _int64 bb2;
>
> showing that the Microsoft compiler hasn't simply created a #define _int64
> __int64 instead of treating _int64 as a keyword.
> So, I expect clang-cl should do the same thing.  The following simple
> patch for CLANG is probably the correct way
> to remedy this, and it seemed to work for me.  FWIW, I found this in the
> SPEC 2000 INT program 186.crafty, which uses the
> _int64 type directly.
>
> $ svn diff
> Index: include/clang/Basic/TokenKinds.def
> ===================================================================
> --- include/clang/Basic/TokenKinds.def  (revision 216129)
> +++ include/clang/Basic/TokenKinds.def  (working copy)
> @@ -558,6 +558,7 @@
>  ALIAS("_uuidof"          , __uuidof   , KEYMS | KEYBORLAND)
>  ALIAS("_inline"          , inline     , KEYMS)
>  ALIAS("_declspec"        , __declspec , KEYMS)
> +ALIAS("_int64"           , __int64    , KEYMS)
>
>  // Borland Extensions which should be disabled in strict conformance mode.
>  ALIAS("_pascal"      , __pascal   , KEYBORLAND)


This patch looks like the right approach to me. Are there other keywords
that need this treatment? This change will also need a testcase before we
can accept it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140821/2802d97a/attachment.html>