search for: disentangling

On Wed, 10 Feb 2016 14:08:43 +0100 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > But you are right, there is a bug: we should rollback if vhost_init_used() > fails. Something like below: > > err_used: > vq->private_data = oldsock; > vhost_net_enable_vq(n, vq); > + vhost_adjust_vring_endian(vq); Shouldn't we switch back before we

On Wed, 10 Feb 2016 14:08:43 +0100 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > But you are right, there is a bug: we should rollback if vhost_init_used() > fails. Something like below: > > err_used: > vq->private_data = oldsock; > vhost_net_enable_vq(n, vq); > + vhost_adjust_vring_endian(vq); Shouldn't we switch back before we

The way vring endianness is being handled currently obfuscates the code in vhost_init_used(). This patch tries to fix that by doing the following: - move the the code that adjusts endianness to a dedicated helper - export this helper so that backends explicitely call it No behaviour change. Signed-off-by: Greg Kurz <gkurz at linux.vnet.ibm.com> --- drivers/vhost/net.c | 3 +++

On Wed, 10 Feb 2016 13:48:09 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Wed, Jan 13, 2016 at 06:09:47PM +0100, Greg Kurz wrote: > > The way vring endianness is being handled currently obfuscates > > the code in vhost_init_used(). > > > > This patch tries to fix that by doing the following: > > - move the the code that adjusts

On Wed, Jan 13, 2016 at 06:09:47PM +0100, Greg Kurz wrote: > The way vring endianness is being handled currently obfuscates > the code in vhost_init_used(). > > This patch tries to fix that by doing the following: > - move the the code that adjusts endianness to a dedicated helper > - export this helper so that backends explicitely call it > > No behaviour change. >

On Wed, Jan 13, 2016 at 06:09:47PM +0100, Greg Kurz wrote: > The way vring endianness is being handled currently obfuscates > the code in vhost_init_used(). > > This patch tries to fix that by doing the following: > - move the the code that adjusts endianness to a dedicated helper > - export this helper so that backends explicitely call it > > No behaviour change. >

On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <kcc at google.com> wrote: > Then my question: will there be any objection if I disentangle AsanCoverage from ASan and make it a separate LLVM phase with the proper clang driver support? > Or it will be an unwelcome competition with the planned clang coverage? I don’t view it as a competition, but assuming that we both succeed in our

Hi there, I have following equations to be solved for a and b: a/(a+b) = x1 ab/((a+b)^2 (a+b+1)) = x2 Is there any direct function available to solve them without disentangling them manually? Thanks for your help.

> On Jul 19, 2016, at 09:52, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The IR disruptions for CHERI aren’t that major (the main thing is that we allow alloca’s in different address spaces, but that’s not too difficult to upstream), but it does fail to tick one box that you didn’t list: We would like this feature upstreamed -Matt -------------- next part

Hi David, On Wed, Feb 12, 2014 at 5:22 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 12 Feb 2014, at 13:21, Alexey Samsonov <samsonov at google.com> wrote: > > > On Wed, Feb 12, 2014 at 4:56 PM, David Chisnall < > David.Chisnall at cl.cam.ac.uk> wrote: > >> Are you going to move the unwind library there as part of the >

Regarding performance, I've made a simple coverage with counters and compared it with AsanCoverage. AsanCoverage produces code like this: mov 0xe86cce(%rip),%al test %al,%al je 48b4a0 # to call __sanitizer_cov ... callq 4715b0 <__sanitizer_cov> A simple counter-based thing (which just increments counters and does nothing else useful) produces this: incq 0xe719c6(%rip) The

...(where beta_1.hat is specific to the particular level of `a' being considered). If I am not mistaken. (Please correct me if I am!) But in the logistic model, everything is entangled in the inverse link function (the ``expit'' function as it is called by some), and I can see no way of disentangling. Is there any way of getting at this? I figure that simulation/Monte Carlo inference/ parametric bootstrapping would provide a workaround, but before I go that route, can anyone point me to a simpler method? There wouldn't be anything built into R or an R package, would there? (I did...

On Tue, Feb 18, 2014 at 10:15 PM, Bob Wilson <bob.wilson at apple.com> wrote: > Our instrumentation code is basically done now, so you can try it out and > compare the performance. Just build with -finstr-profile-generate. > Is this in trunk? clang-3.5: error: unknown argument: '-finstr-profile-generate' --kcc > You may want to hack the compiler-rt code in

TL;DR: See subject. That is all. ---- First off, I want to say I'm sorry for doing this. =/ There were several issues that led to this: 1) There were several micro-design problems with the APIs as implemented in the core libraries of LLVM. These then fanned out to all the uses of these libraries making fixing these issues challenging as well. The fixes were also not happening in a timely

Folks, Finally, Syslinux 5.10 has been released. This release includes a merge of the 4.10 development branch, which means that there's a new network stack availble, based on the lwIP embedded TCP/IP stack. The jump from the previous 5.01 release to 5.10 may be a little confusing, but a new network stack is such a large change that it deserved a significant bump in the version minor number.

Hi all, Thanks to everyone's hard work over the last few months, the last child of the AArch64/ARM64 merge issue (http://llvm.org/PR19392) has just been resolved. So I think it's time to finish the job. I'd like to delete the AArch64 target and move ARM64 into its place: for now we'll accept both aarch64 and arm64 triples in all places, and they will all be redirected to the

...r" seems to better indicate the intention. Also, in the same place, I think "don't inherit from ExecutionEngine" is a potentially misleading comment, since that's the class that clients actually use to interface with MCJIT. It would probably be better to say something about disentangling the JIT and MCJIT interfaces and specifically mention that we don't want the base class to manage our modules. Keep in mind, however, that in addition to JIT and MCJIT, there's also the Interpreter class which inherits from ExecutionEngine. There are a few very basic multiple module tests...

On Feb 12, 2014, at 11:43 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Thu, Feb 13, 2014 at 11:10 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <kcc at google.com> wrote: > >> Hi, >> >> Justin is making nice commits for llvm-cov, so I thought we may continue this

# HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1324385575 -3600 # Node ID 716d6d48e647d1d4352f7206e74e693152a4f8fa # Parent f72b99fccfca694674259cc1c03c526a827b67ec libxl: add support for yajl 2.x This patch adds support for yajl versions 2.x, while retaining 1.x compatibility. This patch adds quite a lot of #ifdefs all over the json code, so I''m open

Hi Andy, Here is the patch. it incorporates: 1) your latest patch to SVN. 2) mcjit-module-state-optimization.patch. 3) the PtrSet changes. Other than the OwnedModules implementation there were other differences between 1) and 2), especially in the Finalize* functions, so please review that I got the right code. I got bitten by subtle bugs arising from MCJIT inheriting from EE: First, MCJIT