summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen/catch-implicit-integer-conversions-basics.c
Commit message (Collapse)AuthorAgeFilesLines
* [clang][ubsan] Implicit Conversion Sanitizer - integer sign change - clang partRoman Lebedev2018-10-301-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second half of Implicit Integer Conversion Sanitizer. It completes the first half, and finally makes the sanitizer fully functional! Only the bitfield handling is missing. Summary: C and C++ are interesting languages. They are statically typed, but weakly. The implicit conversions are allowed. This is nice, allows to write code while balancing between getting drowned in everything being convertible, and nothing being convertible. As usual, this comes with a price: ``` void consume(unsigned int val); void test(int val) { consume(val); // The 'val' is `signed int`, but `consume()` takes `unsigned int`. // If val is negative, then consume() will be operating on a large // unsigned value, and you may or may not have a bug. // But yes, sometimes this is intentional. // Making the conversion explicit silences the sanitizer. consume((unsigned int)val); } ``` Yes, there is a `-Wsign-conversion`` diagnostic group, but first, it is kinda noisy, since it warns on everything (unlike sanitizers, warning on an actual issues), and second, likely there are cases where it does **not** warn. The actual detection is pretty easy. We just need to check each of the values whether it is negative, and equality-compare the results of those comparisons. The unsigned value is obviously non-negative. Zero is non-negative too. https://godbolt.org/g/w93oj2 We do not have to emit the check *always*, there are obvious situations where we can avoid emitting it, since it would **always** get optimized-out. But i do think the tautological IR (`icmp ult %x, 0`, which is always false) should be emitted, and the middle-end should cleanup it. This sanitizer is in the `-fsanitize=implicit-conversion` group, and is a logical continuation of D48958 `-fsanitize=implicit-integer-truncation`. As for the ordering, i'we opted to emit the check **after** `-fsanitize=implicit-integer-truncation`. At least on these simple 16 test cases, this results in 1 of the 12 emitted checks being optimized away, as compared to 0 checks being optimized away if the order is reversed. This is a clang part. The compiler-rt part is D50251. Finishes fixing [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]]. Finishes partially fixing [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]]. Finishes fixing https://github.com/google/sanitizers/issues/940. Only the bitfield handling is missing. Reviewers: vsk, rsmith, rjmccall, #sanitizers, erichkeane Reviewed By: rsmith Subscribers: chandlerc, filcab, cfe-commits, regehr Tags: #sanitizers, #clang Differential Revision: https://reviews.llvm.org/D50250 llvm-svn: 345660
* [clang][ubsan] Split Implicit Integer Truncation Sanitizer into unsigned and ↵Roman Lebedev2018-10-111-9/+9
| | | | | | | | | | | | | | | | | | | | signed checks Summary: As per IRC disscussion, it seems we really want to have more fine-grained `-fsanitize=implicit-integer-truncation`: * A check when both of the types are unsigned. * Another check for the other cases (either one of the types is signed, or both of the types is signed). This is clang part. Compiler-rt part is D50902. Reviewers: rsmith, vsk, Sanitizers Reviewed by: rsmith Differential Revision: https://reviews.llvm.org/D50901 llvm-svn: 344230
* [clang][ubsan][NFC] Slight test cleanup in preparation for D50901Roman Lebedev2018-09-271-16/+0
| | | | | | | | | | | | Reviewers: vsk, vitalybuka, filcab Reviewed By: vitalybuka Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D52589 llvm-svn: 343251
* [NFC] Some small test updates for Implicit Conversion sanitizer.Roman Lebedev2018-08-171-0/+131
Split off from D50250. llvm-svn: 339995
OpenPOWER on IntegriCloud