[cfe-dev] [LLVMdev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

[Tony Kelman]

> 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