On Oct 10, 2011, at 1:14 PM, Francois Pichet wrote:
> On Fri, Oct 7, 2011 at 3:20 PM, Douglas Gregor <[email protected]> wrote:
>>
>> On Oct 5, 2011, at 2:52 PM, Francois Pichet wrote:
>>
>>> On Wed, Oct 5, 2011 at 1:58 PM, Bob Wilson <[email protected]> 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.
I'm not convinced that's a reasonable goal. System headers like this one often
resort to compiler-specific hackery (e.g., see our, and everyone else's,
<tgmath.h>), and are often best implemented as part of the compiler itself so
that they map down to the appropriate compiler intrinsics.
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
