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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

[lldb-dev] [4.0.0 Release] Release Candidate 2 has been tagged

Hello testers, 4.0.0-rc2 was just tagged from the branch at r294535. There are still open relase blocking bugs and merge requests, so this will not be the last release candidate, but we've had a lot of merges since the last one, and I'd like to see what the testing looks like. The test-release.s

Re: [lldb-dev] RTTI does not work stable in LLDB.

> On Feb 6, 2017, at 5:58 PM, Roman Popov wrote: > > Hello, > I just found out that sometimes I don't get correct dynamic type in LLDB even > if I compile with g++. How can I get typeinfo/vtable dump from LLDB to check > if it is still the same name matching issue? Stop where dynamic typi

[lldb-dev] A typo on the "Testing LLDB" tutorial page?

On the "Testing LLDB" tutorial page, in the description under "RUNNING TESTS -> Running the full test suite" section, should this > cmake -DLLDB_TEST_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja > ninja check-lldb be > cmake -DLLDB_TEST_USER_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja >