[llvm] r255621 - Fix MSVC build with LLVM_ENABLE_THREADS=OFF

[Reid Kleckner via llvm-commits]

I know that Cygwin doesn't have C++11 STL threading headers:
https://llvm.org/bugs/show_bug.cgi?id=25290

I've also heard that some Power platforms don't, but I don't have any
reference for that.

On Wed, Dec 16, 2015 at 8:24 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
>
> Sent from my iPhone
>
> On Dec 15, 2015, at 12:05 PM, Reid Kleckner <rnk at google.com> wrote:
>
> On Tue, Dec 15, 2015 at 1:55 PM, Mehdi Amini <mehdi.amini at apple.com>
> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Dec 15, 2015, at 11:50 AM, Reid Kleckner <rnk at google.com> wrote:
>>
>> I think I fixed that const qualified issue with r255678. I still have
>> warnings from ppltasks.h, which is this connect issue:
>>
>> https://connect.microsoft.com/VisualStudio/feedback/details/1132688/ppltasks-h-does-not-compile-cleanly
>>
>> I think we should ban inclusions of <future> in LLVM and make a wrapper
>> header that uses pragmas to disable warnings in <future> transitive
>> includes.
>>
>>
>> #include "llvm/Support/future.h"?
>> I can give a try at that later today, but since I can't validate with
>> MSVC it might take a few tentatives, so I don't mind if someone else do it.
>>
>
> I'm actually inclined to throw them all in "llvm/Support/thread.h", since
> we're probably going to need more ifdefs to avoid these includes when
> !LLVM_ENABLE_THREADS.
>
> Have you considered how ThreadPool should operate when the STL does not
> provide C++11 threading headers? We told users in that situation to turn
> off LLVM_ENABLE_THREADS, but this would de-support such a configuration
> altogether.
>
>
> My understanding (and the information that I got on IRC) was that the only
> reason to have LLVM_ENABLE_THREADS is to avoid some performance hit because
> of the need of locking on some globals we have here and there.
>
> So I didn't plan to support any C++11 implementation that do not allow
> std::async with launch deferred. (Note: we never need to include <thread>
> for that)
>
> If anyone has such need, it will require to rewrite a custom
> implementation for std::async with launch::deferred that can be replaced
> like we do in lib/Support/thread.h for std::thread.
> (I'll be happy to review such patch)
>
> --
> Mehdi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151217/ce5dc136/attachment.html>