similar to: Allow reopening on Phabricator

If you can find out whether it's possible with the latest phab, I can update our instance. On Tue, Jun 7, 2016, 9:15 PM Tobias Grosser <tobias at grosser.es> wrote: > On 06/07/2016 09:14 PM, Kuba Brecka via llvm-dev wrote: > > From an unrelated thread: > > > >> ... This will need to be fixed before we can commit the patch. Since > >> Phabricator

Hi Manuel, I believe you're maintaining Phabricator at reviews.llvm.org <http://reviews.llvm.org/>. Duncan likes to send his patch comments via email, like in the example below. Do you know why don't his replies get imported into the web interface? The reply was sent to "reviews+D24569+public+a5763c0a090df06f at reviews.llvm.org

> On 2 Sep 2016, at 12:11, Dmitry Vyukov <dvyukov at google.com> wrote: > > On Fri, Sep 2, 2016 at 12:09 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> >>> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com>

> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> Hi, >> >> I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in

Same problem exists, thread A can still be within REAL(call_once), but after it ran user code and set the flag to ~0. Roughly, call_once does: __call_once(flag, arg, func) { mutex_lock(mut); if (flag == BEING_INITIALIZED) { wait } else if (flag == NOT_INITIALIZED_AT_ALL) { flag = BEING_INITIALIZED; mutex_unlock(mut); func(arg); // <=== user code callback

Hi, I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. TSan already supports pthread_once and dispatch_once by having interceptors that re-implement the

On 02/02/2016 06:25 PM, Kuba Brecka via llvm-dev wrote: > Done in r259529. I unfortunately just got another failure, so this is clearly not darwin only or even low-noise on none-darwin platforms: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9965/ I very much appreciate that people are investigating this issue, but it would be really nice to meanwhile disable this test

On Fri, Jan 22, 2016 at 4:17 PM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Fri, Jan 22, 2016 at 4:11 PM, Kuba Brecka <jbrecka at apple.com> wrote: >> Hm, I tried to reproduce this as well, but unsuccessfully. From the crash >> report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer, >> in this case “0x00486000000025df”. This happens at

Hi, I would like to improve the debugging experience for ASan. The idea is to have a couple of useful commands in LLDB (probably implemented as Python scripts) that could help the user when they are debugging an ASan-enabled binary. We already have some debugging API (asan_interface.h): // Print the description of addr (useful when debugging in gdb). void __asan_describe_address(void

Hm, I tried to reproduce this as well, but unsuccessfully. From the crash report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer, in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17, which is just after the prologue and just after calling cur_thread(). So I’d say it happens when we’re dereferencing the pointer returned by cur_thread(). On OS X, we’re

On Thu, Jun 26, 2014 at 11:34 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > > As I understand, some people legitimately use Phabricator for internal > > review, ... > > MIPS currently do this for patches that only touch the MIPS backend > (details can be found at > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140602/220385.html). >

On Thu, Jun 26, 2014 at 12:01 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > > From: Manuel Klimek [mailto:klimek at google.com] > > Sent: 26 June 2014 10:40 > > To: Daniel Sanders > > Cc: Alp Toker; Eli Bendersky; llvmdev at cs.uiuc.edu > > Subject: Re: [LLVMdev] Phabricator and private reviews > > > > > On Thu, Jun 26, 2014 at 11:34

Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> writes: > What you're seeing is just the fact that lit is waiting on > subprocesses (select is waiting on the pipes i suspect). Right. Some digging revealed that it is waiting on getline_nohang.cc.tmp, a tsan test. I see that this test has been disabled for NetBSD, due to it sometimes failing. I'm seeing the same

Hi Jakub, On Tue, Jul 7, 2020 at 6:25 AM Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > There's a lot of heavily templated code in generic DomTee construction/updater, MemSSA updater, and GraphDiff that has become really hard to modify. For the context, Alina (cc'd) was recently looking into making the domtree code work with 'CFG views'; the basic idea is to

I've read "LLVM Code-Review Policies and Practices," but I remain unsure of a couple of things. Do I always wait for an actual "LGTM", or can people approve the patch for submission in other ways? What happens when a patch is approved but then there are additional review comments? Should the patch be submitted as is, then a follow-up patch submitted, or should the

On 27 May 2015 at 09:29, Justin Bogner <mail at justinbogner.com> wrote: > Mehdi Amini <mehdi.amini at apple.com> writes: >> Hi Manuel, >> >> I like Phabricator for code review much much more than emails. Let me know how >> I can help (I’m not afraid of PHP). > > Chandler updated the llvm phabricator doc to point at what we're deploying: > >

On 27 May 2015 at 12:29, Justin Bogner <mail at justinbogner.com> wrote: > Mehdi Amini <mehdi.amini at apple.com> writes: >> Hi Manuel, >> >> I like Phabricator for code review much much more than emails. Let me know how >> I can help (I’m not afraid of PHP). > > Chandler updated the llvm phabricator doc to point at what we're deploying: > >

Has anyone considered moving all LLVM development over to Phabricator? Phabricator includes - Code review (Differential) - A bug tracker (Maniphest) - Project management software - A wiki (Phriction) - Many more applications LLVM already has a Phabricator instance.

Hi Manuel, > we'd like to open the use of Phabricator as an optional tool for doing code > reviews to a wider audience. Please feel free to start your code reviews by > following the documentation at http://llvm.org/docs/Phabricator.html. sorry for the silly question but... how do you sign up? The "sign up" section doesn't have a "sign up here" link. It

Dear all, it seems as if Phabricator does not (or days delayed) send any emails to the email I added in phabricator. I got a similar report from Maximilian Falkenstein, a student working with me. These delayed or non-existing email reports make it very difficult to keep up-to-date with phabricator reviews. Best, Tobias