RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

If mingw-w64 were a viable alternative, I have to assume that people
would already be using it (it's been around and working well for ages).

People are! Dropping mingw.org support is perfectly fine by me, as
a frequent user of MinGW-w64. So the remaining question is which
configurations of MinGW-w64 will be supported to build LLVM/Clang.

Many projects currently use mingw-w64-win32threads (Rust, Julia, the hundreds
of cross-compiled libraries at https://build.opensuse.org/project/show/windows:mingw:win64
etc). In Debian before about 10 months ago, Fedora pre-21, openSUSE, and
Cygwin, the default MinGW-w64 configuration is win32threads. So requiring
the pthread configuration of MinGW-w64 would make LLVM/Clang more difficult
to cross-compile from those build environments. Arch switched to the
pthread configuration, not sure when. 2 months ago Debian introduced
the ability for the user to choose which threading configuration to use.
Getting that switching functionality into more distributions would help
with cross-compilation flexibility.

Switching from mingw-w64-win32threads to mingw-w64-pthreads is likely
not that painful, one more runtime dll dependency and maybe a few
source changes due to different headers is not too bad. Performance
of multithreaded code should be benchmarked and compared between the
two configurations, I'm not aware of any such existing data.

However the end goal is making clang and libc++ a more viable replacement
so mingw becomes not as important except for initial bootstrapping.
(Or languages for which GCC has frontends but LLVM doesn't.)
If clang itself becomes a better choice than the mingw-w64-win32threads
compiler that these projects are currently using for performance or
availability reasons, then it's not so important which mingw
configuration gets used to build clang in the first place.

For current users of mingw[-w64], I suspect they will care more about
the gcc-style clang front-end for build system reasons, rather than
clang-cl. So having both work properly and in a complete self-sufficient
way would be ideal for compilation on Windows. For cross-compilation
from either Linux or Cygwin to Win32, the gcc-style front end would
be more useful.

I'll probably open a bug on this, but I just tried using clang.exe 3.5.0
built with either MSVC or MinGW-w64-win32threads. When built with MinGW-w64,
clang.exe is too promiscuous in terms of where it picks up system headers.
It found a set of mingw.org headers installed elsewhere on my system
(definitely not on my path) which it proceeded to error on:

c:/mingw/include\wchar.h:539:53: error: functions that differ only in their return type cannot be overloaded
__CRT_MAYBE_INLINE __cdecl __MINGW_NOTHROW intptr_t _wfindnext32i64(intptr_t _fp, struct _wfinddata32i64_t* _fdata) {
                                                    ^
c:/mingw/include\wchar.h:493:30: note: previous declaration is here
int __cdecl __MINGW_NOTHROW _wfindnext32i64 (intptr_t, struct _wfinddata32i64_t*);

So, would love if clang could be a more self-sufficient toolchain and stop
picking up headers from strange places that just happened to be sitting on
my hard drive in the default install location, since those headers were not
used to build clang at all.

-Tony

I'll probably open a bug on this, but I just tried using clang.exe 3.5.0
built with either MSVC or MinGW-w64-win32threads. When built with
MinGW-w64,
clang.exe is too promiscuous in terms of where it picks up system headers.
It found a set of mingw.org headers installed elsewhere on my system
(definitely not on my path) which it proceeded to error on:

I think we already have a bug http://llvm.org/bugs/show_bug.cgi?id=18546.
Clang driver never had proper support for MinGW.

So, would love if clang could be a more self-sufficient toolchain and stop
picking up headers from strange places that just happened to be sitting on
my hard drive in the default install location, since those headers were not
used to build clang at all.

I was under the impression that we were trying to move a away from this
"clang picks up headers from the toolchain it was built with" logic?
Clang's default triple is determined at configure time which is a bit
unfortunate. I think most people would agree that msvc compatible triple
should be the default for windows version of clang.

Nikola, there is a patch for this, see http://reviews.llvm.org/D5268

I think most people would agree that msvc compatible triple should be the default for windows version of clang.

…except for those of us who ship a windows-hosted cross compiler (and don’t want to give it a triple-prefixed name).

–paulr

I understand your point but it's very strange if this logic is baked into
the binary at compile time. If someone downloads the binary we provide on
the website they'll have to know that it defaults to MinGW as it was built
with MinGW (I think). In that case we'll probably need to provide an
additional binary that targets msvc. Anyway, let's not steal the thread,
there'll be plenty of time to discuss this...

Sure. Hopefully we already make it easy for vendors to control the default
triple with -DLLLVM_DEFAULT_TARGET_TRIPLE or whatever it's called.