<div class="gmail_quote">On Tue, May 22, 2012 at 10:29 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Tue, May 22, 2012 at 9:28 PM, Gabe Rives-Corbett<br>
<<a href="mailto:gabe@gaberivescorbett.com">gabe@gaberivescorbett.com</a>> wrote:<br>
> Hello,<br>
><br>
> I built Clang and LLVM 3.1 on OS X using the following configure command:<br>
><br>
> configure --with-gcc-toolchain=/opt/local/ --prefix=/opt/clang-3.1/<br>
> --enable-targets=x86_64,x86 --enable-optimized<br>
><br>
> the reason for the gcc-tolchain location is to use the macports gcc 4.6<br>
> libstdc++ in order to support more of C++11.  I also made the following<br>
> changes to InitHeaderSearch::AddDefaultCIncludePaths:<br>
><br>
> void InitHeaderSearch::AddDefaultCIncludePaths(const llvm::Triple &triple,<br>
>                                             const HeaderSearchOptions<br>
> &HSOpts) {<br>
>   llvm::Triple::OSType os = triple.getOS();<br>
><br>
>   if (HSOpts.UseStandardSystemIncludes) {<br>
>     switch (os) {<br>
>     case llvm::Triple::FreeBSD:<br>
>     case llvm::Triple::NetBSD:<br>
>       break;<br>
>     default:<br>
>       // FIXME: temporary hack: hard-coded paths.<br>
>       //AddPath("/usr/local/include", System, true, false, false);<br>
><br>
>       AddPath("/opt/local/include/gcc46/c++", System, true, false, false);<br>
>  AddPath("/opt/local/include/gcc46/c++/x86_64-apple-darwin11/.", System,<br>
> true, false, false);<br>
>       AddPath("/opt/local/include/gcc46/c++/backward/", System, true, false,<br>
> false);<br>
><br>
> AddPath("/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/include",<br>
> System, true, false, false);<br>
>       AddPath("/usr/local/include", System, true, false, false);<br>
><br>
> AddPath("/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/include-fixed",<br>
> System, true, false, false);<br>
>       AddPath("/usr/include", System, true, false, false);<br>
><br>
>       break;<br>
>     }<br>
>   }<br>
><br>
><br>
> Then when building a C source file I get the following error:<br>
><br>
> In file included from<br>
> /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20:<br>
> In file included from<br>
> /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21:<br>
> In file included from<br>
> /System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20:<br>
> In file included from<br>
> /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:129:<br>
> In file included from<br>
> /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32:<br>
> In file included from<br>
> /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:29:<br>
> /opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/include/xmmintrin.h:102:10:<br>
> error: invalid conversion between vector type '__m128' and integer type<br>
> 'int' of different size<br>
><br>
> Any ideas?<br>
<br>
</div></div>Adding "/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/include/"<br>
to your include paths is a bad idea.</blockquote><div><br></div><div>To expand on this a bit:</div><div><br></div><div>By adding this header search path, you are telling Clang to look into GCC's *internal* headers. These headers are written directly against the implementation details of GCC at the precise version they ship with GCC. Clang won't be able to parse these because it's implementation details are significantly different. Because of this Clang ships with its own internal headers, including 'xmmintrin.h', which are implemented using *Clang's* implementation details.</div>
<div><br></div><div>These headers are in a different fundamental group from the "system" headers, these are "builtin" headers. That is, they are considered to be built into the compiler itself, and not a separable entity. As such, they cannot be shared between GCC and Clang, unlike the system headers of libstdc++ or Linux in general.</div>
</div>