summaryrefslogtreecommitdiffstats
path: root/compiler-rt/test
Commit message (Collapse)AuthorAgeFilesLines
* [compiler-rt] Reduce the number of threads in gcov test to avoid failureCalixte Denizet2020-06-231-15/+5
| | | | | | | | | | | | | | | | | | | | Summary: Patch in D78477 introduced a new test for gcov and this test is failing on arm: - http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-full-sh/builds/4752/steps/ninja%20check%202/logs/stdio - http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/10501/steps/ninja%20check%202/logs/stdio So try to fix it in reducing the number of threads. Reviewers: marco-c Reviewed By: marco-c Subscribers: dberris, kristof.beyls, #sanitizers, serge-sans-paille, sylvestre.ledru Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D79621 (cherry picked from commit 0da37bedc2667da371eda30595a06210595881d0)
* [profile] Don't crash when forking in several threadsCalixte Denizet2020-05-072-0/+46
| | | | | | | | | | | | | | | | | | | Summary: When forking in several threads, the counters were written out in using the same global static variables (see GCDAProfiling.c): that leads to crashes. So when there is a fork, the counters are resetted in the child process and they will be dumped at exit using the interprocess file locking. When there is an exec, the counters are written out and in case of failures they're resetted. Reviewers: jfb, vsk, marco-c, serge-sans-paille Reviewed By: marco-c, serge-sans-paille Subscribers: llvm-commits, serge-sans-paille, dmajor, cfe-commits, hiraditya, dexonsmith, #sanitizers, marco-c, sylvestre.ledru Tags: #sanitizers, #clang, #llvm Differential Revision: https://reviews.llvm.org/D78477 (cherry picked from commit bec223a9bc4eb9747993ee9a4c1aa135c32123e6)
* Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)Hans Wennborg2020-03-031-1/+1
| | | | | | | | | | | | | and follow-ups: a2ca1c2d "build: disable zlib by default on Windows" 2181bf40 "[CMake] Link against ZLIB::ZLIB" 1079c68a "Attempt to fix ZLIB CMake logic on Windows" This changed the output of llvm-config --system-libs, and more importantly it broke stand-alone builds. Instead of piling on more fix attempts, let's revert this to reduce the risk of more breakages. (cherry picked from commit 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e)
* [profile] Support merge pool size >= 10Fangrui Song2020-01-121-0/+7
| | | | | | | | | | | The executable acquires an advisory record lock (`fcntl(fd, F_SETLKW, *)`) on a profile file. Merge pool size >= 10 may be beneficial when the concurrency is large. Also fix a small problem about snprintf. It can cause the filename to be truncated after %m. Reviewed By: davidxl Differential Revision: https://reviews.llvm.org/D71970
* [cfi][test] cross-dso/stats.cpp: don't assume the order of static constructorsFangrui Song2020-01-081-4/+4
| | | | | | | | __sanitizer_stat_init is called for the executable first, then the shared object. In WriterModuleReport(), the information for the shared object will be recorded first. It'd be nice to get rid of the order requirement of static constructors. (This should make .ctors platforms work.)
* [msan] Fix underflow in qsort interceptor.Evgenii Stepanov2020-01-061-0/+7
|
* [msan] Check qsort input.Evgenii Stepanov2020-01-061-0/+5
| | | | | | | | | | | | | | | | | | Summary: Qsort interceptor suppresses all checks by unpoisoning the data in the wrapper of a comparator function, and then unpoisoning the output array as well. This change adds an explicit run of the comparator on all elements of the input array to catch any sanitizer bugs. Reviewers: vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71780
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-021-1/+1
| | | | | | | | | | | | | Rather than handling zlib handling manually, use `find_package` from CMake to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`, `HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is set to `YES`, which requires the distributor to explicitly select whether zlib is enabled or not. This simplifies the CMake handling and usage in the rest of the tooling. This restores 68a235d07f9e7049c7eb0c8091f37e385327ac28, e6c7ed6d2164a0659fd9f6ee44f1375d301e3cad. The problem with the windows bot is a need for clearing the cache.
* Revert "build: reduce CMake handling for zlib"James Henderson2020-01-021-1/+1
| | | | | | | This reverts commit 68a235d07f9e7049c7eb0c8091f37e385327ac28. This commit broke the clang-x64-windows-msvc build bot and a follow-up commit did not fix it. Reverting to fix the bot.
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-011-1/+1
| | | | | | | | | Rather than handling zlib handling manually, use `find_package` from CMake to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`, `HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is set to `YES`, which requires the distributor to explicitly select whether zlib is enabled or not. This simplifies the CMake handling and usage in the rest of the tooling.
* Reland "[msan] Intercept qsort, qsort_r."Reid Kleckner2019-12-271-0/+73
| | | | | | | This reverts commit 8fcce5ac73d49981656d9126e6c88391c1f6bf01. I spoke too soon, the revert does not actually cause the startup crash to go away.
* Revert "[msan] Intercept qsort, qsort_r."Reid Kleckner2019-12-271-73/+0
| | | | | | | | | | | | | | | | | | | This reverts commit 7a9ebe95125ea87a494d0c18f44f10bd70e12188, and dependent commit 54c522420347e58aa7bae1892cf5c5672b57c875, which disables qsort interception for some iOS platforms. After this change, the -Nolibc sanitizer common test binary crashes on startup on my regular Linux workstation, as well as on our bots: https://ci.chromium.org/p/chromium/builders/try/linux_upload_clang/740 ******************** Failing Tests (1): SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test/SanitizerCommon.NolibcMain Loading it up in gdb shows that it crashes during relocation processing, which suggests that some glibc loader versions do not support the THREADLOCAL data added in this interceptor.
* Revert "[msan] Check qsort input."Evgenii Stepanov2019-12-261-5/+0
| | | | | | | | | | | | | This change breaks LLVM bootstrap with ASan and MSan. FAILED: lib/ToolDrivers/llvm-lib/Options.inc OptParser.td:137:1: error: Option is equivalent to def INPUT : Option<[], "<input>", KIND_INPUT>; ^ OptParser.td:137:1: error: Other defined here def INPUT : Option<[], "<input>", KIND_INPUT>; This reverts commit caa48a6b88aeed8ae80e6ddb1eae8c6a7cbe260b.
* [msan] Check qsort input.Evgenii Stepanov2019-12-231-0/+5
| | | | | | | | | | | | | | | | | | Summary: Qsort interceptor suppresses all checks by unpoisoning the data in the wrapper of a comparator function, and then unpoisoning the output array as well. This change adds an explicit run of the comparator on all elements of the input array to catch any sanitizer bugs. Reviewers: vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71780
* [msan] Intercept qsort, qsort_r.Evgenii Stepanov2019-12-231-0/+73
| | | | | | | | | | | | | | | Summary: This fixes qsort-related false positives with glibc-2.27. I'm not entirely sure why they did not show up with the earlier versions; the code seems similar enough. Reviewers: vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71740
* Revert "[msan] Check qsort input." and "[msan] Intercept qsort, qsort_r."Jonas Devlieghere2019-12-201-78/+0
| | | | | | | | | | | | | | Temporarily revert the qsort changes because they fail to build on bots that build with modules: > error: thread-local storage is not supported for the current > target (iossim) http://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/1820/console http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/4983/console This reverts commit ddf897fc80499ece298bc33201db6b697d2af50e. This reverts commit 07861e955d0095f25639d84c5726c73b528567cb.
* [iOS sim] Ensure simulator device is booted in iossim_prepare.pyJulian Lettner2019-12-201-1/+13
| | | | | | | | | | | | | | Recent versions of the iOS simulator require that a "simulator device" is booted before we can use `simctl spawn` (see iossim_run.py) to start processes. We can use `simctl bootstatus` to ensure that the simulator device is booted before we run any tests via lit. The `-b` option starts the device if necessary. Reviewed By: delcypher Differential Revision: https://reviews.llvm.org/D71449
* [compiler-rt] [test] Disable MPROTECT for XRay tests on NetBSDMichał Górny2019-12-201-0/+3
|
* [msan] Check qsort input.Evgenii Stepanov2019-12-201-0/+5
| | | | | | | | | | | | | | | | | | Summary: Qsort interceptor suppresses all checks by unpoisoning the data in the wrapper of a comparator function, and then unpoisoning the output array as well. This change adds an explicit run of the comparator on all elements of the input array to catch any sanitizer bugs. Reviewers: vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71780
* [msan] Intercept qsort, qsort_r.Evgenii Stepanov2019-12-201-0/+73
| | | | | | | | | | | | | | | Summary: This fixes qsort-related false positives with glibc-2.27. I'm not entirely sure why they did not show up with the earlier versions; the code seems similar enough. Reviewers: vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71740
* [compiler-rt] [test] Disable MPROTECT on two builtin testsMichał Górny2019-12-204-8/+18
| | | | | | | | Introduce a new %run_nomprotect substitution to run tests that do not work with MPROTECT enabled. This uses paxctl via a wrapper on NetBSD, and evaluates to plain %run on other systems. Differential Revision: https://reviews.llvm.org/D71513
* [compiler-rt] [test] Add missing %run to fread_fwrite MSAN testMichał Górny2019-12-191-1/+1
| | | | | | | | Add a missing %run substitution to fread_fwrite test. This fixes the test on NetBSD where %run disables ASLR as necessary for MSAN to function. Differential Revision: https://reviews.llvm.org/D71623
* [compiler-rt] [fuzzer] Enable LSan in libFuzzer tests on NetBSDKamil Rytarowski2019-12-191-1/+0
|
* [compiler-rt] [test] Disable ASLR on UBSAN+[AMT]SAN tests on NetBSDMichał Górny2019-12-181-0/+2
|
* [compiler-rt] [test] Disable ASLR on LSAN+ASAN tests on NetBSDMichał Górny2019-12-181-0/+2
|
* [compiler-rt] [test] Disable ASLR for fuzzer tests on NetBSDMichał Górny2019-12-181-0/+3
|
* [lit] Remove lit's REQUIRES-ANY directiveThomas Preud'homme2019-12-1710-10/+10
| | | | | | | | | | | | | | | | | Summary: Remove REQUIRES-ANY alias lit directive since it is hardly used and can be easily implemented using an OR expression using REQUIRES. Fixup remaining testcases still using REQUIRES-ANY. Reviewers: probinson, jdenny, gparker42 Reviewed By: gparker42 Subscribers: eugenis, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, delcypher, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits, #sanitizers, llvm-commits Tags: #llvm, #clang, #sanitizers Differential Revision: https://reviews.llvm.org/D71408
* Change `asan/TestCases/Darwin/malloc_zone-protected.cpp` to call abort so ↵Dan Liew2019-12-161-1/+1
| | | | | | | | | | | | | | | | | | | | that it **always crashes**. Summary: This is needed because on some platforms we can't install signal handlers and so the application just traps (i.e. crashes) rather than being intercepted by ASan's signal handler which in the default Darwin config doesn't exit with a crashing exit code. rdar://problem/57984547 Reviewers: yln, kubamracek, jfb Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71573
* [ubsan] Enable testing of .m filesVedant Kumar2019-12-131-1/+1
| | | | | This allows `.m` test files, like the existing Misc/bool.m, to be tested.
* [LSAN] Increase stack space for guard-page.c testAlex Richardson2019-12-131-2/+2
| | | | | | | | | | | | | | | | | | Summary: When running the tests on a Ubuntu 18.04 machine this test is crashing for me inside the runtime linker. My guess is that it is trying to save more registers (possibly large vector ones) and the current stack space is not sufficient. Reviewers: samsonov, kcc, eugenis Reviewed By: eugenis Subscribers: eugenis, merge_guards_bot, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71461
* [Scudo] [GWP-ASan] Add GWP-ASan to Scudo Standalone.Mitch Phillips2019-12-131-0/+4
| | | | | | | | | | | | | | | | Summary: Adds GWP-ASan to Scudo standalone. Default parameters are pulled across from the GWP-ASan build. No backtrace support as of yet. Reviewers: cryptoad, eugenis, pcc Reviewed By: cryptoad Subscribers: merge_guards_bot, mgorny, #sanitizers, llvm-commits, cferris, vlad.tsyrklevich, pcc Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71229
* [iOS sim] Simplify iossim_run.py scriptJulian Lettner2019-12-121-3/+2
|
* [TSan] Pacify flaky test on DarwinJulian Lettner2019-12-111-7/+18
| | | | | | | | | | | This flaky test that I added really gives our CI a lot of headaches. Although I was never able to reproduce this locally, it sporadically hangs/fails on our bots. I decided to silently pass the test whenever we are unable to setup the proper test condition after 10 retries. This is of course suboptimal and a last recourse. Please let me know if you know how to test this better. rdar://57844626
* [profile] Delete stale profiles in test/profile/instrprof-value-prof.test, NFCVedant Kumar2019-12-111-0/+1
|
* [profile] Delete stale profile in test/profile/instrprof-set-filename.c, NFCVedant Kumar2019-12-111-0/+2
|
* [profile] Add explanatory comments to instrprof-darwin-exports.c, NFCVedant Kumar2019-12-101-3/+11
|
* Remove unused Unit test directory for xray.Eric Christopher2019-12-092-43/+0
|
* [compiler-rt] [test] Disable ASLR on ASAN/MSAN/TSAN tests on NetBSDMichał Górny2019-12-066-0/+21
| | | | | | | | Use a new %run wrapper for ASAN/MSAN/TSAN tests that calls paxctl in order to disable ASLR on the test executables. This makes it possible to test sanitizers on systems where ASLR is enabled by default. Differential Revision: https://reviews.llvm.org/D70958
* [compiler-rt] Disable fuzzer large.test when LLVM_ENABLE_EXPENSIVE_CHECKS=ONAlex Lorenz2019-12-034-0/+7
| | | | | | | | | | | | | This test is timing out on Green Dragon http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/ and looks like it's not executed on other bots with expensive checks enabled http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-ubuntu http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win The test times out at the C++ source file takes too long to build (2+ hours on my machine), as clang spends a lot of time in IR/MIR verifiers. Differential Revision: https://reviews.llvm.org/D70024
* Rename `tsan/race_range_pc.cc` to `test/tsan/race_range_pc.cpp`.Dan Liew2019-12-031-0/+0
| | | | The old suffix was preventing it from being executed by default.
* Revert "Revert 1689ad27af5 "[builtins] Implement rounding mode support for ↵Yi Kong2019-11-272-2/+4
| | | | | | | | | i386/x86_64"" Don't build specilised fp_mode.c on MSVC since it does not support inline ASM on x86_64. This reverts commit a19f0eec94e195cac676d0d473882b48f4fded90.
* [clang][CodeGen] Implicit Conversion Sanitizer: handle increment/decrement ↵Roman Lebedev2019-11-273-0/+364
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (PR44054)(take 2) Summary: Implicit Conversion Sanitizer is *almost* feature complete. There aren't *that* much unsanitized things left, two major ones are increment/decrement (this patch) and bit fields. As it was discussed in [[ https://bugs.llvm.org/show_bug.cgi?id=39519 | PR39519 ]], unlike `CompoundAssignOperator` (which is promoted internally), or `BinaryOperator` (for which we always have promotion/demotion in AST) or parts of `UnaryOperator` (we have promotion/demotion but only for certain operations), for inc/dec, clang omits promotion/demotion altogether, under as-if rule. This is technically correct: https://rise4fun.com/Alive/zPgD As it can be seen in `InstCombineCasts.cpp` `canEvaluateTruncated()`, `add`/`sub`/`mul`/`and`/`or`/`xor` operators can all arbitrarily be extended or truncated: https://github.com/llvm/llvm-project/blob/901cd3b3f62d0c700e5d2c3f97eff97d634bec5e/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp#L1320-L1334 But that has serious implications: 1. Since we no longer model implicit casts, do we pessimise their AST representation and everything that uses it? 2. There is no demotion, so lossy demotion sanitizer does not trigger :] Now, i'm not going to argue about the first problem here, but the second one **needs** to be addressed. As it was stated in the report, this is done intentionally, so changing this in all modes would be considered a penalization/regression. Which means, the sanitization-less codegen must not be altered. It was also suggested to not change the sanitized codegen to the one with demotion, but i quite strongly believe that will not be the wise choice here: 1. One will need to re-engineer the check that the inc/dec was lossy in terms of `@llvm.{u,s}{add,sub}.with.overflow` builtins 2. We will still need to compute the result we would lossily demote. (i.e. the result of wide `add`ition/`sub`traction) 3. I suspect it would need to be done right here, in sanitization. Which kinda defeats the point of using `@llvm.{u,s}{add,sub}.with.overflow` builtins: we'd have two `add`s with basically the same arguments, one of which is used for check+error-less codepath and other one for the error reporting. That seems worse than a single wide op+check. 4. OR, we would need to do that in the compiler-rt handler. Which means we'll need a whole new handler. But then what about the `CompoundAssignOperator`, it would also be applicable for it. So this also doesn't really seem like the right path to me. 5. At least X86 (but likely others) pessimizes all sub-`i32` operations (due to partial register stalls), so even if we avoid promotion+demotion, the computations will //likely// be performed in `i32` anyways. So i'm not really seeing much benefit of not doing the straight-forward thing. While looking into this, i have noticed a few more LLVM middle-end missed canonicalizations, and filed [[ https://bugs.llvm.org/show_bug.cgi?id=44100 | PR44100 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=44102 | PR44102 ]]. Those are not specific to inc/dec, we also have them for `CompoundAssignOperator`, and it can happen for normal arithmetics, too. But if we take some other path in the patch, it will not be applicable here, and we will have most likely played ourselves. TLDR: front-end should emit canonical, easy-to-optimize yet un-optimized code. It is middle-end's job to make it optimal. I'm really hoping reviewers agree with my personal assessment of the path this patch should take.. This originally landed in 9872ea4ed1de4c49300430e4f1f4dfc110a79ab9 but got immediately reverted in cbfa237892e55b7129a1178c9b03f26683d643af because the assertion was faulty. That fault ended up being caused by the enum - while there will be promotion, both types are unsigned, with same width. So we still don't need to sanitize non-signed cases. So far. Maybe the assert will tell us this isn't so. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44054 | PR44054 ]]. Refs. https://github.com/google/sanitizers/issues/940 Reviewers: rjmccall, erichkeane, rsmith, vsk Reviewed By: erichkeane Subscribers: mehdi_amini, dexonsmith, cfe-commits, #sanitizers, llvm-commits, aaron.ballman, t.p.northover, efriedma, regehr Tags: #llvm, #clang, #sanitizers Differential Revision: https://reviews.llvm.org/D70539
* [profile] Fix file contention causing dropped counts on Windows under ↵Hans Wennborg2019-11-273-0/+108
| | | | | | | | | | | | | | | | | | | | | -fprofile-generate See PR43425: https://bugs.llvm.org/show_bug.cgi?id=43425 When writing profile data on Windows we were opening profile file with exclusive read/write access. In case we are trying to write to the file from multiple processes simultaneously, subsequent calls to CreateFileA would return INVALID_HANDLE_VALUE. To fix this, I changed to open without exclusive access and then take a lock. Patch by Michael Holman! Differential revision: https://reviews.llvm.org/D70330
* Revert "[clang][CodeGen] Implicit Conversion Sanitizer: handle ↵Roman Lebedev2019-11-273-364/+0
| | | | | | | | | | increment/decrement (PR44054)" The asssertion that was added does not hold, breaks on test-suite/MultiSource/Applications/SPASS/analyze.c Will reduce the testcase and revisit. This reverts commit 9872ea4ed1de4c49300430e4f1f4dfc110a79ab9, 870f3542d3e0d06d208442bdca6482866b59171b.
* [clang][CodeGen] Implicit Conversion Sanitizer: handle increment/decrement ↵Roman Lebedev2019-11-273-0/+364
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (PR44054) Summary: Implicit Conversion Sanitizer is *almost* feature complete. There aren't *that* much unsanitized things left, two major ones are increment/decrement (this patch) and bit fields. As it was discussed in [[ https://bugs.llvm.org/show_bug.cgi?id=39519 | PR39519 ]], unlike `CompoundAssignOperator` (which is promoted internally), or `BinaryOperator` (for which we always have promotion/demotion in AST) or parts of `UnaryOperator` (we have promotion/demotion but only for certain operations), for inc/dec, clang omits promotion/demotion altogether, under as-if rule. This is technically correct: https://rise4fun.com/Alive/zPgD As it can be seen in `InstCombineCasts.cpp` `canEvaluateTruncated()`, `add`/`sub`/`mul`/`and`/`or`/`xor` operators can all arbitrarily be extended or truncated: https://github.com/llvm/llvm-project/blob/901cd3b3f62d0c700e5d2c3f97eff97d634bec5e/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp#L1320-L1334 But that has serious implications: 1. Since we no longer model implicit casts, do we pessimise their AST representation and everything that uses it? 2. There is no demotion, so lossy demotion sanitizer does not trigger :] Now, i'm not going to argue about the first problem here, but the second one **needs** to be addressed. As it was stated in the report, this is done intentionally, so changing this in all modes would be considered a penalization/regression. Which means, the sanitization-less codegen must not be altered. It was also suggested to not change the sanitized codegen to the one with demotion, but i quite strongly believe that will not be the wise choice here: 1. One will need to re-engineer the check that the inc/dec was lossy in terms of `@llvm.{u,s}{add,sub}.with.overflow` builtins 2. We will still need to compute the result we would lossily demote. (i.e. the result of wide `add`ition/`sub`traction) 3. I suspect it would need to be done right here, in sanitization. Which kinda defeats the point of using `@llvm.{u,s}{add,sub}.with.overflow` builtins: we'd have two `add`s with basically the same arguments, one of which is used for check+error-less codepath and other one for the error reporting. That seems worse than a single wide op+check. 4. OR, we would need to do that in the compiler-rt handler. Which means we'll need a whole new handler. But then what about the `CompoundAssignOperator`, it would also be applicable for it. So this also doesn't really seem like the right path to me. 5. At least X86 (but likely others) pessimizes all sub-`i32` operations (due to partial register stalls), so even if we avoid promotion+demotion, the computations will //likely// be performed in `i32` anyways. So i'm not really seeing much benefit of not doing the straight-forward thing. While looking into this, i have noticed a few more LLVM middle-end missed canonicalizations, and filed [[ https://bugs.llvm.org/show_bug.cgi?id=44100 | PR44100 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=44102 | PR44102 ]]. Those are not specific to inc/dec, we also have them for `CompoundAssignOperator`, and it can happen for normal arithmetics, too. But if we take some other path in the patch, it will not be applicable here, and we will have most likely played ourselves. TLDR: front-end should emit canonical, easy-to-optimize yet un-optimized code. It is middle-end's job to make it optimal. I'm really hoping reviewers agree with my personal assessment of the path this patch should take.. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44054 | PR44054 ]]. Reviewers: rjmccall, erichkeane, rsmith, vsk Reviewed By: erichkeane Subscribers: mehdi_amini, dexonsmith, cfe-commits, #sanitizers, llvm-commits, aaron.ballman, t.p.northover, efriedma, regehr Tags: #llvm, #clang, #sanitizers Differential Revision: https://reviews.llvm.org/D70539
* [PowerPC][compiler-rt][builtins]Add __fixtfti builtin on PowerPCLei Huang2019-11-252-0/+1608
| | | | | | | | | | | | Implements __fixtfti builtin for PowerPC. This builtin converts a long double (IBM double-double) to a signed int128. The conversion relies on the unsigned conversion of the absolute value of the long double. Tests included for both positive and negative long doubles. Patch By: Baptiste Saleil Differential Revision: https://reviews.llvm.org/D69730
* [TSan] Make `mach_vm_allocate.c` test less flakyJulian Lettner2019-11-211-5/+8
| | | | rdar://57365733
* [Symbolizers] On Darwin compute function offset when possible.Dan Liew2019-11-193-2/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The sanitizer symbolizers support printing the function offset (difference between pc and function start) of a stackframe using the `%q` format specifier. Unfortunately this didn't actually work because neither the atos or dladdr symbolizer set the `AddressInfo::function_offset` field. This patch teaches both symbolizers to try to compute the function offset. In the case of the atos symbolizer, atos might not report the function offset (e.g. it reports a source location instead) so in this case it fallsback to using `dladdr()` to compute the function offset. Two test cases are included. rdar://problem/56695185 Reviewers: kubamracek, yln Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69549
* Revert 1689ad27af5 "[builtins] Implement rounding mode support for i386/x86_64"Hans Wennborg2019-11-192-4/+2
| | | | | | | | It broke the build with MSVC: fp_mode.c(20): error C2065: '__asm__': undeclared identifier > Differential Revision: https://reviews.llvm.org/D69870
* [profile] Support online merging with continuous sync modeVedant Kumar2019-11-181-0/+138
| | | | | | | | | | | | | | | Make it possible to use online profile merging ("%m" mode) with continuous sync ("%c" mode). To implement this, the merged profile is locked in the runtime initialization step and either a) filled out for the first time or b) checked for compatibility. Then, the profile can simply be mmap()'d with MAP_SHARED set. With the mmap() in place, counter updates from every process which uses an image are mapped onto the same set of physical pages assigned by the filesystem cache. After the mmap() is set up, the profile is unlocked. Differential Revision: https://reviews.llvm.org/D69586
OpenPOWER on IntegriCloud