<div dir="ltr">I kind of feel like we should drop support for this configuration. Here are the reasons why:<div><br></div><div>1) clang, lld, and other LLVM-based tools already make use of std::recursive_mutex and std::mutex, so if those types don't exist in this one configuration, we have already (even if inadvertently) made a statement that we don't support that configuration.</div>
<div><br></div><div>2) We chose C++11 as the baseline because all compilers should support it. This functionality in particular is pretty egregious to not support, considering how simple it is.</div><div><br></div><div>3) Not supporting this configuration does not mean we don't support GCC / MinGW, it only means we don't support GCC / MinGW / threads-win32. There is still the threads-posix flavor of this platform which works fine on Windows.</div>
<div><br></div><div>#3 is a little unfortunate and backwards, since on Windows we should be encouraging native Windows implementations of things and discouraging posix emulation, but in this case the functionality just isn't implemented.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 9:26 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+llvmdev.<div><br></div><div>I find this pretty surprising. Actually, we already use std::mutex and std::recursive_mutex in clang, lld, and other llvm projects, it's just a coincidence that it hadn't been introduced into LLVM until my commits.</div>
<div><br></div><div>I'm not sure what the right thing to do here is. If I understand correctly, it seems like in order to encounter this, a) you must be using GCC, b) you must be using the MinGW flavor of GCC, and c) you must be using the threads-win32 flavor of this toolchain. Only if all 3 of those are true, then std::mutex and std::recursive_mutex don't exist.</div>
<div><br></div><div>Anybody else have thoughts on whether this necessitates reverting the mutex changes, or whether this toolchain configuration should be supported?</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">
On Fri, Jun 20, 2014 at 12:07 AM, Vadim Chugunov <span dir="ltr"><<a href="mailto:vadimcn@gmail.com" target="_blank">vadimcn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
FYI - this commit broke LLVM build using [[ <a href="http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo" target="_blank">http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo</a> | win32 threads ]] flavor of the mingw toolchain. I am getting [[ <a href="http://stackoverflow.com/questions/14191566/c-mutex-in-namespace-std-does-not-name-a-type" target="_blank">http://stackoverflow.com/questions/14191566/c-mutex-in-namespace-std-does-not-name-a-type</a> | error: 'recursive_mutex' in namespace 'std' does not name a type ]].<br>
Not sure if this would be considered a problem for LLVM...<br>
<br>
<a href="http://reviews.llvm.org/D4196" target="_blank">http://reviews.llvm.org/D4196</a><br>
<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>