search for: trappability

...>> >> >> 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 adding explicit support for trappability to load/store. -Chris

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

...t; 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 adding > explicit support for trappability to load/store. This won't free the optimizer to treat null as an invalid pointer though. Some LLVM hacker thought it would be a good idea to use address spaces 256 and 257 on x86 in a way that can require dereferences of address 0 to be valid. Dan

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

On 04/29/2014 10:44 AM, Filip Pizlo wrote: > LD;DR: Your desire to use trapping on x86 only further convinces me > that Michael's proposed intrinsics are the best way to go. I'm still not convinced, but am not going to actively oppose it either. I'm leery of designing a solution with major assumptions we don't have data to backup. I worry your assumptions about