search for: __builtin_trap

Hi Zoltan, We've come across this before where people meant to induce a trap by dereferencing a null. It doesn't work for LLVM (as you found out). Essentially, it's a valid transformation to turn this into unreachable. The better solution is to use something like __builtin_trap. -bw On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote: > > Hi, > > Currently, llvm treats the loads from a null address as > unreachable code, i.e.: > load i32* null > is transformed by some optimization pass into > u...

...i Zoltan, > > We've come across this before where people meant to induce a trap by > dereferencing a null. It doesn't work for LLVM (as you found out). > Essentially, it's a valid transformation to turn this into unreachable. The > better solution is to use something like __builtin_trap. > > -bw > > > On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote: > > >> Hi, >> >> Currently, llvm treats the loads from a null address as unreachable code, >> i.e.: >> load i32* null >> is transfo...

...e official position on continuing from a debug trap, but I think that without that ability, the concept would be pretty useless. A quick example <https://godbolt.org/z/-8voBz> shows that clang produces the "expected" output even at -O3. In fact, on aarch64, __builtin_debugtrap() and __builtin_trap() produce the same instruction, and the only difference between them is that the latter also triggers DCE of everything coming after it. pl

Hi, Currently, llvm treats the loads from a null address as unreachable code, i.e.: load i32* null is transformed by some optimization pass into unreachable This presents problems in JIT compilers like mono which implement null pointer checks by trapping SIGSEGV signals. It also looks incorrect since it changes program behavior, which might be undefined in general, but it is quite

...gt;> We've come across this before where people meant to induce a trap by >> dereferencing a null. It doesn't work for LLVM (as you found out). >> Essentially, it's a valid transformation to turn this into unreachable. The >> better solution is to use something like __builtin_trap. >> >> -bw >> >> On Sep 5, 2009, at 2:19 PM, Zoltan Varga <vargaz at gmail.com> wrote: >> >>> >>>                Hi, >>> >>>  Currently, llvm treats the loads from a null address as unreachable >>> code, i.e.: >>...

On 4/5/2013 1:23 PM, Cameron McInally wrote: > Hey guys, > > I'm learning that LLVM does not preserve faults during constant > folding. I realize that this is an architecture dependent problem, but > I'm not sure if it's safe to constant fold away a fault on x86-64. > > A little testcase: > > #include <stdio.h> > > int foo(int j, int d) { >

Hey guys, I'm learning that LLVM does not preserve faults during constant folding. I realize that this is an architecture dependent problem, but I'm not sure if it's safe to constant fold away a fault on x86-64. A little testcase: #include <stdio.h> int foo(int j, int d) { return j / d ; } int bar (int k, int d) { return foo(k + 1, d); } int main( void ) { int r =

...ersion of -enable-unsafe-fp-math or gfortran's -ffpe-trap. More accurately, this hypothetical option would suppress the folding of unsafe integer expressions altogether. Would an option such as this benefit the community at large? To be complete, I've also explored the idea of generating a __builtin_trap() call for such expressions before the IR level. However, I have not yet convinced myself that this will generate the same fault as the actual sdiv/udiv instruction would. Things to do. -Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.o...

Hi, I'm noticing an unexpected difference between targets when I hit a dbgtrap in the debugger. Consider this simple llvm function: define void @do_break() { entry: call void @llvm.debugtrap() ret void } If I compile that with llc and use lldb to launch a program that calls it, on x86_64 linux (Ubuntu 18.04), here's what I see at the stop: Process 130404 stopped * thread #1,