Yes, upon further inspection, aforementioned patch explicitly adds the directories in MinGW::AddClangCXXStdlibIncludeArgs()
which is distinctly different than mingw-builds.
With MSYS2 C++ include directories is kept in /mingw64/include/c++/${gccver} whereas with mingw-builds /mingw64/x86_64-w64-mingw32/include/c++
is where they are.
Old patch is removed from the MSYS2 packages and a new one is introduced after this update but unfortunately it does not handle
the changes. ( I’ve added the maintainer of clang at MSYS2 in this conversation).
MSYS2 is damn great and convenient to use. I’d very much like to see recent version of clang is usable without problems again.
The attached patch should fix that, please let me know if it works for you.
mingw.diff (2.49 KB)
You only need to have the bin directory in your PATH. clang will find
the include and library directory based on the bin directory. There are
no fixed paths, you can put in c:\mingw or wherever.
I ran into a problem using mingw-64 and the latest clang. In the mingw-64 intrin.h for gcc-4.9 on up it uses the gcc version number to decide whether to define the macro __MINGW_FORCE_SYS_INTRINS. If this macro is not defined it leads to multiple declarations for __m64 and some other CPU feature typdefs. Its gcc implementation defines __MINGW_FORCE_SYS_INTRINS for gcc-4.9 on up but clang still sets the gcc version number to gcc-4.2.1 so that __MINGW_FORCE_SYS_INTRINS is not automatically defined.
My workaround for this was to define __MINGW_FORCE_SYS_INTRINS when using clang. This appears to work fine in my tests for clang but then I found a link of yours at http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20141110/118349.html which appears to claim that defining __MINGW_FORCE_SYS_INTRINS forces the use of invalid CPU instructions when compiling with clang but evidently not when compiling with gcc.
Does merely specifying all the x86-x64 compiler intrinsics, as the intrin.h in gcc-4.9 and up does, cause CPU instruction set problems when compiling with clang ? If so this means that I cannot use clang with gcc-4.9 and up unless I locally change their headers to avoid the problem. I have alerted mingw-64 about the general issue.
clang uses its own *intrin.h files, found in …\lib\clang\3.7.0\include\ relative to the bin, which appears before the gcc include directories. If you run clang++ -v somefile.cpp you’ll see which directory clang looks for, it should look something like:
#include <…> search starts here:
C:\mingw32\i686-w64-mingw32\include\c++
C:\mingw32\i686-w64-mingw32\include\c++\i686-w64-mingw32
C:\mingw32\i686-w64-mingw32\include\c++\backward
C:\llvm\msvc\RelWithDebInfo\bin..\lib\clang\3.7.0\include
C:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include
C:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include-fixed
C:\mingw32\i686-w64-mingw32\include
C:\mingw32\include
clang uses its own *intrin.h files, found in ..\lib\clang\3.7.0\include\
relative to the bin, which appears before the gcc include directories.
If you run clang++ -v somefile.cpp you'll see which directory clang
looks for, it should look something like:
#include <...> search starts here:
C:\mingw32\i686-w64-mingw32\include\c++
C:\mingw32\i686-w64-mingw32\include\c++\i686-w64-mingw32
C:\mingw32\i686-w64-mingw32\include\c++\backward
* C:\llvm\msvc\RelWithDebInfo\bin\..\lib\clang\3.7.0\include*
C:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include
C:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include-fixed
C:\mingw32\i686-w64-mingw32\include
C:\mingw32\include
Look at line 26 of clang's intrin.h. Clang is actually including the mingw/gcc intrin.h instead of using its own as long as its the gcc version and not the Windows VC++ version.
Thanks, it seems to be working. I’ve noticed something else alltogether when testing that pthreads are not linked
by default.There is a FIXME in Tools.cpp and the code is commented out. I don’t think there is anyone using gcc
without c++11 std::thread support. I think it should be enabled by default.
Yes, I commented it out due to mingw.org not having libpthread.
Anyhow, the other drivers in Tools.cpp usually add pthread conditionally:
if (Args.hasArg(options::OPT_pthread))
CmdArgs.push_back(“-lpthread”);
would it make sense to do the same for mingw?
clang uses its own *intrin.h files, found in ..\lib\clang\3.7.0\include\
relative to the bin, which appears before the gcc include directories.
If you run clang++ -v somefile.cpp you'll see which directory clang
looks for, it should look something like:
#include <...> search starts here:
C:\mingw32\i686-w64-mingw32\include\c++
C:\mingw32\i686-w64-mingw32\include\c++\i686-w64-mingw32
C:\mingw32\i686-w64-mingw32\include\c++\backward
* C:\llvm\msvc\RelWithDebInfo\bin\..\lib\clang\3.7.0\include*
C:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include
C:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include-fixed
C:\mingw32\i686-w64-mingw32\include
C:\mingw32\include
Look at line 26 of clang's intrin.h. Clang is actually including the mingw/gcc intrin.h instead of using its own as long as its the gcc version and not the Windows VC++ version. As mentioned for gcc-4.9 and up the mingw/gcc intrin.h file brings in all x86 CPU features. This does not negatively affect a gcc compile. I am going to assume that it will not negatively affect a clang compile.
I did not understand your comment in the link I found at http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20141110/118349.html. I am assuming that it does not mean that clang will output invalid CPU instructions just because the mingw/gcc intrin.h file includes all CPU intrinsic features. I also did not understand from your discussion in the link why clang continues to tag itself as version 4.2.1 of gcc but that is another matter entirely and has to do no doubt with clang internals and matters I don't even pretend to understand. I just want to verify that the use of mingw/gcc for gcc version 4.9 and up will not cause problems when I define __MINGW_FORCE_SYS_INTRINS to avoid compilation errors from the mingw/gcc intrin.h header file.
I’d even prefer a negatory option something in the vein of no-pthreads
but I think -pthreads would do for now.
Hurcan: added -pthread in r241485. Note that’s -pthread not -pthreads. The -pthreads option is hardly used in Tools.cpp, maybe it’s depreciated.
Hey guys,
Thanks for CC’ing me on this.
I do remember a previous discussion on this issue with gcc where there are 3 possible combinations for locations of c++ includes.
Hurcan I don’t maintain the gcc packages for msys2 alexey does.
He is currently looking at rebuilding to gcc 5.1
If you create an issue there he might be able to change the paths of the package to match mingw-builds.
If not I will update clang in the next msys2 package to handle the msys2 layout
A bit unrelated but still on topic of clang gcc I have build a fully independent clang toolchain for mingw-w64.
What this mean by this is that we no longer require gcc.
I patched the mingw-w64-crt to be buildable with clang and
I patched the clang driver and got compiler-rt working for mingw-w64 along with libc++.
I would prefer to move the package in the direction of defaulting to use compiler-rt and libc++ instead of libgcc and libstdc++
I sent in the patches to llvm commits for the compiler-rt support but didn’t get reply from anyone
Yaron maybe you would be able to help me in getting this reviewed / merged
All the patches are here
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-clang-svn
Kind Regards
Martell
Hi Martell,
Can you build the whole toolchain without any GNU stuff?
What replaces make, gprof, addr2line, c++filt? Is lldb working perfectly on Windows/GNU?
Right now clang drops in the mingw chain which requires us to maintain mingw compatibility, a task by itself.
Making and maintaining/owning a mingw-w64 toolchain distribution is much larger undertaking and I don’t have the time for it. I can review additions/expansions/bug fixes to the mingw toolchain though.
Yaron
Sysroot is not used for tools look-up, that would be pretty insane for
cross-compiling. You want to use -B for that.
Joerg
Can you build the whole toolchain without any GNU stuff?
What replaces make, gprof, addr2line, c++filt? Is lldb working perfectly on Windows/GNU?
Well i am using cmake so you can use ninja or whatever generator is uses.
In terms of the other things you mentioned binutils is still required as lld is not quite ready to handle this
I did say it was independent of gcc not binutils 
I have’t tested lldb but that will be the next package I work on.
Right now clang drops in the mingw chain which requires us to maintain mingw compatibility, a task by itself.
Well thats exactly what I changed
Clang can now build the mingw-w64 crt itself also so gcc is not needed at all.
Hi Yaron,
I’m adding j-b from videolan to the CC list.
We are looking at setting up a build bot for this target as we have a lot of invested interest in this target.
It would be great if we could get my patches reviewed and whatever changes needed to get them merged.
Is there anything you need from us to get this merged?
I don’t know who to add as a reviewer on pabricator for this target
The only one that came to mind was yourself because you helped me with the mingw-w64 driver review last time
Kind Regards
Martell
That does work but could you please look at my comment regarding a problem with clang and the mingw-64 intrin.h in gcc-4.9 and gcc-5.1.
I don't mind Hurcan taking over this thread I started since he had his own problem with clang targeting gcc on Windows, but I would like a little clarification of what I have reported using clang with mingw-64/gcc-4.9 and mingw-64/gcc-5.1. Thanks !