search for: pr965

...hich produces an infinite loop, or perhaps lead to a stack overflow (as > GCC might produce)... it's alright if the infinite loop is written using > tail-calls. All I expect is that it never actually return when you run it. this sounds like a manifestation of bug 965, see http://llvm.org/PR965 Ciao, Duncan.

...infinite loop, or perhaps lead to a stack overflow (as >> GCC might produce)... it's alright if the infinite loop is written using >> tail-calls. All I expect is that it never actually return when you run it. > > this sounds like a manifestation of bug 965, see http://llvm.org/PR965 ah, you are quite right! I'd searched "recursion" to look for bugs, but the problem (as described in #965) is more general than that. (I'm quite familiar with Haskell, in which termination vs. nontermination is discussed much more than it is in C.) The optimization and the...

I tried the LLVM demo with unmodified settings http://llvm.org/demo/index.cgi (same results from llvm 2.6 with clang, `clang-cc -emit-llvm -O2 test.c`, on my Linux x86_64) For fun, I made a recursive function, but LLVM optimized it wrong (if I'm understanding C standards correctly). "void f() { f(); }"[see llvm-code in footnote 1] was optimized to be equivalent to "void f()

...nst)) on the declaration will add those llvm attributes if you're using llvm-gcc or clang to generate this llvm assembly. Note that there doesn't seem to be a function attribute to say "this function won't go into an infinite loop" though, which I guess means http://llvm.org/PR965 hasn't been fixed yet.

> only if the compiler can prove that the called function has > no side effects (such as modifying some global variables or > causing the program to exit). can it prove if the function resides in a shared library? -- View this message in context: http://old.nabble.com/DCE-and-external-function-tp29932485p29942236.html Sent from the LLVM - Dev mailing list archive at Nabble.com.