On Mon, Oct 10, 2011 at 4:19 PM, Douglas Gregor <[email protected]> wrote:
>
> 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.
>

ok then i'll revert.

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to