search for: canthrow

from http://llvm.org/docs/LangRef.html: nounwind > This function attribute indicates that the function never raises an > exception. If the function does raise an exception, its runtime behavior is > undefined. However, functions marked nounwind may still trap or generate > asynchronous exceptions. Exception handling schemes that are recognized by > LLVM to handle asynchronous

> On Feb 8, 2017, at 12:58 PM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I think this behavior is intended to allow better LTO between C and C++. Consider this kind of code: > > // foo.h > extern "C" int doThing(bool canThrow); > // foo.cpp > int doThing(bool canThrow) { > ... > if (hadError) { > if (canThrow) throw MyException; else return -1; > } > } > // bar.c > #include "foo.h" > void f() { > doThing(false); // don't declare doThing as nounwind > } > /...

...is that if the compiler (or the user) determined that the function cannot throw, we have the NOUNWIND attribute which is not orthogonal with either exception support. Despite this we should still emit the unwind entry for the EXIDX_CANTUNWIND value, which is always done. Another issue is that canThrow (!NoUnwind) is set by default. Setting NoUnwind is an optimisation which is not handled by the ARM Streamer. A first approach was to have the backend return needsUnwindTableEntry() false if noexception support, but unwind tables can be used without exception handler (e.g) for debug infos or C u...