similar to: Why is there a llvm/apple-llvm-project-staging ?

On Mon, Jul 6, 2020 at 5:21 PM Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > There's an email thread at this point :) You mean http://lists.llvm.org/pipermail/llvm-dev/2020-July/142951.html ? I wasn't sure that was directly related - since that thread seems to be asking for permission/buy-in to /add/ a branch, it doesn't (based on my reading at

On Mon, Jul 6, 2020 at 5:29 PM Eric Christopher <echristo at gmail.com> wrote: > > Yep. That thread. It got there eventually around this branch as well. It's a... long thread at this point. *nod* I think I've read it all - and don't see mention of this subproject/fork/thingy. (& that entire thread occurred after (June 29th) this email from Roman (June 21st) - and was

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 03/17/2020 06:39 AM, Roman Lebedev wrote: > On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard <tstellar at redhat.com> wrote: >> >> On 03/16/2020 11:09 PM, Roman Lebedev wrote: >>> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev >>> <cfe-dev at lists.llvm.org> wrote: >>>> >>>> On 03/16/2020 10:13 AM, Florian Hahn wrote:

On Mon, Oct 7, 2019 at 11:32 AM Roman Lebedev <lebedev.ri at gmail.com> wrote: > > Bump. Any further thoughts here? > > To recap - i don't really see how this can be a demandedbits problem - we do > demand all those bits, we just know they must be zero. > (i would love to be proven wrong though!) > > Roman. > > On Tue, Oct 1, 2019 at 11:17 PM Roman Lebedev

On Thu, Jun 25, 2020 at 9:59 AM Roman Lebedev <lebedev.ri at gmail.com> wrote: > On Thu, Jun 25, 2020 at 7:48 PM Arthur Eubanks via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > After talking with some NPM people, I believe the ultimate goal after > NPM is enabled by default is to only support `-passes=`, and remove support > for `-foo-pass`. > Hm,

Please can we shut down one of the two systems for new bugs ASAP? We've already had an instance of someone filing the same bug using both systems, with two different fixes being committed by two different people at the same time... On Tue, 17 Mar 2020 at 06:49, Robinson, Paul via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > > -----Original Message----- > > From:

Hi Roman, Thanks for your good idea. I think it can solve the abs issue very well. I can continue with my work now^-^. But if it is not abs and there is no select, %res = OP i32 %b, %a %sub = sub i32 0, %b %res2 = OP i32 %sub, %a theoretically, we can still do the following transform for the above pattern: %res2 = OP i32 %sub, %a ==> %res2 = sub i32 0, %res Not sure whether we can do it

Sorry, I didn't notice this change of default last night. Thanks for fixing this! -- Mehdi On Tue, Jul 28, 2020 at 5:50 AM MyDeveloper Day via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I've made the change > > https://reviews.llvm.org/harbormaster/plan/5/ > > MyDeveloperDay <https://reviews.llvm.org/p/MyDeveloperDay/> changed the Hold > Drafts

On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Mehdi AMINI <joker.eph at gmail.com> writes: > > > What is the practical plan to enforce the lack of merges? When we > > looked into this GitHub would not support this unless also forcing > > every change to go through a pull request (i.e. no pre-receive hooks >

This looks to be a reasonable starting point. A couple of nit picks, none are blockers. 1. I'd hold off on handing out the sub-domain for the moment. This feels more official than we probably want for a random incubator.  I reserve the right to change my mind here, but maybe we should delay this part until we see what actual incubators look like?  As an alternative, maybe

> On Jun 30, 2020, at 11:52 AM, Roman Lebedev <lebedev.ri at gmail.com> wrote: > > On Tue, Jun 30, 2020 at 9:44 PM Chris Lattner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> The idea of adding an “incubation” stage to projects in the LLVM world seems to be positively received. I also noticed that we don’t really document the new project policy in

Hi. As per[1], gcc-4.8 is the oldest supported *major* gcc version. But what about minor/patch versions? When https://reviews.llvm.org/D43779 was initially committed, a few[2][3] buildbots failed. As i have now looked into the issue: * but it is *REPRODUCIBLE* with gcc-4.8.4 and gcc-4.9.2 from debian oldstable (Jessie). * it is *NOT* reproducible with gcc-4.8.5 and gcc-4.9.3 from ubuntu 16.04,

The current documentation talks about both the Phabricator review, and review as mail replies on -commits lists. It also talks about submitting patches to lists, with the subtext that it may be friendlier for outsiders. It is true that Phabricator has some entry threshold, larger than github, or maillists, so the attempt is not unwarranted. But from what i can tell, 99.9% patches go via

05.07.2020, 05:22, "Roman Lebedev" <lebedev.ri at gmail.com>: > On Sun, Jul 5, 2020 at 12:18 PM Shawn Landden via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>  Carry-less multiplication[1] instructions exist (at least optionally) on many architectures: armv8, RISC-V, x86_64, POWER, SPARC, C64x, and possibly more. >> >>  This proposal is to add a

The thing is, we *don't* "not demand" those high bits. We *don't* not care what's in those bits - IR shifts don't mask their shift amounts. I.e we can't replace `x >> (32-y)` with `x >> (-y)`, which would be legal transform should we not demand those bits. We very much demand them. We just know those bits to be zero. And i'm not sure how to convey

Why is there a public GN buildbot that sends emails and IRC notifications? That isn't what was agreed upon. Either un-GM it, or silence it. Roman. On Fri, Jun 28, 2019 at 1:05 AM <llvm.buildmaster at lab.llvm.org> wrote: > > The Buildbot has detected a new failure on builder sanitizer-x86_64-linux-gn while building llvm. > Full details are available at: >

> On Dec 9, 2019, at 1:10 PM, Roman Lebedev <lebedev.ri at gmail.com> wrote: > > Yep, there seems to be an issue with commits containing non-ASCII > symbols (in Author: line?) Ah, perhaps, but I don’t seen anything obvious, at least not in the log. And the author has other commits just before and after that did generate a messages, so it seems somewhat random to me. >

+ Denis and Galina who should know about the affected buildbots and whether it's fine to upgrade them or whether their configurations reflect some important use cases. Sylvestre should know if the release process for LLVM on Ubuntu/Debian relies on the older GCC toolchains somehow. On Mon, Apr 9, 2018 at 1:51 PM Roman Lebedev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hmm,

On Tue, Jul 28, 2020 at 3:29 PM James Y Knight <jyknight at google.com> wrote: > > Please assume good faith -- I'm pretty sure this is simply a configuration mistake, since Mehdi just upgraded Phabricator to a new upstream revision last night. > Probably the default behavior changed in the new upstream version, and it just needs to be turned off. Yep, that's why i'm