search for: fcatch

...7:48 PM, Richard Smith wrote: > Hi, > > There are three different (and mostly orthogonal, design-wise) areas where I would like to make improvements to Clang's undefined behavior checking: > > 1) Completeness of checks. There are integer undefined behaviors which -ftrapv and -fcatch-undefined-behavior don't catch, and there is almost no checking available for any other undefined behaviors outside of those and the ones caught by {Address,Thread,Memory} Sanitizer. > > I would like to add support for checking the following additional undefined behaviors, which Clang do...

...in() { void *p; f((uint64_t*)&p); } ------------------------------------ and it correctly catches the invalid access. If I comment the attribute, the optimizers find and exploit the undefined behavior and asan fails to report it. Is this the expected behavior? Is this something that needs -fcatch-undefined-behavior instead? Cheers, Rafael

> Indeed, but can't an analysis find at least one value for each variable > where the behavior is not undefined? > Such a value must exist, or the entire function is useless if it always > has undefined behavior. Good point :). > Sure, testing on 1 such value (or a random) value won't prove that the > result is correct, but may help finding trivial > miscompilations

...'t have time to do this kind of code > inspection myself. Makes sense. > > There has been talk (I don't remember where) about a Clang option for > detecting undefined behavior. Is there any progress on this? This > could be used to enable automated random testing. *Yes, -fcatch-undefined-behavior. http://clang.llvm.org/docs/UsersManual.html#codegen * Best regards, --Edwin

Patch and documentation can be found here: http://embed.cs.utah.edu/ubc/ John

On Apr 8, 2011, at 8:27 AM, John Regehr wrote: > Patch and documentation can be found here: > > http://embed.cs.utah.edu/ubc/ It seems that this could be merged into -fcatch-undefined-behavior while separating mechanism from policy: 1) Adding checks for more undefined behavior. 2) Allowing different choices of trap mechanism when undefined behavior is encountered. Cameron

...eople who really care, but "exploiting" > undefined behavior just for the sake of breaking code is a non-goal. > Also, as a bit of a teaser, I think Richard Smith is going to be looking into providing much more extensive optional *checking* of undefined behavior. Essentially, '-fcatch-undefined-behavior' may grow some serious teeth. This should allow users to check their code fairly aggressively for UB but not needlessly punish code or those debugging code. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llv...

...amp;p); > } > ------------------------------------ > > and it correctly catches the invalid access. If I comment the > attribute, the optimizers find and exploit the undefined behavior and > asan fails to report it. Is this the expected behavior? Is this > something that needs -fcatch-undefined-behavior instead? For performance reasons, asan runs at the end of the optimization pipeline, so it doesn't check loads which get removed by the IR optimizers. -Eli

...------------------------------- > > > > and it correctly catches the invalid access. If I comment the > > attribute, the optimizers find and exploit the undefined behavior and > > asan fails to report it. Is this the expected behavior? Is this > > something that needs -fcatch-undefined-behavior instead? > > For performance reasons, asan runs at the end of the optimization > pipeline, so it doesn't check loads which get removed by the IR > optimizers. > > -Eli > > _______________________________________________ > LLVM Developers mailing lis...

...-- > > > > and it correctly catches the invalid access. If I comment the > > attribute, the optimizers find and exploit the undefined > behavior and > > asan fails to report it. Is this the expected behavior? Is this > > something that needs -fcatch-undefined-behavior instead? > > For performance reasons, asan runs at the end of the optimization > pipeline, so it doesn't check loads which get removed by the IR > optimizers. > > -Eli > > _______________________________________________ > LLV...

...Clang to directly pass options down to the LLVM layer. Also, it indicates the asan functionality defaults to on. Ideally all of this functionality would default to off, and be enabled via '-fasan' or even better '-faddress-sanitizer' in Clang. That would match the behavior of '-fcatch-undefined-behavior', '-fmudflap', etc. If you want to expose the more fine grained flags to users that are mentioned on the wiki page, they could also have '-f...' Clang flags, but it seems unlikely that those are important. What's your expected plan for the runtime librar...

I am working on a program which links with the FTDI USB driver (ftd2xx.dylib). Prior to a couple of hours ago I had only worked with Debug builds of my code (no compiler optimizations). In testing a production build, I found that using anything other than -O0 results in the FTDI driver returning bad data; just a lot of zeroes. I tested and re-tested to make sure that changing just that one option

On Jan 20, 2010, at 12:49 PM, John Regehr wrote: > > There has been talk (I don't remember where) about a Clang option for > detecting undefined behavior. Is there any progress on this? This > could > be used to enable automated random testing. -fcatch-undefined-behavior: http://clang.llvm.org/docs/UsersManual.html#codegen Right now it only catches out of range shifts and simple array out of bound issues, not all undefined behavior. -Chris

http://blog.regehr.org/archives/761 Thanks, John

On Jul 26, 2012, at 9:58 AM, John Regehr wrote: > http://blog.regehr.org/archives/761 It's an interesting post, but I'd like to point out that it is a non-goal for the project to be actively hostile to users of the compiler. :) It is useful to have debugging tools for people who really care, but "exploiting" undefined behavior just for the sake of breaking code is a

...ctionality would default to off, and be enabled via > '-fasan' or even better '-faddress-sanitizer' in Clang. > That's what I have now (-fasan). I slightly prefer -fasan over -faddress-sanitizer because the former is shorter. > That would match the behavior of '-fcatch-undefined-behavior', '-fmudflap', > etc. If you want to expose the more fine grained flags to users that are > mentioned on the wiki page, they could also have '-f...' Clang flags, but it > seems unlikely that those are important. > I will probably need a few more u...

Hi all, I'm trying to write a tool for detecting undefined behavior in C regarding sequence points and side effects. I'm not sure whether it should be a Clang plugin or LLVM run or something completely different (I'm really new to both Clang and LLVM) and that's what I need advice with. For my work, I need to use both AST and alias analysis Clang plugin: +relatively easy to

On Tue, Jul 26, 2011 at 10:20 AM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 21, 2011, at 8:05 AM, Kostya Serebryany wrote: > > > Hi, > > What would be our next steps in getting ASan into the LLVM trunk? > > I'd like to do it in two steps, first for the LLVM part with minimal > tests and then for the run-time library and all tests. > >

On Jun 21, 2011, at 8:05 AM, Kostya Serebryany wrote: > Hi, > What would be our next steps in getting ASan into the LLVM trunk? > I'd like to do it in two steps, first for the LLVM part with minimal tests and then for the run-time library and all tests. > The current ASan's source repository will probably stay the primary home for the run-time library and tests as we plan

Hello, I have tried a lot fix this error but am not able to can you please find me a solution am trying to compile the SAFECode in Cygwin Environment to work for windows. used make -j4 command to make the files in cygwin i have got this error make[5]: Leaving directory '/home/uidr7475/Work/LLVM_OBJ/projects/safecode/tools/clang/include' /usr/bin/cp: cannot stat