similar to: Phabricator down?

I am seeing only one log entry for such error, so I wondering if this is transient. Does it still fail with retry? - Eric On Fri, Nov 4, 2016 at 6:30 AM Hubert Tong via llvm-dev < llvm-dev at lists.llvm.org> wrote: I'm getting the same error. -- HT On Fri, Nov 4, 2016 at 8:24 AM, Nemanja Ivanovic via llvm-dev < llvm-dev at lists.llvm.org> wrote: It appears that Phabricator is

Phabricator does only respond with FilesystemException Failed to create a temporary directory: the disk is full. I didn't know who to inform but I figured it might be worth to tell someone :) Cheers, Johannes

Could this issue also be related to an “AphrontQueryException #1030: Got error 28 from storage engine” error when browsing Phabricator? ~ Todd Snider From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hubert Tong via llvm-dev Sent: Friday, May 1, 2020 9:15 AM To: Mircea Trofin Cc: Nicolai Hähnle via llvm-dev Subject: [EXTERNAL] Re: [llvm-dev] arc diff says "disk is

Looks like I can't access git, documentation, bugs... I'm not sure if this email will actually go through. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171009/e63b709a/attachment.html>

Hi All, Anyone else getting the following message when accessing phabricator? AphrontQueryException #1030: Got error 28 from storage engine Thanks, Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170922/55efee12/attachment.html>

So Mehdi, you're not in favour of providing this functionality then? Or just not in favour of that use case? On Wed, Feb 8, 2017 at 10:18 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Feb 7, 2017, at 5:44 PM, Timothy Arceri via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Wed, 2017-02-08 at 00:12 +0100, Nemanja Ivanovic wrote:

I've noticed that some reviews, but not others, show up in Phab with a "buildable" indication in a "Diff Detail" box, just below the summary. Can somebody describe what that's about? Most interesting might be why it's there only sometimes, also what sort of "build" this indication is reporting. Thanks, --paulr

Would it make sense to: 1. Provide the integer Major/Minor/Patch API's for use cases where the user wants to check that the loaded version is at least some version that contains a fix they're after 2. Provide a string API for the caching use case you outlined On Wed, Feb 8, 2017 at 3:56 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Feb 8, 2017, at

On Wed, 2017-02-08 at 00:12 +0100, Nemanja Ivanovic wrote: > I am certainly willing to write up a patch to do this. I was hoping > to get a few more responses/buy-in from the community. > And honestly, I'd be interested to know if this can be back-ported to > at least 4.0 if it gets accepted. My *possible* use case is for identifying the version of llvm used to compile shaders for

Now that we have switched to git and I had to leave behind my wonderfully simple svn workflow I have noticed something curious when committing. My typical workflow once my patch is approved on Phabricator has always been: - Update my source tree to latest - Apply the approved patch - Rebuild - Retest - If all is well, commit Having to update again after rebuilding/retesting was extremely rare

On 01/26/2017 12:45 AM, Nemanja Ivanovic via llvm-dev wrote: > This has actually come up in the context of a JIT, but I think that  > having the functionality in general could be useful. > > Currently, there does not appear to be an API in LLVM to query for  > LLVM version information. In the particular context where this came  > up, LLVM is used as a shared library and various

Hi, everyone, I'm currently the code owner for the PowerPC target. I worked on the PowerPC target for many years, and that was a lot of fun, but I've not been directly involved in development for PowerPC for some time. I would like to nominate Nemanja Ivanovic for the role of PowerPC target code owner. Insofar as a code owner is responsible for making sure that patches are reviewed,

On Wed, 9 Sep 2020 at 19:26, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > - Default (i.e. no -profile-deopt-cold): do nothing > - Option with no arg (i.e. -profile-deopt-cold): add attribute only to > functions that have an execution count of zero > - Option with an arg (i.e. -profile-deopt-cold=<N>): add attribute to > functions that account for <N>% of

Revision https://reviews.llvm.org/rL314025 works. Revision https://reviews.llvm.org/rL314026 does not (404 Not Found). At the time of this mailing, the top of trunk is at 314060. Is this some kind of known problem with Phabricator recently? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Quentin, thanks so much for looking at this. I should have noticed the other spill to the same stack slot if control doesn't flow through block 2 (line 32). I am sorry to have wasted your time. For the original issue, we won't be able to do anything for the spills, but we can clean up the issue where we materialize the same constant multiple times into the same register just to spill it.

I'm not sure exactly what you're after. I was under the impression that you want to know which register is live at a specific point (an instruction). If that's the case, how do one of the two suggested solutions not suffice? If a register is live-in to a block and not killed before your instruction or it has a def and no kill within the block, it is live. Otherwise it is dead and

Thanks for the reduced test case, I’ll try to take a look by the end of the week. > On Feb 20, 2019, at 6:53 PM, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > > Finally managed to reduce this to something manageable: https://godbolt.org/z/Hw529k <https://godbolt.org/z/Hw529k> > > On line 40 of the output, we have a load-immediate to put zero into R3. Then we

Sure. I didn't use lit or ninja. I simply copied the script produced by lit (/home/buildbots/ppc64le-clang-multistage-test/clang-ppc64le-multistage/stage1/tools/clang/test/Driver/Output/target-override.c.script) into a temporary directory (along with a deep copy of the build directory). I modified the paths in the script to point to the temporary directory. Then I ran the script in a loop. For

Should be fixed by https://reviews.llvm.org/D87103 Shall we consider deprecating(emitting a warning)/removing %T from lit? lldb, lld/COFF and clang-tools-extra are the three major users of %T. There are a few other %T in other places but there are not too many. We will also investigate whether other projects using lit are using %T. On Thu, Sep 3, 2020 at 11:25 AM David Blaikie <dblaikie at

This is likely due to a race condition (%T is a shared parent directory). I'll put up a patch to fix it. On Thu, Sep 3, 2020 at 10:00 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is the machine running any jobs in parallel? Would it be worth trying running lit in the loop, rather than the script? (perhaps lit's doing something interesting) or maybe the