search for: always_false

...ptr[0] = 10 is propagated into one copy of maybe_devide (in > source a), and ptr[0]=10 in caller_a is DSEed ? `ptr[0] = 10` is not really propagated anywhere. What happens is that `source-a` 's copy of `maybe_divide` gets optimized to a `ret (unsigned) ptr` (after inlining in the body of `always_false`)[1], so it is able to DSE the store `ptr[0] = 10`. But `source-b` s copy of `maybe_divide` still has the load and the division (since it does not have access to `always_false` 's body), so if `caller_a` ends up calling that implementation of `maybe_divide`, we get a `SIGFPE`. [1]: For refere...

So in this case, ptr[0] = 10 is propagated into one copy of maybe_devide (in source a), and ptr[0]=10 in caller_a is DSEed ? David On Sat, Feb 27, 2016 at 1:41 PM, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Just as a reality check, I wrote up a demonstration where one link > order causes a SIGFPE and another doesn't (and the program is well > defined, as

...to one copy of maybe_devide > (in > > source a), and ptr[0]=10 in caller_a is DSEed ? > > `ptr[0] = 10` is not really propagated anywhere. What happens is that > `source-a` 's copy of `maybe_divide` gets optimized to a `ret > (unsigned) ptr` (after inlining in the body of `always_false`)[1], so > it is able to DSE the store `ptr[0] = 10`. But `source-b` s copy of > `maybe_divide` still has the load and the division (since it does not > have access to `always_false` 's body), so if `caller_a` ends up > calling that implementation of `maybe_divide`, we get a `SIGFP...

...d into one copy of maybe_devide (in > > source a), and ptr[0]=10 in caller_a is DSEed ? > > `ptr[0] = 10` is not really propagated anywhere. What happens is that > `source-a` 's copy of `maybe_divide` gets optimized to a `ret > (unsigned) ptr` (after inlining in the body of `always_false`)[1], so > it is able to DSE the store `ptr[0] = 10`. But `source-b` s copy of > `maybe_divide` still has the load and the division (since it does not > have access to `always_false` 's body), so if `caller_a` ends up > calling that implementation of `maybe_divide`, we get a `SIGFP...

On Mon, Jul 11, 2016 at 2:28 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > ping! > > Sanjoy Das wrote: > # Proposed Solution: >> >> We introduce a "new" LLVM type. I will still refer to it as GCREF >> here, but it may actually still be "<ty> addrspace(k)*" where k is >> specially noted in the datalayout. >>