similar to: Phabricator disc is full, it's all but down.

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

Hello, I'm seeing what appears to be a serverside error - "Internal Server Error FilesystemException: Failed to create a temporary directory: the disk is full." if arc diff --trace. Anyone else getting this - any idea what to do? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

It appears that Phabricator is down. I get: Unhandled Exception ("AphrontQueryException") #1030: Got error 28 from storage engine I have not seen anyone bring it up on the mailing list so I'm just worried that it might be only me getting this message. -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

> > Okay, it's just not immediately undefined behaviour. The C model has more > issues because of the problem with how "trap representation" is defined > (which precludes trap representations for unsigned char, two's complement > signed char, etc.). This interpretation is further stressed because C only explicitly ascribes > undefined behaviour to trap

Hello Fedor. Thank you for the information. I made a simple patch that exposes PassInstrumentationCallback so llvmGetPassPluginInfo can use it: https://reviews.llvm.org/D71086 . Would this change make sense? Thanks, Juneyoung Lee On Thu, Dec 12, 2019 at 12:44 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > > On 12/3/19 8:01 PM, Juneyoung Lee via llvm-dev wrote: > >

Hello all, Is it valid to dereference a pointer that has undef bits in its offset? For example, %p = alloca [8 x i8] %p2 = gep %p, (undef & 8) store 0, %p2 undef & 8 is always less than 8, so technically it will store zero to one of the array's elements. The reason is that I want to improve no-undef analysis by suggesting that a pointer that is passed to load/store is

> > // Members are initialized to poison at object creation. >> p = alloca {i8, i32} // p[0], p[4~7] are poison >> p[0] is an i8, so it shouldn't be poison? > > My interpretation of standard is that reading uninitialized char can also yield trap representation. If uninitialized, char variable has indeterminate value, and C/C++ does not seem to forbid reading trap

I think we need to allow this.  Otherwise, we have to prove that addresses are non-undef before we can hoist or sink a memory instruction.  Today, aliasing can use things like known bits, and if we imposed a no-undef in address requirement, we'd either need to replace such reasoning in AA, or have passes which wish to hoist/sink check the property afterwards. Or to say it differently, I

I think it’s reasonable to expect that IR generated by frontends doesn’t do this. Not sure about transforms; I can imagine that we might speculate a load without proving all the bits are well-defined. -Eli From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Juneyoung Lee via llvm-dev Sent: Sunday, September 20, 2020 3:54 PM To: llvm-dev <llvm-dev at lists.llvm.org>

It is UB when a poison is passed to certain operations that raise UB on poison, such as division by poison/dereferencing poison pointer/branching on poison condition/etc. Otherwise, poison is simply propagated, but it does not raise UB Copying poison bytes is okay: // Members are initialized to poison at object creation. p = alloca {i8, i32} // p[0], p[4~7] are poison q = alloca {i8, i32} // we

Thank you for the infos; it seems making it raise UB is problematic. Would clarifying it in LangRef be good? I can update the patch to contain the information instead. Another concern is then, how can we efficiently encode an assumption that a pointer variable in IR does not have undef bits? Certainly, in the front-end language, (most of) pointers won't have undef bits, and it would be great

Hello Sanjoy, Yep, combining it with propagateEquality of pointers may raise problem. :\ However I believe propagateEquality should be fixed properly, and adding psub also suggests a solution for that. :) It is sound to replace a pointer with another if subtraction of them is 0: a = malloc() free(a) b = malloc() // Assume b == a numerically if ((psub inbounds a b) == 0) { // a and b are

Two thoughts: 1. I think that we should aim for regularity, to the extent possible, and so we should treat nonnull, align, etc. similarly w.r.t. to whether they produce poison or UB. 2. I was thinking about the following last night, and it clarified for me why having an not_poison attribute makes sense and seems useful, and how poison/UB might affect things on a function-call boundary itself.

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>

On Wed, Feb 19, 2020 at 3:51 AM Juneyoung Lee via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think not_poison (Johannes's used keyword) makes sense. We can simulate the original UB semantics by simply attaching it, as explained. > For the attributes other than nonnull, we may need more discussion; align attribute seems to be okay with defining it as poison, dereferenceable

On 02/19, Juneyoung Lee via llvm-dev wrote: > Hello, > > > Would it be correct to resolve this by saying that dereferenceable(N) > > *implies* not_poison? This would be helpful as a clarification of how > > it all fits together. > > Yes, I think it makes sense. I don't we should do that. Take the `gep inbounds` example: char* foo(char *arg) { return `gep

Hello all, How can I see the result of lazy value info analysis? I ran a command `opt -lazy-value-info -correlated-propagation -print-lazy-value-info example.ll -disable-output` with a following program as the input: ``` define i32 @f(i32 %a, i32 %b) { %i = icmp eq i32 %a, 10 br i1 %i, label %A, label %B A: %c = add i32 %a, 20 ret i32 %c B: ret i32 0 } ``` However, it shows a

> It is important to note that this applies to trap representations and not to unspecified values. A structure or union never has a trap representation. Yes, nondeterministic bits would work for padding of struct/union, as described in (3) The third case is the value of struct/union padding. For the members of struct/union, it is allowed to have trap representation, so poison can be used.

It seems MemorySSA.cpp is the only real code where we found the problem happening. Is it possible to change the source of MemorySSA.cpp to hide the problem and buy some time for now? Now we use an empty generic_def_path_iterator with Optional<ListIndex> N being initialized by None as the end of range. Can we initialize the Optional var with a special value instead of None?