search for: recommit

...me. I've accidentally removed the directory /home/vadve/shared/PublicCVS/llvm-test/MultiSource/Benchmarks/MiBench from the LLVM Test CVS repository. I can either have our IT people restore it off of backup, or if someone has an updated copy of it, they can re-commit all the files. If you can recommit the files, please email me and do so. Otherwise, I'll email our IT people tomorrow morning and have them fetch the backups. My apologies. -- John T.

...by the third time I’d had to fix them, I was getting pretty good at it. I don’t wish to change the policy with regard to reverts (having a working and stable head is very valuable), but it would be good if we could have a stronger policy that stuff that is reverted goes into Phabricator and is not recommitted until the person who initially reverted it has signed off (or, at least, there’s a strong consensus that it’s the right thing). The main lesson for me is that more frequent merges will be less painful. That’s a big change, because previously I’d spend a day or two fixing merge conflicts no mat...

...ything. ~Craig On Mon, Feb 27, 2017 at 8:47 PM, Nirav Davé via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yes. I'm seeing that as well. Not clear what's going on. > > In any case it looks to be unrelated to the alias analysis so barring > concerns, I'm going to recommit the patch in the morning and let others > take a look at this. > > -Nirav > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -------------- next p...

Just be aware that those ifdefs were recommitted and reverted several times, so I'm not sure what the state is. On Fri, Sep 28, 2018 at 8:48 AM Alastair Murray via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kern, > > We also had issues with mixing GCC/Clang builds when testing the 7.0 > release branch. > >...

This patch only results in relaxing dependencies. This now *allows* new orderings that were not previously allowed, but, the fact that we then actually get such a suboptimal output likely indicates an issue elsewhere, that this allowance is exacerbating. Some observations: 1. For some reason, memop folding seems to be generating seriously non-optimal instructions. It is somehow causing there to

...rch 2017 at 14:58, Hal Finkel <hfinkel at anl.gov> wrote: > When you reverted r282259 in 282289, you also reverted the functional fix > to make the command-line option actually work. Right now it is broken. > Regardless of what else we do, we should fix this (we should probably > recommit r282259, with the default flipped, to pick up the fixes). We should run check-all and the test-suite with it on/fast before flipping the switch, and make sure that the behaviour Sebastian encountered is dealt with before this going live, or we'd be breaking too many test-suites and reverting a...

Hi Evgeny, Quentin and Matthias found it was a problem about subreg live range update and will push a fix soon (http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170123/424126.html). Thanks, Wei. On Fri, Jan 27, 2017 at 10:35 AM, Wei Mi <wmi at google.com> wrote: > Sure. Will keep you posted. > > Thanks, > Wei. > > On Fri, Jan 27, 2017 at 10:31 AM, Evgeny

No objections here. I'd be glad to see this go in. :) - Lang. On Fri, Jul 18, 2014 at 4:30 PM, Eric Christopher <echristo at gmail.com> wrote: > Sounds like we've got sufficient amount of momentum here for Dave to > go ahead and recommit. Any last objections? > > -eric > > On Fri, Jul 18, 2014 at 1:35 PM, Eli Bendersky <eliben at google.com> wrote: > > > > > > > > On Fri, Jul 18, 2014 at 12:06 PM, Jordan Rose <jordan_rose at apple.com> > wrote: > >> > >> I don'...

...he bit-test instruction above. After the patch was committed, two more exceptions were found which led to reverting the patch (https://reviews.llvm.org/rL304762). Looking for safe-alternatives that will assure us correctness of each added entry, we narrowed our options to the following 3: 1- Recommitting TableGen's backend as "disable by default": a- prepare a full instruction list of the exceptions in X86 ISA. b- Mark these instructions with special flag to indicate illegal folding. c- Integrate the backend into llorg while disabling it by default. d- Provide...

Thanks for your replies. That was a very useful discussion. I won't recommit on a Friday afternoon, but will do on Monday, as it looks like we agreed again on the direction and the change. Orthogonal to this change, the interesting topics brought up are improved diagnostics, and the cases the vectoriser misses. I will briefly look why this particular case isn't vectoris...

...on: "the optimizer was unable to perform the requested transformation". We could argue about the suggestions given as to why the transformations didn't happen in this case, but overall I think this is an improvement. I just wanted to check if we are happy with this behaviour? Okay to recommit? Cheers, Sjoerd. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191002/4f680ac1/attachment-0001.html>

Hi everyone, In the reviewing system, after a patch is approved, what should be the following step? I assume I'll have to make sure the patch hasn't broken anything, before pushing it, so I'll wan't to run a full build+tests, probably in a remote sterile environment (like a jenkins server). Do we have an integration system like this? Or should I just trust the build+tests on my

...a symbol alias to the linker script for libLLVM.so? -Tom > Alastair, if you noticed this during the release testing, did you > surface it anywhere? > > > On Fri, Sep 28, 2018 at 6:07 PM, Reid Kleckner <rnk at google.com> wrote: >> Just be aware that those ifdefs were recommitted and reverted several times, >> so I'm not sure what the state is. >> >> On Fri, Sep 28, 2018 at 8:48 AM Alastair Murray via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> Hi Kern, >>> >>> We also had issues with mixin...

Folks, I've been asking around people about the state of FP contract, which seems to be "on" but it's not really behaving like it, at least not as I would expect: int foo(float a, float b, float c) { return a*b+c; } $ clang -target aarch64-linux-gnu -O2 -S fma.c -ffp-contract=on -o - (...) fmul s0, s0, s1 fadd s0, s0, s2 (...) $ clang -target aarch64-linux-gnu -O2 -S fma.c

Why are you reverting patches for any area that you have no authorization for ? No build was broken. This patch is fine. I am authorized to check in to the Mips area and Daniel is the maintainer for that area. On 06/08/2014 02:13 AM, Alp Toker wrote: > Author: alp > Date: Sun Jun 8 04:13:42 2014 > New Revision: 210424 > > URL:

On Fri, Jul 18, 2014 at 12:06 PM, Jordan Rose <jordan_rose at apple.com> wrote: > I don't have much to add here besides +1. I think using std::unique_ptr > even for create* functions/methods is the right way to go. +1 smart pointers here are a win in terms of safety and self-documentation. I don't see why create* factories should be treated differently. Eli >

...tor or email. There > is a strong expectation that authors respond promptly to post commit > feedback and address it. Failure to do so is cause for the patch to be > reverted. If substantial problems are identified, it is expected that > the patch is reverted, fixed offline, and then recommitted (possibly > after further review.) > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- next part -------------- An HTML attachment was...

...irectory > /home/vadve/shared/PublicCVS/llvm-test/MultiSource/Benchmarks/MiBench > from the LLVM Test CVS repository. > > I can either have our IT people restore it off of backup, or if > someone > has an updated copy of it, they can re-commit all the files. > > If you can recommit the files, please email me and do so. Otherwise, > I'll email our IT people tomorrow morning and have them fetch the > backups. > > My apologies. > > -- John T. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.ui...

...that case. However, people do make mistakes. When something bad happens, don't be shy about reverting a broken patch, particularly when it is an obvious problem. The author may be away, and there is no reason to wait for them to fix it. When they get a chance, they can fix the patch and recommit. There is nothing personal about it. :) I think too often we wait for patches to be fixed, rather than *immediately* reverting a known broken patch. If you have run up against a problem, you can be sure that many other people are hitting the same problem too, they just may not be saying anyt...

There is a second issue with the new TableGenBackendSkeleton.cpp file. It is a skeleton file for writing a new TableGen backend. /home/buildbots/docker-RHEL-buildbot/SetupBot/worker_env/ppc64le-clang-rhel-test/clang-ppc64le-rhel/llvm/llvm/lib/TableGen/TableGenBackendSkeleton.cpp:38:17: error: private field 'Records' is not used [-Werror,-Wunused-private-field] RecordKeeper &Records;