summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [ASAN] fix startup crash in dlsym for long paths since glibc 2.27Peter Wu2018-06-141-1/+18
| | | | | | | | | | | | | | | | | | | | Summary: Error messages for dlsym used to be stored on the stack, but since commit 2449ae7b ("ld.so: Introduce struct dl_exception") in glibc 2.27 these are now stored on the heap (and thus use the dlsym alloc pool). Messages look like "undefined symbol: __isoc99_printf\0/path/to/a.out". With many missing library functions and long object paths, the pool is quickly exhausted. Implement a simple mechanism to return freed memory to the pool (clear it in case it is used for calloc). Fixes https://github.com/google/sanitizers/issues/957 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D47995 llvm-svn: 334703
* [Sanitizer] fix compilation warningDavid Carlier2018-06-141-1/+1
| | | | | | | | | | | | In most of systems, this field is a signed type but in some it is an unsigned. Reviewers: vitalybuka Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D48118 llvm-svn: 334686
* [ASAN] Fix fputs interception for 32-bit macOSPeter Wu2018-06-131-1/+1
| | | | | | | | | On 32-bit macOS, "_fputs$UNIX2003" is called instead of "fputs" and the "fgets_fputs" test fails. Apparently previous versions still passed the test due to the internal implementation calling "strlen", but that does not seem to be the case with macOS 10.13.3. Fixes r334450. llvm-svn: 334670
* [Sanitizers] Make sanitizer allocator linker-initialize compliant.Alex Shlyapnikov2018-06-133-4/+7
| | | | | | | | | | | | | | | | | | | | | Summary: These four SpinMutex ctors was the only code executed in the ctor for the static __asan::Allocator instance (same for the other sanitizers allocators), which is supposed to be fully linker-initialized. Also, when the global ctor for this allocator instance is executed, this instance might already be initialized by __asan_init called from .preinit_array. Issue: https://github.com/google/sanitizers/issues/194 Reviewers: morehouse, eugenis, cryptoad Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D48142 llvm-svn: 334660
* Disable MSan tests of prlimit on FreeBSDDimitry Andric2018-06-131-1/+1
| | | | | | | Like NetBSD, FreeBSD does not have prlimit(2), so do not attempt to use it during the MSan tests. llvm-svn: 334659
* [TSan] Fix madvise(MADV_NOHUGEPAGE) for meta shadow memoryAlex Shlyapnikov2018-06-134-18/+40
| | | | | | | | | | | | | | | | Summary: Move madvise(MADV_NOHUGEPAGE) for the meta shadow memory after the meta shadow memory is mapped (currently it silently fails with ENOMEM). Add a diagnostic message to detect similar problems in the future. Reviewers: dvyukov Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D48097 llvm-svn: 334624
* [XRay] Set an explicit dependency on libc++ when neededPetr Hosek2018-06-131-8/+20
| | | | | | | | | | | When XRay is being built as part of the just built compiler together with libc++ as part of the runtimes build, we need an explicit dependency from XRay to libc++ to make sure that the library is available by the time we start building XRay. Differential Revision: https://reviews.llvm.org/D48113 llvm-svn: 334575
* Reland "Passthrough additional flags to custom libcxx CMake build"Petr Hosek2018-06-131-0/+1
| | | | | | | | This is needed when we're cross-compiling compiler-rt. Differential Revision: https://reviews.llvm.org/D47834 llvm-svn: 334570
* Revert r334458, r334220, r334212, r334139.Matt Morehouse2018-06-121-1/+0
| | | | | | | Reverts changes to AddCompilerRT.cmake due to breakage of http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/. llvm-svn: 334528
* [asan, myriad] Support environment variablesWalter Lee2018-06-121-2/+5
| | | | | | | | | | Provide a buffer that the test harness can write into to provide values for the environment variables. Format is a null-separated list of VAR=value pairs; this is sufficent for our purpose. Differential Revision: https://reviews.llvm.org/D47960 llvm-svn: 334522
* [Fuzzer] Afl driver changing iterations handlingDavid Carlier2018-06-121-5/+19
| | | | | | | | | | | | Handling differently the iterations with the type limit and eventually an error message. Reviewers: morehouse, kcc Reviewed By: morehouse Differential Revision: https://reviews.llvm.org/D47880 llvm-svn: 334510
* [scudo] Add C++17 aligned new/delete operators supportKostya Kortchinsky2018-06-124-62/+87
| | | | | | | | | | | | | | | | | | | Summary: This CL adds support for aligned new/delete operators (C++17). Currently we do not support alignment inconsistency detection on deallocation, as this requires a header change, but the APIs are introduced and are functional. Add a smoke test for the aligned version of the operators. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D48031 llvm-svn: 334505
* [XRay][profiler] Part 5: Profiler File WritingDean Michael Berris2018-06-122-6/+53
| | | | | | | | | | | | | | | | | | | | | | | Summary: This is part of the larger XRay Profiling Mode effort. This patch implements the profile writing mechanism, to allow profiles collected through the profiler mode to be persisted to files. Follow-on patches would allow us to load these profiles and start converting/analysing them through the `llvm-xray` tool. Depends on D44620. Reviewers: echristo, kpw, pelikan Reviewed By: kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45998 llvm-svn: 334472
* [XRay][profiler] Part 4: Profiler Mode WiringDean Michael Berris2018-06-1210-52/+345
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is part of the larger XRay Profiling Mode effort. This patch implements the wiring required to enable us to actually select the `xray-profiling` mode, and install the handlers to start measuring the time and frequency of the function calls in call stacks. The current way to get the profile information is by working with the XRay API to `__xray_process_buffers(...)`. In subsequent changes we'll implement profile saving to files, similar to how the FDR and basic modes operate, as well as means for converting this format into those that can be loaded/visualised as flame graphs. We will also be extending the accounting tool in LLVM to support stack-based function call accounting. We also continue with the implementation to support building small histograms of latencies for the `FunctionCallTrie::Node` type, to allow us to actually approximate the distribution of latencies per function. Depends on D45758 and D46998. Reviewers: eizan, kpw, pelikan Reviewed By: kpw Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D44620 llvm-svn: 334469
* [builtins] Delay emutls deallocation for one roundRyan Prichard2018-06-121-11/+41
| | | | | | | | | | | | | | | | | | | | Summary: With Android/Bionic, delay deallocation to round 2 of 4. It must run after C++ thread_local destructors have been called, but before the final 2 rounds, because emutls calls free, and jemalloc then needs another 2 rounds to free its thread-specific data. Fixes https://github.com/android-ndk/ndk/issues/687 Reviewers: cmtice, srhines, jyknight, chh, echristo Reviewed By: srhines, chh, echristo Subscribers: echristo, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D46978 llvm-svn: 334463
* [builtins] emutls cleanup: determine header size using sizeofRyan Prichard2018-06-121-6/+7
| | | | | | | | | | | | | | Summary: Also add a few post-#else/#endif comments Reviewers: echristo, srhines Reviewed By: echristo Subscribers: chh, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D47861 llvm-svn: 334462
* [sanitizer] Add fgets, fputs and puts into sanitizer_commonPeter Wu2018-06-115-29/+50
| | | | | | | | | | | | | | | Summary: Add fgets, fputs and puts to sanitizer_common. This adds ASAN coverage for these functions, extends MSAN support from fgets to fputs/puts and extends TSAN support from puts to fputs. Fixes: https://github.com/google/sanitizers/issues/952 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D46545 llvm-svn: 334450
* [Sanitizers] Move pvalloc overflow tests to common.Alex Shlyapnikov2018-06-113-7/+15
| | | | | | | | | | | | | | | | | | | Summary: Now all sanitizers with improved allocator error reporting are covered by these common tests. Also, add pvalloc-specific checks to LSan. HWASan is not covered by sanitizer_common, hence its own pvalloc and other allocator tests. Reviewers: vitalybuka Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D47970 llvm-svn: 334424
* [scudo] Improve the scalability of the shared TSD modelKostya Kortchinsky2018-06-116-51/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The shared TSD model in its current form doesn't scale. Here is an example of rpc2-benchmark (with default parameters, which is threading heavy) on a 72-core machines (defaulting to a `CompactSizeClassMap` and no Quarantine): - with tcmalloc: 337K reqs/sec, peak RSS of 338MB; - with scudo (exclusive): 321K reqs/sec, peak RSS of 637MB; - with scudo (shared): 241K reqs/sec, peak RSS of 324MB. This isn't great, since the exclusive model uses a lot of memory, while the shared model doesn't even come close to be competitive. This is mostly due to the fact that we are consistently scanning the TSD pool starting at index 0 for an available TSD, which can result in a lot of failed lock attempts, and touching some memory that needs not be touched. This CL attempts to make things better in most situations: - first, use a thread local variable on Linux (intead of pthread APIs) to store the current TSD in the shared model; - move the locking boolean out of the TSD: this allows the compiler to use a register and potentially optimize out a branch instead of reading it from the TSD everytime (we also save a tiny bit of memory per TSD); - 64-bit atomic operations on 32-bit ARM platforms happen to be expensive: so store the `Precedence` in a `uptr` instead of a `u64`. We lose some nanoseconds of precision and we'll wrap around at some point, but the benefit is worth it; - change a `CHECK` to a `DCHECK`: this should never happen, but if something is ever terribly wrong, we'll crash on a near null AV if the TSD happens to be null; - based on an idea by dvyukov@, we are implementing a bound random scan for an available TSD. This requires computing the coprimes for the number of TSDs, and attempting to lock up to 4 TSDs in an random order before falling back to the current one. This is obviously slightly more expansive when we have just 2 TSDs (barely noticeable) but is otherwise beneficial. The `Precedence` still basically corresponds to the moment of the first contention on a TSD. To seed on random choice, we use the precedence of the current TSD since it is very likely to be non-zero (since we are in the slow path after a failed `tryLock`) With those modifications, the benchmark yields to: - with scudo (shared): 330K reqs/sec, peak RSS of 327MB. So the shared model for this specific situation not only becomes competitive but outperforms the exclusive model. I experimented with some values greater than 4 for the number of TSDs to attempt to lock and it yielded a decrease in QPS. Just sticking with the current TSD is also a tad slower. Numbers on platforms with less cores (eg: Android) remain similar. Reviewers: alekseyshl, dvyukov, javed.absar Reviewed By: alekseyshl, dvyukov Subscribers: srhines, kristof.beyls, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D47289 llvm-svn: 334410
* [ASAN] Fix crash on i?86-linux (32-bit) against glibc 2.27 and laterPeter Wu2018-06-101-7/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Running sanitized 32-bit x86 programs on glibc 2.27 crashes at startup, with: ERROR: AddressSanitizer: SEGV on unknown address 0xf7a8a250 (pc 0xf7f807f4 bp 0xff969fc8 sp 0xff969f7c T16777215) The signal is caused by a WRITE memory access. #0 0xf7f807f3 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x127f3) #1 0xf7a92599 (/lib/libasan.so.5+0x112599) #2 0xf7a80737 (/lib/libasan.so.5+0x100737) #3 0xf7f7e14f in _dl_init (/lib/ld-linux.so.2+0x1014f) #4 0xf7f6eb49 (/lib/ld-linux.so.2+0xb49) The problem is that glibc changed the calling convention for the GLIBC_PRIVATE symbol that sanitizer uses (even when it should not, GLIBC_PRIVATE is exactly for symbols that can change at any time, be removed etc.), see https://sourceware.org/ml/libc-alpha/2017-08/msg00497.html Fixes https://github.com/google/sanitizers/issues/954 Patch By: Jakub Jelinek Reviewed By: vitalybuka, Lekensteyn Differential Revison: https://reviews.llvm.org/D44623 llvm-svn: 334363
* [MSan] Report proper error on allocator failures instead of CHECK(0)-ingAlex Shlyapnikov2018-06-088-25/+78
| | | | | | | | | | | | | | | | | | Summary: Following up on and complementing D44404. Currently many allocator specific errors (OOM, for example) are reported as a text message and CHECK(0) termination, not stack, no details, not too helpful nor informative. To improve the situation, detailed and structured errors were defined and reported under the appropriate conditions. Reviewers: eugenis Subscribers: srhines, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D47793 llvm-svn: 334338
* [asan, myriad] Use local pool for new/delete when ASan run-time is not upWalter Lee2018-06-083-4/+73
| | | | | | | | This can happen on Myriad RTEMS so needs to be handled. Differential Revision: https://reviews.llvm.org/D47916 llvm-svn: 334329
* [Sanitizers] Check alignment != 0 for aligned_alloc and posix_memalignAlex Shlyapnikov2018-06-0811-5/+78
| | | | | | | | | | | | | | | Summary: Move the corresponding tests to the common folder (as all of the sanitizer allocators will support this feature soon) and add the checks specific to aligned_alloc to ASan and LSan allocators. Reviewers: vitalybuka Subscribers: srhines, kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D47924 llvm-svn: 334316
* [Xray] logging forgotten headerDavid Carlier2018-06-081-0/+1
| | | | | | | | | | | | pthread.h missing for pthread_key* functions. Reviewers: dberris Reviewed By: dberris Differential Revison: https://reviews.llvm.org/D47933 llvm-svn: 334272
* [XRay][compiler-rt] Cleanup some internal XRay utilitiesDean Michael Berris2018-06-082-7/+7
| | | | | | | This change uses 'const' for the retryingWriteAll(...) API and removes unnecessary 'static' local variables in getting the temporary filename. llvm-svn: 334267
* [XRay][compiler-rt] Remove reliance on C++ ABI featuresDean Michael Berris2018-06-082-115/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes http://llvm.org/PR32274. This change adds a test to ensure that we're able to link XRay modes and the runtime to binaries that don't need to depend on the C++ standard library or a C++ ABI library. In particular, we ensure that this will work with C programs compiled+linked with XRay. To make the test pass, we need to change a few things in the XRay runtime implementations to remove the reliance on C++ ABI features. In particular, we change the thread-safe function-local-static initialisation to use pthread_* instead of the C++ features that ensure non-trivial thread-local/function-local-static initialisation. Depends on D47696. Reviewers: dblaikie, jfb, kpw, eizan Reviewed By: kpw Subscribers: echristo, eizan, kpw, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46998 llvm-svn: 334262
* [HWASan] Report proper error on allocator failures instead of CHECK(0)-ingAlex Shlyapnikov2018-06-078-35/+89
| | | | | | | | | | | | | | | | Summary: Currently many allocator specific errors (OOM, for example) are reported as a text message and CHECK(0) termination, not stack, no details, not too helpful nor informative. To improve the situation, detailed and structured errors were defined and reported under the appropriate conditions. Reviewers: eugenis Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D47798 llvm-svn: 334248
* [libFuzzer] When printing NEW_FUNC, use 1-base indexing.Kostya Serebryany2018-06-071-1/+1
| | | | | | | | | | | | | | Summary: Otherwise we print things like [0/1] which is visually confusing. Reviewers: kcc Reviewed By: kcc Subscribers: delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D47837 llvm-svn: 334234
* Silence a -Wconstant-logical-operand warning.Douglas Yung2018-06-071-3/+3
| | | | llvm-svn: 334214
* [Fuzzer] Update the header path for fdio/spawn.h on FuchsiaPetr Hosek2018-06-071-1/+1
| | | | | | | | The path now includes lib/ prefix. Differential Revision: https://reviews.llvm.org/D47866 llvm-svn: 334213
* Disable recursive interceptors in signal(3)/MSanKamil Rytarowski2018-06-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: signal(3) on NetBSD calls internally sigaction(2). Without disabling the recursive interceptor, there are false positives about uninitialized memory reads inside libc. This change fixes execution of such programs as sh(1) and vmstat(1) in the NetBSD userland. Sponsored by <The NetBSD Foundation> Reviewers: eugenis, vitalybuka, joerg Reviewed By: vitalybuka Subscribers: llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D47650 llvm-svn: 334168
* [libFuzzer] make the corpus elements aware of their data flow tracesKostya Serebryany2018-06-075-5/+41
| | | | llvm-svn: 334158
* [sanitizer] Don't use internal_unlink on WindowsVitaly Buka2018-06-071-8/+12
| | | | llvm-svn: 334152
* [libFuzzer] remove an experimental flag -use_feature_frequencyKostya Serebryany2018-06-065-30/+1
| | | | llvm-svn: 334146
* [Fuzzer] Use private libc++ even for FuchsiaPetr Hosek2018-06-061-7/+2
| | | | | | | | | | | On Fuchsia, we use libc++ compiled with ASan for our ASan built executable which means we cannot use the same libc++ for libFuzzer when building fuzz targets, instead we'll link a custom internal libc++ into Fuchsia's build of libFuzzer like we already do on Linux. Differential Revision: https://reviews.llvm.org/D47835 llvm-svn: 334144
* [CMake] Passthrough additional flags to custom libcxx CMake buildPetr Hosek2018-06-061-0/+1
| | | | | | | | This is needed when we're cross-compiling compiler-rt. Differential Revision: https://reviews.llvm.org/D47834 llvm-svn: 334139
* [sanitizer] Replace deprecated mktemp with mkstempVitaly Buka2018-06-061-1/+1
| | | | llvm-svn: 334138
* [sanitizer] Cleanup ReadFileToVector and ReadFileToBufferVitaly Buka2018-06-065-45/+109
| | | | | | | | | | | | | | | Summary: Added unit-test. Fixed behavior of max_len argument. Call read syscall with all available buffer, not just a page. Reviewers: eugenis Subscribers: kubamracek, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46618 llvm-svn: 334130
* [asan] Fix Myraid RTEMS port broken by r333985Walter Lee2018-06-061-0/+1
| | | | | | Add nop CheckASLR() function. llvm-svn: 334102
* Fix compile error with libstdc++.Ilya Biryukov2018-06-061-0/+5
| | | | | | | | | | By adding a ctor to create fuzzer_allocator<T> from fuzzer_allocator<U>. This mimics construcotrs of std::allocator<T>. Without the constructors, some versions of libstdc++ can't compile `vector<bool, fuzzer_allocator<bool>>`. llvm-svn: 334077
* [XRay][compiler-rt] Refactor recursion guard for Basic and FDR ModeDean Michael Berris2018-06-064-36/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change extracts the recursion guard implementation from FDR Mode and updates it to do the following: - Do the atomic operation correctly to be signal-handler safe. - Make it usable in both FDR and Basic Modes. Before this change, the recursion guard relied on an unsynchronised read and write on a volatile thread-local. A signal handler could then run in between the read and the write, and then be able to run instrumented code as part of the signal handling. Using an atomic exchange instead fixes that by doing a proper mutual exclusion even in the presence of signal handling. Reviewers: kpw, eizan, jfb Reviewed By: eizan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47696 llvm-svn: 334064
* [libFuzzer] initial implementation of -data_flow_trace. It parses the data ↵Kostya Serebryany2018-06-0613-2/+188
| | | | | | flow trace and prints the summary, but doesn't use the information in any other way yet llvm-svn: 334058
* [lsan] Do not check for leaks in the forked processVitaly Buka2018-06-051-0/+9
| | | | | | | | | | | | | | | | Summary: If calling process had threads then forked process will fail to detect references from them. Fixes https://github.com/google/sanitizers/issues/836 Reviewers: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47751 llvm-svn: 334036
* [LSan] Report proper error on allocator failures instead of CHECK(0)-ingAlex Shlyapnikov2018-06-056-27/+211
| | | | | | | | | | | | | | | | | | Summary: Following up on and complementing D44404. Currently many allocator specific errors (OOM, for example) are reported as a text message and CHECK(0) termination, not stack, no details, not too helpful nor informative. To improve the situation, detailed and structured errors were defined and reported under the appropriate conditions. Reviewers: eugenis Subscribers: srhines, mgorny, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D47645 llvm-svn: 334034
* [XRay][compiler-rt] Use DCHECK instead of assert(...) (NFC)Dean Michael Berris2018-06-051-10/+8
| | | | | | Use DCHECK instead of assert(...) in the XRay runtime. llvm-svn: 334002
* [XRay][compiler-rt] Use static instead of inline (NFC)Dean Michael Berris2018-06-051-13/+12
| | | | | | | | | | We don't actually need to support multiple definitions of the functions in FDR mode, but rather want to make sure that the implementation-detail functions are marked as 'static' instead. This allows the inliner to do its magic better for these functions too, since inline functions must have a unique address across translation units. llvm-svn: 334001
* [XRay][compiler-rt] Remove __xray:: in some places (NFC)Dean Michael Berris2018-06-052-12/+12
| | | | | | | This is a cosmetic change to remove unnecessary full-qualifications of types/functions that are already in the __xray:: namespace. llvm-svn: 334000
* [XRay][compiler-rt] Remove namespace __xray_fdr_internal (NFC)Dean Michael Berris2018-06-051-46/+5
| | | | | | We no longer need the __xray_fdr_internal namespace. llvm-svn: 333998
* [XRay][compiler-rt] Merge XRay FDR mode into a single file (NFC)Dean Michael Berris2018-06-053-740/+737
| | | | | | | | | | | | | We planned to have FDR mode's internals unit-tested but it turns out that we can just use end-to-end testing to verify the implementation. We're going to move towards that approach more and more going forward, so we're merging the implementation details of FDR mode into a single .cc file. We also avoid globbing in the XRay test helper macro, and instead list down the files from the lib directory. llvm-svn: 333986
* Introduce CheckASLR() in sanitizersKamil Rytarowski2018-06-058-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: At least the ASan, MSan, TSan sanitizers require disabled ASLR on a NetBSD. Introduce a generic CheckASLR() routine, that implements a check for the current process. This flag depends on the global or per-process settings. There is no simple way to disable ASLR in the build process from the level of a sanitizer or during the runtime execution. With ASLR enabled sanitizers that operate over the process virtual address space can misbehave usually breaking with cryptic messages. This check is dummy for !NetBSD. Sponsored by <The NetBSD Foundation> Reviewers: vitalybuka, joerg Reviewed By: vitalybuka Subscribers: cryptoad, kubamracek, llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D47442 llvm-svn: 333985
OpenPOWER on IntegriCloud