On Tue, Oct 5, 2021 at 9:48 AM Renato Golin via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> On Tue, 5 Oct 2021 at 17:06, Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> - Any other information that you think will help the Board of Directors
>> make the best decision.
>
> - Founda
In general, please try to structure changes so that CMake cache clobbers
aren't necessary. If you introduce changes that require clobbers by
accident, consider adding some temporary CMake logic to help buildbots
recover on their own. Some temporary CMake hacks can save a lot of time
across all the
You might want to look at the compiler-rt tests, which have support for
remote runs. Search for the '%run' substitution. It's probably not directly
applicable to gtest tests, though.
On Fri, May 26, 2017 at 8:17 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hello all,
>
> we a
On Wed, Feb 15, 2017 at 10:35 AM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> I am fine with switching mmap over to llvm if it works. One important
> thing to LLDB is we have a "mmap if not on remote file system" that must
> continue to work. If you mmap something from a network
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
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
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:
>
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
On Thu, Jan 12, 2017 at 10:18 AM, Vadim Chugunov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I was referring to this: https://support.microsoft.com/en-us/help/
> 2999226/update-for-universal-c-runtime-in-windows. Granted, it was
> probably marked as non-critical, so some users may have skip
The purpose of linking the CRT statically was to ensure that clang can run
on systems that don't have the CRT already installed from some other app or
by VS itself. As long as that is preserved, feel free to do whatever you
need.
I think we still want to link vcruntime140 statically and the C++ ru
I imagine that Hans doesn't have Python 3 installed on his system, so LLDB
didn't autoconfigure with Python support.
On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> > Does the 4.0 binary not work for you? It is the first release that contains
> preb
Right, the x86_32 calling convention that MSVC uses fails to align such
objects, and this is the error you get if you try. VS 2015 update 3
probably added __declspec(align(8)) to std::atomic<__int64>, triggering
this error if you pass one or an object that contains one by value.
On Thu, Jun 30, 20
On Thu, Jun 30, 2016 at 9:16 AM, James Y Knight via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I don't think we should do any of that. It's too complicated -- and I
> don't see the reason to even do it.
>
> There's a need for the "llvm-project" repository -- that's been discussed
> plenty -- but
I also support Chris's position of 4.0, 4.1 etc. I don't think "majorness"
is that important, and we can sort out the bit code compatibility story
some other way.
Sent from phone
On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" <
llvm-...@lists.llvm.org> wrote:
> On Mon, Jun 13, 2016 at 4:54
I'm in favor of both going to git as the source of truth, and then
switching the hosting to github.
Echoing everyone else, this unlocks a lot of good stuff that I won't
repeat, and most of it can be handled independently from the VCS move.
The major blocker I see for the move is figuring out how
On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> It has been noted that LLDB installs its own copy of six.py
> (third_party/Python/module/six/six.py) that conflicts with a standalone
> one lang/py-six (path in pkgsrc).
>
> Could we reuse an external
OK, we've had to change that several times now. At this point I think we
should just enable bigobj on that specific file. I'll try to prepare a
patch.
On Tue, Feb 9, 2016 at 9:52 AM, Aidan Dodds wrote:
> Hi Reid,
> Thanks for taking a look at this.
> Here was the full error:
>
> llvm\tools\clang
Which object file has crossed the limit? When this has happened before,
this has usually highlighted over use of templates, which is worth fixing
because it speeds up builds on other platforms as well. If MSVC 2015
instead just happens to generate say one extra section per function, then
we should
Chromium's test framework uses the same technique. It has the potential to
really slow things down if you have a lot of failing tests. You might want
some kind of threshold for giving up, I.e. here's 50 failures, I'll stop
running the rest so devs see results sooner.
Otherwise, yeah, this seems re
19 matches
Mail list logo
