User Details
- User Since
- Sep 23 2015, 2:21 AM (348 w, 2 d)
Jan 10 2022
oof, sorry, I'm still figuring out the new interface, this is committed here:
add FIXME suggested by @aeubanks
Jan 8 2022
Feb 14 2021
this is very cool, Florian. do you mind letting us know (or maintaining a list somewhere) of bugs this finds?
Jul 8 2020
Did you mean to check something like the following?
define i32 @src(i1 %cond, i32 %x) { %x2 = freeze i32 %x %s = select i1 %cond, i32 %x2, i32 undef ret i32 %s } define i32 @tgt(i1 %cond, i32 %x) { %x2 = freeze i32 %x ret i32 %x2 }
@craig.topper ok, I agree that should work. alive doesn't like it -- is this an alive bug @nlopes? a freeze should not yield undef.
https://alive2.llvm.org/ce/z/mWAsYv
@majnemer should work: https://alive2.llvm.org/ce/z/vL4yn4
Apr 1 2020
Sorry but I don't think this can land until it has options for sending sanitizer output to Slack channels and SMS numbers.
Mar 14 2020
so this works but seems heavy-handed:
http://volta.cs.utah.edu:8080/z/w-L7Jw
Feb 26 2020
This seems good to me.
Feb 10 2020
Oct 4 2019
Jul 16 2019
Jul 7 2019
I'll just add that we (my students and I) are interested in making the UB semantics easily pluggable / switchable. They'll still (almost certainly) be in C++, but we'd like to factor these out so at least they're cleanly separated and easily swapped out.
Jun 19 2019
I am also in the "be a bit conservative at first and see how things shake out" camp, but it's y'all doing the hard work here, not me :)
Jun 17 2019
Just wanted to say that I think I agree with the design choices here!
May 15 2019
May 4 2019
Apr 17 2019
Dec 29 2018
Nov 20 2018
tweak spacing
refactor a bit-- getRangeForOperand() now returns an optional since it can fail
eliminate tabs
factor out the getRangeForOperand() code
Refresh patch, and fix a test broken by increased LVI precision.
Nov 17 2018
Nov 1 2018
Regarding ++ and --, I think for now it's fine to just document that these aren't instrumented.
Oct 31 2018
I do not agree that ++ is performed on the original type. The C99 standard (6.5.3.1.2) appears to be very clear on this point: "The expression ++E is equivalent to (E+=1)."
This patch doesn't appear to yet fix the "x++" or "x--" cases.
I can test this and write a few test cases.
Oct 5 2018
Sep 14 2018
Apr 6 2018
Aug 4 2017
Jul 25 2017
Could you please quantify the effect that this has on compile time? Time for an optimized -j1 compile of LLVM itself is reasonable. Also it would be nice to know what effect this has on generated code.
Jun 7 2017
Well, my second program should subtract a multiple of sizeof(T). But anyway, my view is that this is a real overflow and a nasty consequence of the unsigned size_t and the usual arithmetic conversions and I don't think we want to try to poke a hole in UBSan to allow this idiom unless it turns out to be extremely common.
Sorry, let's go with this example instead, which makes it clear that the program is attempting to do something completely sensible:
I'm taking a look. For reference here's the test program I'm using.
Jun 5 2017
I'm afraid I don't have a better name for this.
May 9 2017
Apr 7 2017
Mar 9 2017
Feb 9 2017
Paging @dtzWill
Feb 1 2017
Does this check need to be sensitive to the dialect of C/C++ that the user asked for? I know that it used to be the case that the standard could be read either way for this case, but as you observe it is now unambiguously UB.
Out of curiosity, how many of these superfluous checks are not subsequently eliminated by InstCombine?
Nov 18 2016
I had some deadlines to get through, but now I'll get back to updating this patch, hopefully in a few days!
Jun 8 2016
I've looked at the code and I agree that the implementation is sound and is precise for non-wrapped inputs.
Jun 6 2016
Also see section 3.5 of this paper (by the authors of the code above):
Great to see some work going on here!
May 30 2016
May 27 2016
rebase and bump
May 26 2016
May 18 2016
Fix borked test. Thanks folks!
I should add a note about testing:
updated patch from Will:
May 17 2016
Hi guys, I don't know the best place for this-- just wanted to implement it since Rich Felker, author of Musl libc, was complaining that the transformation is missing. If this isn't the right place I'm happy to close this out.
May 12 2016
fix misspelling
revise wording as suggested by Sanjoy
May 11 2016
Oops-- instead of
I have a small, well-defined program that gets compiled into a crash by clang -O2 -fsanitize=signed-integer-overflow -fsanitize-trap=signed-integer-overflow. So either there's a bug in this patch or else teaching LLVM to see through overflow intrinsics is exposing a bug elsewhere. I'll narrow it down.
A few more reps of the build completed, and it's more like a 6 second slowdown on an 1.5-hour non-parallel build.
May 9 2016
Address Philip's feedback and rebase. Thanks for the comments!
May 8 2016
Looks like this patch makes a -j1 build of LLVM + Clang about 4 seconds slower on a Haswell-E. The total build takes about 87 minutes. The effect is robust across repetitions. I can give more details if anyone wants.
May 6 2016
Do we have a standard benchmark for measuring effect on compile time? If I was going to be somewhat careful about it I'd do a single-threaded build of LLVM using itself, then repeat enough times to get statistical significance. Is that good enough? Overkill? Is there something other than LLVM that I should be building? I have SPEC 2006 handy but an not sure it's widely available.