Uploaded AArch64 binaries:
2c3bd3d686c3712ba5699e9a638bc849ddb0aae3
clang+llvm-8.0.0-rc1-aarch64-linux-gnu.tar.xz
Had one failure in check-all (memory sanitizer). I opened PR40511 for it [1].
I ran into some snags with ARM, I'm still figuring out if there's
something wrong with our infrastructure
On Mon, Jan 28, 2019 at 6:23 PM Bero Rosenkränzer
wrote:
>
> Hi,
> working without immediately obvious regressions on OpenMandriva x86-64, x86,
> aarch64 and armv7hnl.
> Since our 4.0 release is imminent, 8.0 won't go in there, but it will be our
> main compiler the day after the release and bee
He all,
I've updated the downstream fork zipping tool that I posted about last
November [1]. It is much improved in every way. The most important
enhancements are:
- Does a better job of simplifying history
- Handles nested submodules
- Will put non-submodule-update content in a subdirectory
Björn Pettersson A writes:
> In the new monorepo UC1 may or may not be a parent to UL1.
> We could actually have something like this:
>
> UL4->UC2->UL3->UL2->UL1->UL0->UC1
>
> Our DL1 commit should preferably have UL1 as parent after
> conversion
>
> UL4->UC2->UL3->UL2->UL1->UL0->UC1
>
Reviving this old thread and +Joshua Peraza who's
also interested in this.
On Wed, Dec 13, 2017 at 4:17 PM Leonard Mosescu wrote:
> Thanks Greg,
>
> 1. Expose the opaque ptr as an opaque handle()
> - this is an easy, quick and convenient solution for many SBxxx types
> but it may not work
Hi,
As part of the migration of LLVM's source code to github, we need to update
our developer policy with instructions about how to interact with the new git
repository. There are a lot of different topics we will need to discuss, but
I would like to start by initiating a discussion about our mer
A linear history makes it much easier to git-bisect, since each commit can be
rolled back individually. Easier cross-project bisection is one of the
advantages of having the monorepo, and I wouldn't want to loose that.
-- adrian
___
lldb-dev mailing li
Tom Stellard via Openmp-dev writes:
> As part of the migration of LLVM's source code to github, we need to update
> our developer policy with instructions about how to interact with the new git
> repository. There are a lot of different topics we will need to discuss, but
> I would like to start
[Armchair observer...]
If any merges are allowed, they should be rare, have recent parent commits,
or the history graph becomes useless.
4. Each reviewed bug / feature must be rebased onto the current "known
good" commit, merged into a "probably good" commit, tested by build bots,
and only then p
SLES and Ubuntu 14.04 tarballs uploaded. Sorry for the delay. I will try
and find time to make a build for bionic / 18.04 too.
99ec00702e39b096ace4fbce3d787b9e485b879e
clang+llvm-8.0.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
dbf204f70cb09ec459e5eb4fc14e8fa71292daa7
clang+llvm-8.0.0-rc1-x86_64
10 matches
Mail list logo
