[LLVMdev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
yaron.keren at gmail.com
Wed Sep 24 06:31:30 PDT 2014
The question is should llvm start using <thread> and <mutex> when
mingw+win32 threads does not support these.
What is the reason to use mingw+win32 threads instead of mingw+pthreads
which does support the above?
2014-09-24 15:47 GMT+03:00 Óscar Fuentes <ofv at wanadoo.es>:
> Chandler Carruth <chandlerc at gmail.com> writes:
> > AKA: MinGW + win32threads is holding LLVM (and all of its subprojects)
> > back. We need to stop supporting this host platform.
> > I'm aware of essentially 2 reasonably important use cases for supporting
> > MinGW + win32threads:
> I suppose that you are talking about MinGW (www.mingw.org) all along
> and not about MinGW-w64 (www.mingw-w64.org) which supports the features
> you are missing.
> > 1) Sane host toolchain on Windows that doesn't require downloading MSVC.
> > (I'm dubious about the value of this one...)
> Oh, well. You are talking about "everything that is not MSVC++". Ok.
> > 2) Cross-compiling a Windows clang.exe (and other tools) from a Linux (or
> > other host) box.
> I have no idea how cross-compiling from other OS can solve shortcomings
> on the *runtime* libraries of a toolchain.
> > I *really* don't want to spend lots of time going
> > there because it seems like a low-value platform, but we can.
> Thanks, I knew that you consider MinGW* "low-value" all along. MinGW-w64
> is well ahead of MSVC++ on C++ language and library support, and it is
> very likely that it will remain that way, but you take every chance to
> bad-mouth it to promote MSVC++ support on LLVM/Clang.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev