search for: noreturns

Hi, Building the following C code I get a call instruction that has no noreturn attribute, while the function itself does have it. void foo(void **b) { __builtin_longjmp(b, 1); } define void @_Z3fooPPv(i8** %b) noreturn nounwind uwtable { entry: %0 = bitcast i8** %b to i8* tail call void @llvm.eh.sjlj.longjmp(i8* %0)

Hi all, Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths. While I don’t necessarily think it’s ideal to ignore all noreturn decls, I think there’s definitely room for some heuristics around ignoring things like llvm_unreachable (perhaps opt-in?). I’m

You can use CallInst::hasFnAttr(). It checks for attributes in the instruction and in the function decl. http://llvm.org/docs/doxygen/html/Instructions_8cpp_source.html#l00345 Nuno ----- Original Message ----- > Hi, > > Building the following C code I get a call instruction that has no > noreturn > attribute, while the function itself does have it. > > void foo(void **b)

Dear all, I don't get how llvm handles functions with __attribute__((noreturn)). It seems that LR register is backed up on the stack whilst it will never be used to return from a 'noreturn' function. I have this problem with a home-made backend but it seems that ARM flavour of clang has same behaviour. By the way, SP is also saved, I don't understand why. Is there a syntax error

+ cfe-dev > On Mar 28, 2016, at 1:23 PM, Harlan Haskins via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths. FWIW, Daniel Dunbar and a few others have brought up the lack of a

Hi Kostya, On 28/11/12 14:47, Kostya Serebryany wrote: > Hi, > > Building the following C code I get a call instruction that has no noreturn > attribute, while the function itself does have it. > > void foo(void **b) { > __builtin_longjmp(b, 1); > } > > > define void @_Z3fooPPv(i8** %b) noreturn nounwind uwtable { > entry: > %0 = bitcast i8** %b to i8*

Hello, as of gcc v2.7.2.1, the noreturn attribute needs to be given *after* the prototype declaration and not before, but for gcc v3.x, things changed for this attribute again, since gcc v2.5.x did it the way, newer gcc versions prefer it... I've applied a small unified diff, fixing this stuff. THX for listening. CU Tom. (Thomas M.Ott) Germany -------------- next part -------------- ---

Hello, I am not sure about the semantic (if any) of returns_twice and noreturn attributes. int fork() __attribute__((returns_twice)); void join(int) __attribute__((noreturn)); int f(int n) { int t = fork(); n++; if (t != 0) join(t); return n; } Produces the following LLVM IR: ; Function Attrs: nounwind uwtable define i32 @f(i32 %n) local_unnamed_addr #0 { entry: %call = call i32

On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: > > Hello, > > I am not sure about the semantic (if any) of returns_twice and noreturn > attributes. > > int fork() __attribute__((returns_twice)); > void join(int) __attribute__((noreturn)); > > int f(int n) { > int

I am compiling some code with Clang which needs to jump to a fixed address to perform a "syscall". These fixed addresses contain valid code. I noticed that this code produces a warning: typedef void (*exit_syscall_type) (int status) __attribute__((noreturn)); void _exit(int status) __attribute__ ((noreturn)); void _exit(int status) { ((exit_syscall_type)0x10000)(status); } This

Hi Keir: I spotted some bogus uses of the noreturn keyword on ia64. [IA64]: noreturn cannot be used if function may return The functions die_if_kernel and vmx_die_if_kernel can certainly return. This disqualifies them from using the noreturn keyword which is reserved for functions that never return. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cheers, -- Visit Openswan at

Guys, I would like to instrument the bytecode that LLVM produces with assertions. I have written the instrumentation code manually, but I do not know how to halt the program in case the assertion is false. I took a look into the bytecode that LLVM produces for a program like: #include <stdlib.h> int main() { exit(1); } And it is like this: define i32 @main() nounwind { entry:

This happens with GCC 7.0.1. The errors were all of the form: qemu-speed-test.c: In function 'main': qemu-speed-test.c:153:7: error: this statement may fall through [-Werror=implicit-fallthrough=] usage (EXIT_SUCCESS); ^~~~~~~~~~~~~~~~~~~~ qemu-speed-test.c:155:5: note: here default: ^~~~~~~ --- builder/index-validate.c | 2 +-

Hi All, I have a program that uses C++ STL a lot. To have the source code for STL functions, I undefined "_GLIBCXX_EXTERN_TEMPLATE" in c++config.h. In spite of this, after compilation (via clang) and linking (via llvm-ld), the resulting bitcode contains a few declared functions (with no definitions). My question is: In the scenario where some function definitions are missing in a llvm

hi, list, i am making a llvm compiler for shader-like programs. as we known, shader programs are short and have less function calls. i found that i have to save/restore callee-saved register(CSR) in prolog and epilog. because I can violate ABI from driver(c code) and shader, i plan to append the attribute 'noreturn' to all shader functions. in PrologEpilogInserter.cpp, you can find that

During the review of https://reviews.llvm.org/D59978 we got to the question whether we can optimize based on the assumption that stack overflow is undefined behavior. While I think it is according to the C++ standard, Windows Structured Exception Handling and signal handlers might allow programs to recover/exit gracefully. Concretely, the patch D59978 wants add the noreturn attribute to functions

> If there's sensible control flow after a function returns, don't mark > it or calls to it noreturn. How do I prevent llvm-gcc from labelling a particular function with the noreturn attribute so an unreachable is not inserted after a call to it? Does llvm-gcc keep a list of functions somewhere that it thinks do not return? Max On Tue, Sep 8, 2009 at 10:30 PM, Eli Friedman

When I compile some code with the near-trunk clang++ I get this: ... tail call void @_Unwind_Resume_or_Rethrow(i8* %exn2) noreturn unreachable ... declare void @_Unwind_Resume_or_Rethrow(i8*) ... Same with __cxa_throw. 'noreturn' is missing on declarations. This seems to be a bug. Also can _Unwind_Resume_or_Rethrow actually return? When I run some simple exception code in JIT I

Victor Campos wrote: > Guys, > > I would like to instrument the bytecode that LLVM produces with > assertions. I have written the instrumentation code manually, but I do > not know how to halt the program in case the assertion is false. I took > a look into the bytecode that LLVM produces for a program like: > > #include <stdlib.h> > int main() { >

Hi Nadav, > I almost missed your email because you replied only to the list. I understand your argument. I think that my fix addresses a part of it. It says that instructions that do not return should not be removed. > The current implementation of mayReturn is to check the 'noreturn' function attribute. Are you suggesting to add a new attribute that is called 'mustreturn'