similar to: Hello, new to the list

> > I want to know, given a function, How do I know which block is entry > > block, which blocks are exit blocks? Is there any efficient way to > > dicectly get that information? > > Given a function you can always use Function::getEntryBlock() to get the > entry block. You need to scan the function to get the returning nodes. You could also use UnifyExitNode (a pass

While learning to write LLVM passes and following the precise instructions under http://llvm.org/docs/WritingAnLLVMPass.html, <http://llvm.org/docs/WritingAnLLVMPass.html> I got this error when loading the hello pass to run the test program: opt -load ./Release/lib/Hello.so -hello < test/test.bc > /dev/null Error opening './Release/lib/Hello.so': ./Release/lib/Hello.so:

Hey Chuck, I'm afraid I can't reproduce your error but...a problem you may run into later is that opt will complain with opt: llvm/lib/VMCore/Pass.cpp:149: void<unnamed>::PassRegistrar::RegisterPass(const llvm::PassInfo&): Assertion `Inserted && "Pass registered multiple times!"' failed. Aborted I "fixed" this by replacing the LLVMLIBS line in

I want rsync to do this: Backup all files under ~/, except in some cases. When rsync gets to ~/News, which has an extensive, fluctuating and deep heirarchy of directories under it. An example might be: News/agent/nntp/news.gmane.org/gmane/comp/lang/perl/beginners/ I want to skip any files that have all numbers for names which would be under the last directory above. However there are at

Hello, I have a dir ~/Maildir where all my mails get distributed to their respective folders through procmail filters. The heirarchy is as follows: ~/Maildir/ /inbox --> maildir /trash --> maildir /newsletter --> mbox lists/ --> normal dir /dovecot --> dovecot list maildir /some other list maildirs I need

Thanks, Shu, I guess I haven't updated since my post went out. There are actually 2 problems: 1. mis-compilation: My LLVM-2.5 turned out to be mis-compiled using gcc-4.4.0 (surprise to me) on Debian4-32b. I tried a few different compilers, and gcc-4.0.4 (a relatively old one, again surprised me) seems to work out fine. Question: is there a good/quick/reliable way to figure out whether a

Hi, Michael Tsirkin pointed out issues w.r.t various locking related TODO items and races w.r.t device removal. In this first round of cleanups, I have taken care of most pressing issues. These patches apply on top of following. git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v4 I have tested these patches with mount/umount and device removal using qemu monitor. For

On Mon, Jan 16, 2017 at 03:04:33PM +0100, Cornelia Huck wrote: > From: Bhumika Goyal <bhumirks at gmail.com> > > Declare virtio_config_ops structure as const as it is only stored in the > config field of a virtio_device structure. This field is of type const, so > virtio_config_ops structures having this property can be declared const. > Done using Coccinelle: > >

On Mon, Jan 16, 2017 at 03:04:33PM +0100, Cornelia Huck wrote: > From: Bhumika Goyal <bhumirks at gmail.com> > > Declare virtio_config_ops structure as const as it is only stored in the > config field of a virtio_device structure. This field is of type const, so > virtio_config_ops structures having this property can be declared const. > Done using Coccinelle: > >

Declare target_core_fabric_ops strucrues as const as they are only passed as an argument to the functions target_register_template and target_unregister_template. The arguments are of type const struct target_core_fabric_ops *, so target_core_fabric_ops structures having this property can be declared const. Done using Coccinelle: @r disable optional_qualifier@ identifier i; position p; @@

Declare target_core_fabric_ops strucrues as const as they are only passed as an argument to the functions target_register_template and target_unregister_template. The arguments are of type const struct target_core_fabric_ops *, so target_core_fabric_ops structures having this property can be declared const. Done using Coccinelle: @r disable optional_qualifier@ identifier i; position p; @@

On Thu, Sep 05, 2019 at 03:48:57PM -0400, Vivek Goyal wrote: > It is possible that a mount is in progress and device is being removed at > the same time. Use virtio_fs_mutex to avoid races. > > This also takes care of bunch of races and removes some TODO items. > > Signed-off-by: Vivek Goyal <vgoyal at redhat.com> > --- > fs/fuse/virtio_fs.c | 32

On Thu, Sep 05, 2019 at 03:48:57PM -0400, Vivek Goyal wrote: > It is possible that a mount is in progress and device is being removed at > the same time. Use virtio_fs_mutex to avoid races. > > This also takes care of bunch of races and removes some TODO items. > > Signed-off-by: Vivek Goyal <vgoyal at redhat.com> > --- > fs/fuse/virtio_fs.c | 32

I have been at Microsoft the last couple of days and so couldn't join the discussion earlier. Here's my view of the name issue, and (the reason this is long), a little about how I think we want users to view this tool: First, I think the name should convey the purpose of the tool -- otherwise, it just creates a confusing acronym (and goodness knows we have enough names already, even

Here are two things that need to be done. 1. Generate Referreal URL''s for users. -- people will signup and a referral URL will be generated for them, which they can share 2. Track those referral URL''s -- I will have to track performance of each referral URL How can go about doing this using Rails 3.1 -- You received this message because you are subscribed to the Google

Hi Miklos, Here are few small cleanups for virtiofs for 5.5. I had received some comments from Michael Tsirkin on original virtiofs patches and these cleanups are result of these comments. Thanks Vivek Vivek Goyal (3): virtiofs: Use a common function to send forget virtiofs: Do not send forget request "struct list_head" element virtiofs: Use completions while waiting for queue

On Tue, Aug 03, 2004 at 12:26:50PM -0500, Brian Gaeke wrote: > > On Mon, Aug 02, 2004 at 06:05:16PM -0700, Reid Spencer wrote: > > > On Mon, 2004-08-02 at 18:04, Chris Lattner wrote: > > > llvmcd - llvm compiler driver > > > llvmci - llvm compiler invoker > > > llvmcs - llvm compiler system (or perhaps "compilation system") > > > llvmct

On Thu, Sep 05, 2019 at 03:48:49PM -0400, Vivek Goyal wrote: > +static void virtio_fs_drain_queue(struct virtio_fs_vq *fsvq) > +{ > + WARN_ON(fsvq->in_flight < 0); > + > + /* Wait for in flight requests to finish.*/ > + while (1) { > + spin_lock(&fsvq->lock); > + if (!fsvq->in_flight) { > + spin_unlock(&fsvq->lock); > + break; > + }

On Thu, Sep 05, 2019 at 03:48:49PM -0400, Vivek Goyal wrote: > +static void virtio_fs_drain_queue(struct virtio_fs_vq *fsvq) > +{ > + WARN_ON(fsvq->in_flight < 0); > + > + /* Wait for in flight requests to finish.*/ > + while (1) { > + spin_lock(&fsvq->lock); > + if (!fsvq->in_flight) { > + spin_unlock(&fsvq->lock); > + break; > + }

On Thu, Sep 05, 2019 at 03:48:56PM -0400, Vivek Goyal wrote: > This object is used both by fuse_connection as well virt device. So make > this object reference counted and that makes it easy to define life cycle > of the object. > > Now deivce can be removed while filesystem is still mounted. This will > cleanup all the virtqueues but virtio_fs object will still be around and