similar to: How to get a review for a patch?

Hi Shoaib, > You added the old account for Eli (eli.friedman); I went ahead and switched it > to the newer account (efriedma). You can tell it's an old account because if you > go to https://reviews.llvm.org/p/eli.friedman/ (which can be accessed by e.g. > clicking the eli.friedman in your reviewers list), the last activity is from > 2016, whereas

On 10/15/2019 09:44 PM, Mehdi AMINI wrote: > > > On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard <tstellar at redhat.com <mailto:tstellar at redhat.com>> wrote: > > On 10/15/2019 09:24 PM, Mehdi AMINI wrote: > > Hi Tom. > > > > One issue with this is that we don't have a clear "ordering" from linear revision numbers from

+1. And put it in the email (subject?). While it’s possible to derive a count from a hash manually, better to have it in the email in the first place. You can’t rely on order-of-email-delivery to reflect order-of-commit. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Shoaib Meenai via llvm-dev Sent: Wednesday, October 16, 2019 1:42 AM To: tstellar at redhat.com;

I believe (and I believe it was James who pointed this out on IRC) that Phabricator pulls in all refs, and GitHub stores PR commits under refs/pull. On 5/30/19, 3:37 PM, "llvm-dev on behalf of Tom Stellard via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: On 05/30/2019 10:04 AM, Sachkov, Alexey via llvm-dev wrote: >

On 10/16/2019 07:31 AM, Roman Lebedev wrote: > +1, please. > > Also, putting a tag on the *first* commit in the repo, > and doing `git describe --match FIRST_COMMIT_TAG` will be *great*! > Do we need to add a tag or is `git rev-list --count HEAD` good enough? -Tom > Roman. > > On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev > <llvm-dev at

I've successfully used Peter's patches to get past those relocation errors. On 6/28/17, 9:36 AM, "llvm-dev on behalf of Peter Smith via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Yes it should cover the following relocations: R_ARM_CALL (ARM BL/BLX) R_ARM_JUMP24 (ARM B) R_ARM_THM_CALL (Thumb BL/BLX)

On Fri, May 31, 2019, 10:02 AM Roman Lebedev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, May 31, 2019 at 10:55 AM Manuel Klimek via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > We should be able to control the noise of these > > >, but I also wonder whether we can switch to github reviews as part of > the git move :) >

Hello all, It's been a month since my previous email on the topic, and since then I've done some initial work on porting the coroutines passes to the new pass manager. In total there are 6 patches -- that's a lot to review, so allow me to introduce the changes being made in each of them. # What's finished In these first 6 patches, I focused on lowering coroutine intrinsics

At a guess that looks like your llvm and lld checkouts are not quite in synch. It will be worth updating llvm and lld to top of trunk. I've rebased the consolidated patch https://reviews.llvm.org/D34634 this morning, it might be worth trying that if you are seeing problems. Peter On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote: > Hi, I tried

Adding cfe-dev, since this is a clang issue. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Jim Meyering via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Jim Meyering <jim at meyering.net> Date: Monday, April 2, 2018 at 8:40 PM To: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: [llvm-dev] trivial input provokes failed

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

While attempting to reduce a ubsan-specific bug, I stumbled upon the following. [I would have filed a bug report, but don't have an account, and so requested one per https://bugs.llvm.org/ about 7 hours ago -- but still no response, so am sending this instead. ] Using clang built from latest master of about 5 hours ago: $ echo struct a typename a | clang -x c++ - <stdin>:1:19: error:

On 10/16/2019 12:02 PM, Roman Lebedev wrote: > On Wed, Oct 16, 2019 at 9:55 PM Tom Stellard <tstellar at redhat.com> wrote: >> >> On 10/16/2019 07:31 AM, Roman Lebedev wrote: >>> +1, please. >>> >>> Also, putting a tag on the *first* commit in the repo, >>> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*! >>>

I actually run a in-house Phabricator instance with 400+ users and multiple git repo including custom extension developments I also follow the Phabricator development quite closely because we upgrade every couple of weeks I’d be more than happy to help maintain the phab instance for LLVM MyDeveloperDay On Fri, 31 May 2019 at 09:19, Manuel Klimek via llvm-dev < llvm-dev at lists.llvm.org>

+llvm-dev From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Bader, Alexey via cfe-dev Sent: Thursday, May 30, 2019 7:31 PM To: clang-dev developer list <cfe-dev at lists.llvm.org> Subject: [cfe-dev] FYI: LLVM Phabricactor notifications. Importance: Low Hi, I think some of contributors to the Clang received a notifications about some commits done in the past. I wanted

I tweaked the notifications yesterday, hopefully we don't see more spam storms. For filtering git refs: this is something that has changed substantially in Phabricator over the past couple of months, but I think I've managed to restrict notifications to only "master." (Although, again, this has changed a lot... getting this right depends on my own archaeological skills for

> On Mar 3, 2020, at 17:16, Shoaib Meenai <smeenai at fb.com> wrote: > > `arc patch` should preserve the author information in the original commit, if there was any. At least it has in my experience. Yes, but I think people can upload raw patches to Phabricator without using `arc diff`. I know I ran into one of these just last week where I used Johannes' script (thanks!) and

David Jones via llvm-dev <llvm-dev at lists.llvm.org> writes: > GDB likes to load all symbols from shared libraries up front. And on > x86_64 your main executable is really just another shared library. Yes, but does gdb reload everything on each execution? Every time I execute "run" I see the same slow behavior. Loading the symbols for small tools like llvm-rc takes

David Jones <dlj at google.com> writes: > >> * Provide C symbols as specified by the standards, but take advantage > >> and use C++ language facilities for the core implementation. > > Does this mean C programs would require a C++ runtime? If not, how will > the project ensure that? > > Shooting from the hip: no. Turning off exceptions, RTTI, and static

I discovered that I can hack around my particular problem by placing set_property(TARGET clang PROPERTY INTERFACE_LINK_LIBRARIES) at the end of tools/driver/CMakeLists.txt. I'd prefer to fix this properly though, of course. On 12/1/17, 4:18 PM, "llvm-dev on behalf of Shoaib Meenai via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org>