similar to: [LLVMdev] proposal for exploiting undefined behavior much more aggressively

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

On Thu, Jul 26, 2012 at 3:41 PM, Chris Lattner <clattner at apple.com> wrote: > 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

> 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

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

We (the folks working on Souper) would appreciate any feedback on these IR-level superoptimizer results: http://blog.regehr.org/extra_files/souper-jul-15.html My impression is that while there's clearly plenty of material in here that doesn't want to get implemented in an opt pass, there are a number of gems hiding in there that are worth implementing. Blog post containing

On 01/20/2010 10:49 PM, John Regehr wrote: >> 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

I just tried asan on an optimized 32 bit build of ------------------------------------- #include <stdint.h> __attribute__((noinline)) void f(uint64_t *p) { *p = 42; } int main() { 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

I looked into the archives as far back as 2009 and searched around for more information about vmkit, but I still have some questions. First of all, what is that status of VMKit? Is there any active development? A roadmap? Is it in maintenance mode? Secondly, can VMKit generate binaries that can be used on android/jni? Finally, I understand that the .net/CLI support is no longer being

> I just noticed: most of the results in this batch seem to be about exploiting `[zs]ext i1` having cost 1 > in order to replace a select of cost 3. > Could you do a run where select has cost 1 and [zs]ext i1 (and trunc to i1) has cost 2 or 3? I tried this (or something quite similar) earlier and it caused Souper to introduce *a lot* of selects. So the problem is that Souper's

On the subject of undefined behavior and known bits, as I'm sure some of you are aware, code in ValueTracking.cpp is exploiting poison value rules to get a bit of extra precision in the known bits. These rules fire on examples like the ones below. Do we have a set of rules that clients of known bits need to follow to avoid unsoundness? I remember Nuno and/or David Majnemer saying

As you all have undoubtedly noticed, I recently did Yet Another Merge to Apple's GCC top-of-tree. This merge was prompted by several important fixes in the "blocks" implementation. There are still many testcases that need to be moved over, but those can come at our leisure. I compiled both the "Apple way" and the "FSF way". It also passed the tests in

Hi, i'm not too familiar with how the ogg vorbis community works, so i hope this is within the topic of the list, but i didnt really want to leave this thing i've did out in the dark either. :) i've just ported libvorbis, libogg, and vorbisfile stuff to the pocket pc a while ago, it was pretty straight forward (just add a few more #ifdefs around the ftoi function and some others) and

Hi, Can kernel's freeBSD exploited by tools hacking ? If true, can I know how to fix this problem, and what tools can do that. Thanks alot

Hi! If you were looking foe a paper about improving vorbis compression by using arithmetic coding and exploiting temporal redundancies (i.e. repeating sound) you might have a look here: http://web.interware.hu/rudas Three ogg vorbis files were compressed losslessly, with compression ratios between 2 - 8 % and compression time about 1/500 realtime (i.e. slow). Theoretical upper bound of the

I get the output below on Ubuntu Hardy on ia32 from svn 56984. John make[2]: Entering directory `/home/regehr/llvm-gcc/build/gcc' /home/regehr/llvm-gcc/build/./gcc/xgcc -B/home/regehr/llvm-gcc/build/./gcc/ -B/home/regehr/i686-pc-linux-gnu/bin/ -B/home/regehr/i686-pc-linux-gnu/lib/ -isystem /home/regehr/i686-pc-linux-gnu/include -isystem /home/regehr/i686-pc-linux-gnu/sys-include -O2 -O2

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

Hi, I'd like to see what parts of LLVM/Clang are being executed. I know that "make ENABLE_COVERAGE=1" used to just work, but so far (on 64-bit Ubuntu 14.04) I've had no luck building either 3.4.x or SVN head using any of Clang 3.4, Clang head, or a recent GCC. The first error that I get when building with GCC is this:

Also note that this is not the kind of bug for which asan is good. If we are dereferencing an uninitialized pointer, there is a high chance that the program will SEGV w/o any tool. If we are unlucky and the garbage is accidentally equal to some valid address, asan will not catch it either. Valgrind (and work-in-progress MemorySanitizer) will catch this. --kcc On Sat, Nov 3, 2012 at 5:38 AM, Eli

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an