similar to: arc diff says "disk is full"?

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

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

I thought so, initially. But I'm able to log in to reviews.llvm.org. Also, I assume install-certificate is before any of these considerations? On Wed, Apr 8, 2020 at 6:53 PM David Blaikie <dblaikie at gmail.com> wrote: > Hmm - I'm running a pretty old version & seems to be working for me: > > $ arc version > > arcanist 3b6b523c2b236e3724a1e115f126cb6fd05fa128 (18

There's a wrinkle in this: some tests (clang ones, for instance) have output checks depending on the line position of the input. For example, they check debug info. Adding // FIXME: comments shift that. If the goal is easy identification of auto-inserted -allow-unused-prefixes directives, how about: - we make the flag an enum: true, false, and auto_inserted - we use

On Tue, Nov 10, 2020, 01:03 James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > I don't know if lit's parser is up to this (I suspect it isn't), but could > you add a comment to the end/in the middle of a RUN? Something like `# RUN: > do some thing | FileCheck %s --check-prefix=UNUSED --allow-unused-prefixes > ## FIXME? That would avoid changing the line

Hello, on a fresh install (i.e. newly-cloned arcanist and llvm-project), I get this. Any ideas? Thanks! arc install-certificate CONNECT Connecting to "https://reviews.llvm.org/api/"... Usage Exception: Failed to connect to server (https://reviews.llvm.org/api/): [HTTP/500] Internal Server Error As received by the server, this request had a nonzero content length but no POST data.

how about -allow-unused-prefixes=needs_review On Mon, Nov 9, 2020 at 3:54 PM David Blaikie <dblaikie at gmail.com> wrote: > I don't feel too strongly about the "=true" bit for legitimate cases - > I'd prefer not to have it, but it's not the end of the world. > I do feel more strongly that if you're going to automatically add it > to cases that might

My preference would be to go with the tri-value option - I think the downside of folks needing to write a value after "-allow-unused-prefixes" is not that terrible; if folks feel that using true/false/auto is weird, how about "allowed/disallowed/script_allowed" or something like that. I'd argue that the value here is getting to the place where the default is right (so we

On Mon, Nov 9, 2020 at 1:54 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Nov 9, 2020 at 10:18 AM Mircea Trofin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > There's a wrinkle in this: some tests (clang ones, for instance) have > output checks depending on the line position of the input. For example, > they check debug info. Adding

On Thu, Nov 5, 2020 at 11:36 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Nov 5, 2020 at 10:46 AM Mircea Trofin <mtrofin at google.com> wrote: >> >> >> >> On Thu, Nov 5, 2020 at 10:40 AM David Blaikie <dblaikie at gmail.com> wrote: >>> >>> >>> >>> On Thu, Nov 5, 2020 at

I recently discovered that multi-line RUN statements can actually be interrupted with non-RUN lines, without changing the behaviour. In other words, you can do something like: # RUN: some command --option1 \ ## Comment # CHECK: check something # RUN: --option2 And you'd end up with "some command --option1 --option2" being run. It's rather surprising behaviour, and not one

I think it would make more sense to add it at each individual call site. This ensures that all cases are fixed, rather than just one in a file. It also ensures that in the (hopefully unlikely) event that there are both intentional and unintentional use-cases within a file, each one gets checked. On Thu, 5 Nov 2020 at 20:29, Mircea Trofin via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On Thu, Nov 5, 2020 at 10:40 AM David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Nov 5, 2020 at 7:30 AM Mircea Trofin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> There are currently 1350 owner-less failures in the spreadsheet >> <https://docs.google.com/spreadsheets/d/1o6q3XH1n3DDyyccnYZ_kVfhFbTDzC_S09e973_cwYuw/edit#gid=0>.

There are currently 1350 owner-less failures in the spreadsheet <https://docs.google.com/spreadsheets/d/1o6q3XH1n3DDyyccnYZ_kVfhFbTDzC_S09e973_cwYuw/edit#gid=0>. These seem to be the larger areas there. If you see an area you have ownership or expertise in, please sign up for fixing the tests by Monday, Nov. 9. Otherwise, I will "blanket-add" --allow-unused-prefixes=true to the

On 03/05/2015 06:16 PM, Mircea Trofin wrote: > Thanks! > > Philip, do you mean I should transform the original IR to something > like this? Yes. > (...which is what -expand-struct-regs can do, when applied to my > original input) Sorry, what? This doesn't appear to be a pass in ToT. Are you using an older version of LLVM? If so, none of my comments will apply. >

errata: I am on 3.6 full stop. I *thought* there was a 3.7 available, based on the title of http://llvm.org/docs/ ("LLVM 3.7 documentation"). I suppose the docs are ahead of the release schedule? On Sun, Mar 8, 2015 at 9:44 AM Mircea Trofin <mtrofin at google.com> wrote: > Sorry, that phase is part of the PNaCl toolchain. This would be LLVM 3.6, > would your comments still

> On 29 Sep 2020, at 11:13, Mircea Trofin <mtrofin at google.com> wrote: > > > > On Tue, Sep 29, 2020 at 11:09 AM Daniel Sanders <daniel_l_sanders at apple.com <mailto:daniel_l_sanders at apple.com>> wrote: > Yes so long as you're including the invalid space too (IIRC it matters for DBG_VALUE in particular) the reason I didn't do that is that

You should probably pull in some folks who implemented/maintain the feature for Darwin. I guess they aren't linking this info, but only communicating in the object file between tools - maybe they flag these sections (either in the object, or by the linker) as ignored/dropped during linking. That semantic could be implemented in ELF too by marking the sections SHF_IGNORED or something

Yes so long as you're including the invalid space too (IIRC it matters for DBG_VALUE in particular) the reason I didn't do that is that there's a lot more ctors than consumers of MCRegister. It seemed cheaper to do the checks when they're consumed and pretty much every consumer I encountered started with `assert(Reg.isPhysicalRegister() && ...)`. > On 29 Sep 2020, at

On Tue, Sep 29, 2020 at 9:08 AM Quentin Colombet <qcolombet at apple.com> wrote: > Hi, > > Register can represent virtual or physical registers. > MCRegister can only represent physical registers. > That's what I thought, but MCRegister has some stack slot APIs. > Eventually all Register instances are replaced by a MCRegister. > What happens in that case to the