similar to: [RFC] Stack overflow and optimizations

Hi Michael, Please keep in mind non-C/C++ frontends. For example, in Rust, we promise to avoid all undefined behavior in safe code. There is no reasonable compositional analysis that can statically detect stack overflows (I know safety-critical systems are subjected such analyses, but those could not reasonably be enforced on all Rust code -- most of them just forbid recursion, for example), so

Hello, I plan to implement "Stack Smashing Protection - Strong" support in LLVM. Below is a description of this feature and an overview of the implementation plan. I have divided up the implementation into stages that can be delivered incrementally. I'm looking for any feedback (suggestions, requests, etc) before I actually begin the work. Thank you! Josh

Hey everyone, I felt this question is different from my other question - hope this is okay. So - I was playing around with the lookup function of the ExecutionSession and there are some things I don't understand. I have a .BC file with a function "?Sampler@@YAXXZ" referencing a value "?_Plansch_test@@3HA" that is not defined in that module itself. I first planed on not

+ 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

On Friday 13 November 2009 16:26:01 Chris Lattner wrote: > On Nov 13, 2009, at 3:34 AM, Jon Harrop wrote: > >> Point 4 is the one that caused me trouble for some time. > >> Unfortunately > >> it causes a bad interaction with the optimiser, specifically the > >> 'simplifycfg' pass. What seems to happen is that since the function > >> you are

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)

Hey Lang, Thank you for your help and your patience – also for your answers in the “ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup” mail. Both problems have the same origin so I keep writing about it here, to avoid duplication. My big problem is still handling cross references between modules with “our” name scheme. Since our old

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

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)

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

On Nov 13, 2009, at 9:07 AM, Jon Harrop wrote: > > I'll try removing the noalias and seeing if that fixes it. If so, I'll file a > bug report. Which part of LLVM would this be a bug in if things like noalias > and noreturn inhibit TCO when they shouldn't? CodeGen. I looked at noalias, and it was indeed a bug. This is now fixed on trunk in r88672. Noreturn is 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*

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

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

> 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

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 -------------- ---

Hey Lang, > Do you mean that the object file is produced by another process and is being loaded into your JIT process for execution, or that you want your JIT to produce code for several different processes? These are different problems with different solutions. I'll wait until I understand your use case to answer further. In the current state we don’t have a JIT only an handcrafted object

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:

On Fri, Jul 15, 2016 at 2:44 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > Don't we have the same problems for "exit(0)" > > > > > > This is a noreturn call, so yes, iit has another hidden control > > flow-side-effect of a slightly different kind. GCC models it as an extra >