| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
Fix file extension of alignment-assumption-ignorelist.cppp test During the renaming of blacklist to ignorelist this test got renamed incorrectly. Differential revision: https://reviews.llvm.org/D114710 | 4 年前 | |
[compiler-rt][UBSan] Sanitization for alignment assumptions. Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178 | 7 年前 | |
[ubsan] Remove REQUIRED from some TestCases It's not obvious why they are needed, and tests pass. Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D111859 | 4 年前 | |
[UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. Therefore, as per the standard, applying non-zero offset to nullptr (or making non-nullptr a nullptr, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* nullptr is not defined, i.e. e.g. -fno-delete-null-pointer-checks was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 [InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. getelementpointer inbounds is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average +21.62% slowdown * existing check vs. check after this patch: average 22.04% slowdown * no sanitization vs. this patch: average 48.42% slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 llvm-svn: 374293 | 6 年前 | |
[test] Fix unused FileCheck prefixes in compiler-rt/test | 5 年前 | |
[ubsan] Remove REQUIRED from some TestCases It's not obvious why they are needed, and tests pass. Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D111859 | 4 年前 | |
[UBSan] Split nullptr-and-nonzero-offset-variable.c in another direction llvm-svn: 374309 | 6 年前 | |
[UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. Therefore, as per the standard, applying non-zero offset to nullptr (or making non-nullptr a nullptr, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* nullptr is not defined, i.e. e.g. -fno-delete-null-pointer-checks was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 [InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. getelementpointer inbounds is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average +21.62% slowdown * existing check vs. check after this patch: average 22.04% slowdown * no sanitization vs. this patch: average 48.42% slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 llvm-svn: 374293 | 6 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 6 年前 |