search for: trappabl

On Jul 22, 2009, at 1:32 PM, Dan Gohman wrote: >>> >>> - A null pointer is associated with no addresses. >>> >> >> A null pointer in address space 0. > > I'm not fond of weird address-space semantics, but for consistency > with what the optimizer is currently doing, you're right. FWIW, this will be addressed when we finally get around to

On Jul 22, 2009, at 12:56 PM, Eli Friedman wrote: > On Wed, Jul 22, 2009 at 11:30 AM, Dan Gohman<gohman at apple.com> wrote: > >> - The result value of an allocation instruction is associated with >> >> the address range of the allocated storage. >> > > Might want to clarify this to include calloc/realloc. These sort of fall under the category of

On Jul 22, 2009, at 5:23 PM, Chris Lattner wrote: > > On Jul 22, 2009, at 1:32 PM, Dan Gohman wrote: > >>>> >>>> - A null pointer is associated with no addresses. >>>> >>> >>> A null pointer in address space 0. >> >> I'm not fond of weird address-space semantics, but for consistency >> with what the optimizer is

Hi All, as I can see on https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L53 the?Rack::CommonLogger used only in development env and in weird evn called "deployment". Any chance to add "production" to this case? Serg Podtynnyi

This week has been very productive and has shown a huge leap forward in Asterisk development. The creation of the new concepts of an "unstable" branch of the code will, I believe, make for a better development environment in the long run. With that in mind, I'm going to do something I only infrequently do, which is to re-post something in it's entirety and look for comments

Hi, I am currently working on hypercalls from HVM guests. I started with a set of Intel patches posted to xen-devel last September. I currently have code running for both 32-bit and 64-bit HVM guests running on a 64-bit hypervisor. I am curious why none of the original patches were accepted, and what I might need to do to make them acceptable. Is other work being done in this area that

As the discussion has progressed and I've spent more time thinking about the topic, I find myself less and less enthused about the current proposal. I'm in full support of having idiomatic ways to express safe division, but I'm starting to doubt that using an intrinsic is the right way at the moment. One case I find myself thinking about is how one would combine profiling

...hink. (I reserve the right to change my mind later...) > > Notice that the proposed intrinsics are *the best* way of achieving > this, once we have a way of optimizing such branches. The LLVM > backend will know that the i1's returned from the safe.div intrinsic > are "trappable" on x86, and the frontend can arrange to weight the > branches on those i1's appropriately if it wants a trap-based > implementation. Better yet, the frontend could simply feed whatever > profiling it wants ("I saw the corner case X times and the main case Y > times&...