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

[Francois Pichet]

On Mon, Oct 10, 2011 at 4:19 PM, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Oct 10, 2011, at 1:14 PM, Francois Pichet wrote:
>
>> 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.
>
> 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.