ARM looks good. Uploaded.
358fc71b8021eddbb1b93142bc09f1ad698677a6
clang+llvm-8.0.0-rc1-armv7a-linux-gnueabihf.tar.xz
Cheers,
Diana
On Wed, 30 Jan 2019 at 05:45, Brian Cain via Release-testers
wrote:
>
>
> SLES and Ubuntu 14.04 tarballs uploaded. Sorry for the delay. I will try
> and find
On Tue, Jan 29, 2019 at 5:33 PM Tom Stellard via lldb-dev
wrote:
>
> 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
> On Jan 29, 2019, at 4:55 PM, Jeremy Lakeman via llvm-dev
> wrote:
>
> 5. When a new feature is broken up into a patch series, the series should be
> rebased then immediately merged to help identify the individual patches in
> the history graph.
Typically the LLVM development model
Bruce Hoult via llvm-dev writes:
> How about:
>
> Require a rebase, followed by git merge --no-ff
>
> This creates a linear history, but with extra null merge commits
> delimiting each related series of patches.
>
> I believe it is compatible with bisect.
>
>
Björn Pettersson A writes:
> In llvm (split) we have:
>
> UL4->UL3->UL2->UL1->UL0
>\
> ...->DL2->DL1
>
> In clang (split) we have:
>
> UC4->UC3->UC2->UC1->UC0
>\
> ...->DC2->DC1
>
>
> DL1 is a commit that updates the clang submodule
On Wed, Jan 30, 2019 at 12:42 PM David Greene via cfe-dev
wrote:
>
> Bruce Hoult via llvm-dev writes:
>
> > How about:
> >
> > Require a rebase, followed by git merge --no-ff
> >
> > This creates a linear history, but with extra null merge commits
> > delimiting each related series of patches.
>
> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of David
> Greene via cfe-dev
> Sent: Wednesday, January 30, 2019 3:52 PM
> To: Jeremy Lakeman
> Cc: llvm-dev; LLDB Dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org)
> Subject: Re: [cfe-dev]
Strongly in favor of #1.
If we decide to move away from #1, I strongly believe it should be done
well after the github migration. (i.e. lets not change everything at once!)
Philip
On 1/29/19 2:33 PM, Tom Stellard via cfe-dev wrote:
Hi,
As part of the migration of LLVM's source code to
Jeremy Lakeman via llvm-dev writes:
> 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 pushed to trunk. Keeping trunk's history more
> usable, with most bad patches reworked and
This would be great. All of these tests have always been disabled on
Windows so converting them to lit tests would increase test coverage there
as well
On Wed, Jan 30, 2019 at 6:00 PM Alex Langford via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> +1
>
> Thanks for bringing this up. I'd like to
+1
Thanks for bringing this up. I'd like to see this happen!
- Alex
On 1/30/19, 5:33 PM, "lldb-dev on behalf of Davide Italiano via lldb-dev"
wrote:
As you probably know (I didn’t), lldb embeds its own version of
`pexpect-2.4`, which doesn’t support python3.
This is the
As you probably know (I didn’t), lldb embeds its own version of
`pexpect-2.4`, which doesn’t support python3.
This is the (relatively short) list of tests relying on pyexpect:
testcases/tools/lldb-mi/syntax/TestMiSyntax.py:import pexpect
# 7 (EOF)
Hello everyone,
Source, docs, and binaries for LLVM-8.0.0-rc1 are now available at
https://prereleases.llvm.org/8.0.0/#rc1
Please try it out and report any problems as bugs marked as blockers
of https://llvm.org/pr40331
Thanks,
Hans
___
lldb-dev
13 matches
Mail list logo
