similar to: RFC: Adding a staging branch (temporarily) to facilitate upstreaming

On Mon, Jun 29, 2020 at 9:43 PM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hey Duncan, > > On Mon, Jun 29, 2020 at 8:28 PM Duncan Exon Smith via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> To facilitate collaboration on an upstreaming effort (see "More context" >> below), we'd like to *push a branch* (with history)

On 6/30/20 2:07 PM, Chris Lattner via llvm-dev wrote: > > >> On Jun 30, 2020, at 2:02 PM, Duncan Exon Smith <dexonsmith at apple.com >> <mailto:dexonsmith at apple.com>> wrote: >> >> >> >>> On 2020-Jun-30, at 13:28, Chris Lattner via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:

> On 2020-Jun-30, at 13:28, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Jun 29, 2020, at 10:15 PM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> IMO, a pull request isn't as clear given that they haven't been used for contributions before. This is not a time

The downsides of an additional project are small. I can see: 1) It's not possible to do pull requests from there, because GitHub won't treat it as a fork. 2) It's still visible to people ( http://lists.llvm.org/pipermail/llvm-dev/2020-June/142559.html) In the end I don't have a strong opinion on whether this is a branch or a repository, as long as we move ahead soon. On Thu, Jul

As noted in the other thread, making a new repository under the same user, which therefore must be unrelated to the original, seems to have downsides as far as commit duplication on github. Probably the downsides of that are non-critical (and less bad than a bunch of email spam), but it's still unfortunate. It still very much feels to me that the best answer should be to do none of the above,

On Tue, Jan 7, 2020 at 5:35 PM Jonas Devlieghere <jonas at devlieghere.com> wrote: > On Tue, Jan 7, 2020 at 5:16 PM Bill Wendling via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > > > On Tue, Jan 7, 2020 at 4:59 PM Doerfert, Johannes <jdoerfert at anl.gov> > wrote: > >> > >> Hi Bill, > >> > >> On 01/07, Bill Wendling

Hi, One takeaway for me from the recent Phabricator vs Github PR discussions was that arc (arcanist) can be a pain to set up and may pose a hurdle for some contributors. I think those points could be addressed relatively easily by adding a llvm-patch script (or an even better name) that allows users to create and apply patches from reviews.llvm.org using Phabricators API. In my experience, the

Hello. I'm KDE developer and while poking around LLVM, I've stumbled upon LLVM IR syntax definition for Kate. Is there any reason why hasn't this been upstreamed ( https://phabricator.kde.org/source/syntax-highlighting/repository/master/ )? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi all, I'm new to llvm development and I have basic (beginner level) questions regarding the workflow of the llvm project. I want to clarify that the following steps is the workflow of the llvm project to prepare and submit a patch. 1. Clone the git repo (master) and create a branch named "test branch". 2. Make changes to the "test branch" and git fetch all the

>> 3. For many (most?) developers, changing to a monolithic git repo is a >> *bigger* workflow change than switching to separate git repos. Many >> people (and at least some downstream infrastructure) use the git >> mirrors exclusively, aside from git-svn for committing. >> >> I believe the idea is to continue to maintain the read-only independent >> git

Hello. Some time ago, https://github.com/llvm/apple-llvm-project-staging appeared. I do not recall seeing any discussions about it (especially before the fact) here. It is a standalone repository, not a fork, therefore github wrongfully counts everyones commits twice - once in the proper repo, and once in there. That can not be worked around, as far as i understand. So, why is it there in the

Hi, We would like to upstream exception handling support for Windows on ARM64. Microsoft-published specifications can be found here: a) https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling b) https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions We propose the following approach: 1) Upstream miscellaneous clang and llvm patches that are

I just got a Diffusion notification about a change of mine being reverted by Fangrui, but I'm not sure that's actually what happened and am confused and concerned. My commit was "[DebugInfo] Allow spill slots in call site parameter descriptions", and it appears in the history under two hashes: 1ee84e and 67c416. The first commit contains the actual change. The second touches

Hi all F18 merging has finished so commit access should be back to normal. Thanks Rich > -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Richard > Barton via llvm-dev > Sent: 9 April, 2020 16:08 > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] F18 upstreaming Now! > > Hi all > > We are about to merge F18

Hi, time ago I started doing support for 4k sector disk for syslinux. Patches worked for my cases (ext) and did not introduced regression problems with normal disks. Now I would like to update these patches and upstream them. It's not clear however which is the branch I should use to rebase these patches. Previous patches was against syslinux-4.06 but now there is syslinux-5.01 (elflink)

Hello, Background: We (the Portable Native Client team) would like to continue upstreaming our LLVM modifications which contain support for Software Fault Isolation (SFI) as required for sandboxing programs to run under Native Client. Since the "total patch size" is quite big, we are splitting the effort to manageable chunks that can be committed, tested and reviewed separately as

> On May 31, 2016, at 1:16 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> There has been some discussion on IRC about SVN hosting and the perils >> of doing it ourselves. The consensus on the current discussion was >> that moving to a

On Fri, 1 Feb 2019 at 20:35, Matt Arsenault <arsenm2 at gmail.com> wrote: > Oh right, you don’t have the addrspace in the input. Input to what? Even if it's available it's wrong without a fixup pass. Still, custom override for GEP as you talk about later could overcome the problem... > I have long wanted a way for targets to take over the GEP expansion which may help you?

On Fri, 1 Feb 2019 at 20:08, Matt Arsenault <arsenm2 at gmail.com> wrote: > I don’t see why this would need to be an IR pass. There aren’t all that many places left using the default argument to the various pointer function that can mostly be fixed. iPTR is hopelessly broken on the tablegen side, but you wouldn’t get to that point with this. The difficulty I'm seeing is that we need

There are huge differences between source files in the version 3.0.9 released as a tar.gz and source files in git. I would assume that the released version would correspond to the version in git but with 3.0.9 it is not like that. In 3.1.0 the released and git versions are more or less the same. So my question is, from what source files was the 3.0.9 version created? Thank you. Regards, Michal