Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-10-10T11:32:06+00:00 2019-10-10T11:32:06+00:00 Roman Lebedev lebedev.ri@gmail.com 2019-10-10T11:32:06+00:00 urn:sha1:6430adbe647a1837c0476f2c9ecc1c0ef5cba14c llvm-svn: 374316 2019-10-10T09:25:02+00:00 Roman Lebedev lebedev.ri@gmail.com 2019-10-10T09:25:02+00:00 urn:sha1:536b0ee40ab97f2878dc124a321cf9108ee3d233 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 2019-10-02T21:20:37+00:00 Vitaly Buka vitalybuka@google.com 2019-10-02T21:20:37+00:00 urn:sha1:d39e7e2cf156f5f444637fb3d26e98d33b1bfc19 Summary: All other stack trace callers assume that PC contains return address. HWAsan already use GetNextInstructionPc in similar code. PR43339 Reviewers: eugenis, kcc, jfb Subscribers: dexonsmith, dberris, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68313 llvm-svn: 373529 2019-09-11T23:19:48+00:00 Vitaly Buka vitalybuka@google.com 2019-09-11T23:19:48+00:00 urn:sha1:c0fa632236308100e1031fc86edfde13ddc4bcef llvm-svn: 371687 2019-09-09T19:30:48+00:00 Max Moroz mmoroz@chromium.org 2019-09-09T19:30:48+00:00 urn:sha1:9508738cd1d4ad179021314bfe54f2a02cb029cd Summary: This option is true by default in sanitizer common. The default false value was added a while ago without any reasoning in https://github.com/llvm-mirror/compiler-rt/commit/524e934112a593ac081bf2b05aa0d60a67987f05 so, presumably it's safe to remove for consistency. Reviewers: hctim, samsonov, morehouse, kcc, vitalybuka Reviewed By: hctim, samsonov, vitalybuka Subscribers: delcypher, #sanitizers, llvm-commits, kcc Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D67193 llvm-svn: 371442 2019-08-01T17:53:25+00:00 Nico Weber nicolasweber@gmx.de 2019-08-01T17:53:25+00:00 urn:sha1:4a1a113a99082914734b78e434a2ffea78a57dc4 llvm-svn: 367589 2019-07-31T17:51:05+00:00 Nico Weber nicolasweber@gmx.de 2019-07-31T17:51:05+00:00 urn:sha1:46ba9697520f3978b094a880e9ae59fa4639c88c See https://reviews.llvm.org/D58620 for discussion, and for the commands I ran. In addition I also ran for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done and manually updated references to renamed files found by that. llvm-svn: 367452 2019-07-16T06:23:27+00:00 Stephan Bergmann sbergman@redhat.com 2019-07-16T06:23:27+00:00 urn:sha1:e215996a2932ed7c472f4e94dc4345b30fd0c373 i.e., recent 5745eccef54ddd3caca278d1d292a88b2281528b: * Bump the function_type_mismatch handler version, as its signature has changed. * The function_type_mismatch handler can return successfully now, so SanitizerKind::Function must be AlwaysRecoverable (like for SanitizerKind::Vptr). * But the minimal runtime would still unconditionally treat a call to the function_type_mismatch handler as failure, so disallow -fsanitize=function in combination with -fsanitize-minimal-runtime (like it was already done for -fsanitize=vptr). * Add tests. Differential Revision: https://reviews.llvm.org/D61479 llvm-svn: 366186 2019-06-15T01:37:14+00:00 Vitaly Buka vitalybuka@google.com 2019-06-15T01:37:14+00:00 urn:sha1:0b1ea8cb2825cb51c1c2f6dfa9bef95f4a450f93 Summary: It's handling isses as described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832 Patch by Martin Liška. Reviewers: kcc, vitalybuka Reviewed By: vitalybuka Subscribers: cryptoad, kubamracek Differential Revision: https://reviews.llvm.org/D59876 llvm-svn: 363480 2019-05-02T07:05:29+00:00 Stephan Bergmann sbergman@redhat.com 2019-05-02T07:05:29+00:00 urn:sha1:2f0ef58e535c8578dbc2cf57e85b61d8aa5c1643 ...after 5745eccef54ddd3caca278d1d292a88b2281528b "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO" llvm-svn: 359760