[cfe-commits] r140009 - lib/Frontend/CompilerInvocation.cpp

Francois Pichet pichet2000 at gmail.com
Mon Oct 10 13:14:27 PDT 2011

On Fri, Oct 7, 2011 at 3:20 PM, Douglas Gregor <dgregor at apple.com> wrote:
> On Oct 5, 2011, at 2:52 PM, Francois Pichet wrote:
>> On Wed, Oct 5, 2011 at 1:58 PM, Bob Wilson <bob.wilson at apple.com> wrote:
>>> Francois,
>>> I just noticed this change:
>>> r140009 | fpichet | 2011-09-18 22:15:54 -0700 (Sun, 18 Sep 2011) | 1 line
>>> Do not use builtin includes if -fms-compatibility is specified. Some MSVC header files have the same name as clang's builtins, this creates clash.
>>> Are you sure this is the right thing to do?  If none of the clang-specific header files are available, that means that things like the AVX/SSE intrinsics will not be available.  What about clang's version of tgmath.h?  Etc.  What MSVC header files caused a clash and what was the problem with that clash?
>> The problem is:
>> using clang compiled with MSVC 2010
>> given test.cpp:
>> #include <vector>
>> C:\dev\llvm\test>clang test5.cpp
>> In file included from test5.cpp:1:
>> In file included from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc
>> lude\vector:6:
>> In file included from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc
>> lude\memory:987:
>> In file included from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\inc
>> lude\intrin.h:26:
>> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\ammintrin.h:222:1
>> : error:
>>      unknown type name '__m256'
>> __m256 _mm256_macc_ps(__m256, __m256, __m256);
>> ^
>> a flooding of errors
>> That is because ammintrin.h includes some headers existing on MSVC and
>> clang include's builtins directory. When compiling MSVC headers you
>> really want clang to pick the MSVC headers otherwise it won't work.
> We typically want to use Clang's definitions because we can make sure that work well with Clang. If it's just additional definitions you're missing, they could either be added to Clang or you could use the #include_next mechanism.

I don't understand why you would want to use clang definition instead
of the MSVC one when -fms-compatibility is on. They are not necessary
equivalent. My idea of -fms-compatibility is for clang.exe to see
exactly the same stream of tokens as cl.exe would see when compiling
MSVC code on Windows.

More information about the cfe-commits mailing list