<div dir="ltr"><div>I suppose there's also an option #3: "declare that LLVM only supports the threads-posix flavor". As long as configure script gives a clear error message...<br><br></div>It should be noted, though, that MinGW's pthreads mutexes are likely to perform worse than LLVM's home-grown ones: <a href="http://sourceforge.net/p/mingw-w64/bugs/344/">http://sourceforge.net/p/mingw-w64/bugs/344/</a> <br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 11:14 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">Sorry, I mean only disable this for THREADS-WIN32, not threads-posix.</div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 11:14 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">#2 is better if we can detect threads-win32 vs threads-posix on MinGW, and only disable this for threads-posix. We can check for _GLIBCXX_HAS_GTHREADS, but that seems somewhat hackish, so I wonder if there's a better way.<div>
<br></div><div>To handle the switching, I guess we'll have to go back to the original option of having llvm::mutex, llvm::recursive_mutex, etc, and then conditionally typedefing them. Kinda sucks, but still better than getting rid of it entirely.</div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 11:09 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@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">OK, sounds like we're screwed.<div><br></div><div>There's two options:</div><div>1. Revert and give up on C++11 threading libraries for now.</div><div>2. Do what Eric suggests. Move all the mutex usage under #ifdef LLVM_ENABLE_THREADS, and disable LLVM_ENABLE_THREADS by default on MinGW. MinGW plus LLVM_ENABLE_THREADS would become unsupported.</div>
<div><br></div><div>Do people have objections to 2? I don't really like it either.</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 10:33 AM, Yaron Keren <span dir="ltr"><<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.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="rtl"><div dir="ltr">The whole "mutex" and "shared_mutex" files are #ifdef _GLIBCXX_HAS_GTHREADS so if no _GLIBCXX_HAS_GTHREADS there are no mutexes and no <span style="font-family:arial,sans-serif;font-size:12.727272033691406px">call_once. thread lives in "thread" which is also #ifdef </span><font face="arial, sans-serif">_GLIBCXX_HAS_GTHREADS.</font></div>
<div dir="ltr"><font face="arial, sans-serif">"condition_variable" and "future" are the same.</font></div><div dir="ltr"><font face="arial, sans-serif"><br></font></div><div dir="ltr"><font face="arial, sans-serif">I have tested gcc 4.8.2 predefines and </font><span style="font-family:arial,sans-serif">_GLIBCXX_HAS_GTHREADS isn't there nor it is defined anywhere with the win32 version. I have also compiled a small test and indeed it failed with</span></div>
<div dir="ltr"><font face="arial, sans-serif"><br></font></div><div dir="ltr"><font face="arial, sans-serif"> a.cpp:4:3: error: 'mutex' is not a member of 'std'.</font></div><div dir="ltr"><font face="arial, sans-serif"><br>
</font></div><div dir="ltr"><font face="arial, sans-serif">Just for fun, I tried to compile it with -D</font><span style="font-family:arial,sans-serif">_GLIBCXX_HAS_GTHREADS but then it failed on bunch of other errors starting with </span></div>
<div dir="ltr"><span style="font-family:arial,sans-serif"><br></span></div><div dir="ltr"><span style="font-family:arial,sans-serif"> error: '__gthread_time_t' was not declared in this scope</span></div><div dir="ltr">
<br></div><div dir="ltr">so gthreads isn't there.</div><div dir="ltr"><br></div><div dir="ltr">As to popularity, compare the download graphs for 32 bit:</div><div dir="ltr"><br></div><div dir="ltr"> <a href="http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/" target="_blank">http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/</a><br>
</div><div dir="ltr"><br></div><div dir="ltr">and 64 bit:</div><div dir="ltr"><br></div><div dir="ltr"> <a href="http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/" target="_blank">http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.0/</a><br>
</div><div dir="ltr"><br></div><div dir="ltr">in 32 bit the posix version rules, whereas in 64 bit it is a close winner. If you go back to 4.8.2 the pattern is similar.</div><div dir="ltr"><br></div><div dir="ltr">The win32 version does not support anything thread-related so it's not C++11 compliant?</div>
<div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2014-06-20 19:55 GMT+03:00 Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span>:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">It sounds like this version of libstdc++ doesn't support std::recursive_mutex from C++11. This is really unfortunate, because we were hoping that moving to C++11 would allow us to use standard, portable threading primitives.<div>
<br></div><div>Does this version of MinGW have any C++11 threading support? Is it just recursive_mutex that is missing, or do we have to avoid std::mutex, std::call_once, etc? lld has been using all of these things for some time now, and in theory we have the same baseline toolchain requirements.</div>
<div><br></div><div>If it's just std::recursive_mutex, how long do you think it would take to implement that for mingw's libstdc++?</div><div><br></div><div>Do you have a sense of which version of mingw is more popular, the pthreads variant or the win32 threads variant? If the overwhelming majority use the win32 threads variant, I don't think we can break it.</div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 9:49 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">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><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><div><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>
</div></div></blockquote></div><br></div>
</div></div><br></div></div><div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>