Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-13 Thread Reid Kleckner via lldb-dev
These issues should be resolved by r295013 and r295014. On Thu, Feb 9, 2017 at 1:55 PM, Hans Wennborg wrote: > I'm happy as long as it builds :-) > > On Wed, Feb 8, 2017 at 2:26 PM, Zachary Turner wrote: > > Should we do that now, as a way to fix this issue, or should we try to > get > > anothe

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-09 Thread Hans Wennborg via lldb-dev
I'm happy as long as it builds :-) On Wed, Feb 8, 2017 at 2:26 PM, Zachary Turner wrote: > Should we do that now, as a way to fix this issue, or should we try to get > another fix in first so we have more time to think about using std > call_once? > > On Wed, Feb 8, 2017 at 2:19 PM Reid Kleckner

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Zachary Turner via lldb-dev
Should we do that now, as a way to fix this issue, or should we try to get another fix in first so we have more time to think about using std call_once? On Wed, Feb 8, 2017 at 2:19 PM Reid Kleckner wrote: > I think we can. MSVC's std::once_flag default constructor is constexpr > now. It still gen

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Reid Kleckner via lldb-dev
I think we can. MSVC's std::once_flag default constructor is constexpr now. It still generates dynamic initialization code if you use it as a static local, but MSVC defaults to using thread safe static initialization, so that isn't a problem unless you disable it, which we don't. We disable it in c

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Hans Wennborg via lldb-dev
I only ran into problems on Win64. I guess your bot is doing a 32-bit build. On Wed, Feb 8, 2017 at 1:41 PM, Pavel Labath wrote: > My fix was just correcting places Kamil forgot to update (or updated > over-excessively). It does not touch the root problem. > > That said, our windows bot >

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Kamil Rytarowski via lldb-dev
On 08.02.2017 22:41, Pavel Labath wrote: > My fix was just correcting places Kamil forgot to update (or updated > over-excessively). It does not touch the root problem. > > That said, our windows bot > is building > lldb with vs2015. It doe

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Pavel Labath via lldb-dev
My fix was just correcting places Kamil forgot to update (or updated over-excessively). It does not touch the root problem. That said, our windows bot is building lldb with vs2015. It does not seem to have a problem with this. On 8 Februar

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Zachary Turner via lldb-dev
Is this the right review? https://reviews.llvm.org/D5922 Being that this was over 2 years ago, I suspect it was when we were supporting MSVC2012 and 2013. Now that we're requiring MSVC2015, is it time to reconsider? I don't see any links to an MS Connect issue, so I don't know what the original

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Kamil Rytarowski via lldb-dev
On 08.02.2017 22:14, Kamil Rytarowski wrote: > // std::call_once from libc++ is used on all Unix platforms. Other > // implementations like libstdc++ are known to have problems on NetBSD, > // OpenBSD and PowerPC. > #if defined(LLVM_ON_UNIX) && (defined(_LIBCPP_VERSION) || > \ > !(defined

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Kamil Rytarowski via lldb-dev
It looks fine: diff --git a/source/Host/windows/HostInfoWindows.cpp b/source/Host/windows/HostInfoWindows.cpp index a965ec0ea..5b38e6021 100644 --- a/source/Host/windows/HostInfoWindows.cpp +++ b/source/Host/windows/HostInfoWindows.cpp @@ -18,6 +18,7 @@ #include "llvm/Support/ConvertUTF.h" #incl

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Reid Kleckner via lldb-dev
It's a sad story. Read the comments and the review threads. It's hilarious. On Wed, Feb 8, 2017 at 1:00 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Why doesn't llvm::call_once() just use std::call_once on Windows? > > On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg wrote: >

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Zachary Turner via lldb-dev
Why doesn't llvm::call_once() just use std::call_once on Windows? On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg wrote: > The Win64 lldb build seems broken (at 294367). > > I ran into this when trying to build the weekly snapshot > (http://www.llvm.org/builds/) which includes LLDB these days. > >

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Reid Kleckner via lldb-dev
Windows.h appears to `#define MemoryFence _mm_fence`. We should probably undef MemoryFence in llvm/Support/Atomic.h. On Wed, Feb 8, 2017 at 12:40 PM, Hans Wennborg via lldb-dev < lldb-dev@lists.llvm.org> wrote: > The Win64 lldb build seems broken (at 294367). > > I ran into this when trying to bu

[lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

2017-02-08 Thread Hans Wennborg via lldb-dev
The Win64 lldb build seems broken (at 294367). I ran into this when trying to build the weekly snapshot (http://www.llvm.org/builds/) which includes LLDB these days. I suspect this might be related to Kamil's changes a few days ago. I see Pavel committed something to fix Darwin afterwards. Zach,