summaryrefslogtreecommitdiffstats
path: root/compiler-rt/test/asan
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [compiler-rt] [test] Disable ASLR on ASAN/MSAN/TSAN tests on NetBSDMichał Górny2019-12-061-0/+3
| | | | | | | | 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
* [Symbolizers] On Darwin compute function offset when possible.Dan Liew2019-11-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ASan] Mark test as UNSUPPORTED for iOS simulatorJulian Lettner2019-11-181-0/+1
| | | | | | coverage-fork.cpp uses `fork()` which requires additional permissions in the iOS simulator sandbox. We cannot use `sandbox-exec` to grant these permissions since this is a Posix (not Darwin) test.
* [GCOV] Skip artificial functions from being emittedAlexandre Ganea2019-11-151-3/+0
| | | | | | | | This is a patch to support D66328, which was reverted until this lands. Enable a compiler-rt test that used to fail previously with D66328. Differential Revision: https://reviews.llvm.org/D67283
* Reland "[compiler-rt] Fix tests after 03b84e4f6d0"Jan Korous2019-11-081-1/+1
| | | | This reverts commit d6be9273c6035c07b25dd1494f76cd61d523b878.
* Revert "[compiler-rt] Fix tests after 03b84e4f6d0"Jeremy Morse2019-11-081-1/+1
| | | | | | This reverts commit bdeb2724f0aa9c518f94d998d24d8620a1e88727. (Reverting 03b84e4f6d0, so this must come out as well)
* [compiler-rt] Fix tests after 03b84e4f6d0Jan Korous2019-11-071-1/+1
| | | | | | | Fallout from: [clang] Report sanitizer blacklist as a dependency in cc1 Default blacklists are now passed via -fsanitize-system-blacklist from driver to cc1.
* [asan] Provide an interface to update an allocation stack trace.Evgenii Stepanov2019-10-311-0/+19
| | | | | | | | | | | | | | Summary: Sometimes an allocation stack trace is not very informative. Provide a way to replace it with a stack trace of the user's choice. Reviewers: pcc, kcc Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69208
* Add missing lld checks in sanitizer tests.Evgenii Stepanov2019-10-281-1/+1
| | | | | | Do not add an lld dependency when this target does not exist. In this case the system installation of lld is used (or whatever is detected with -fuse-ld=lld by default).
* [asan] Update Windows test expectations for LLVM's MS demanglerReid Kleckner2019-10-172-4/+4
| | | | | | | | After r375041 llvm-symbolizer uses it for demangling instead of UnDecorateSymbolName. LLVM puts spaces after commas while Microsoft does not. llvm-svn: 375147
* Reland "[ASan] Do not misrepresent high value address dereferences as null ↵Julian Lettner2019-10-101-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | dereferences" Updated: Removed offending TODO comment. Dereferences with addresses above the 48-bit hardware addressable range produce "invalid instruction" (instead of "invalid access") hardware exceptions (there is no hardware address decoding logic for those bits), and the address provided by this exception is the address of the instruction (not the faulting address). The kernel maps the "invalid instruction" to SEGV, but fails to provide the real fault address. Because of this ASan lies and says that those cases are null dereferences. This downgrades the severity of a found bug in terms of security. In the ASan signal handler, we can not provide the real faulting address, but at least we can try not to lie. rdar://50366151 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D68676 > llvm-svn: 374265 llvm-svn: 374384
* Revert "[ASan] Do not misrepresent high value address dereferences as null ↵Russell Gallop2019-10-101-50/+0
| | | | | | | | | | dereferences" As it was breaking bots running sanitizer lint check This reverts r374265 (git b577efe4567f1f6a711ad36e1d17280dd1c4f009) llvm-svn: 374308
* [ASan] Do not misrepresent high value address dereferences as null dereferencesJulian Lettner2019-10-101-0/+50
| | | | | | | | | | | | | | | | | | | | | | Dereferences with addresses above the 48-bit hardware addressable range produce "invalid instruction" (instead of "invalid access") hardware exceptions (there is no hardware address decoding logic for those bits), and the address provided by this exception is the address of the instruction (not the faulting address). The kernel maps the "invalid instruction" to SEGV, but fails to provide the real fault address. Because of this ASan lies and says that those cases are null dereferences. This downgrades the severity of a found bug in terms of security. In the ASan signal handler, we can not provide the real faulting address, but at least we can try not to lie. rdar://50366151 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D68676 llvm-svn: 374265
* [CMake] Fix the value of `config.target_cflags` for non-macOS Apple ↵Dan Liew2019-10-011-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | platforms. Attempt #3. The main problem here is that `-*-version_min=` was not being passed to the compiler when building test cases. This can cause problems when testing on devices running older OSs because Clang would previously assume the minimum deployment target is the the latest OS in the SDK which could be much newer than what the device is running. Previously the generated value looked like this: `-arch arm64 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` With this change it now looks like: `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` This mirrors the setting of config.target_cflags on macOS. This change is made for ASan, LibFuzzer, TSan, and UBSan. To implement this a new `get_test_cflags_for_apple_platform()` function has been added that when given an Apple platform name and architecture returns a string containing the C compiler flags to use when building tests. This also calls a new helper function `is_valid_apple_platform()` that validates Apple platform names. This is the third attempt at landing the patch. The first attempt (r359305) had to be reverted (r359327) due to a buildbot failure. The problem was that calling `get_test_cflags_for_apple_platform()` can trigger a CMake error if the provided architecture is not supported by the current CMake configuration. Previously, this could be triggered by passing `-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were generating test configurations for a list of architectures without checking if the relevant Sanitizer actually supported that architecture. We now intersect the list of architectures for an Apple platform with `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer name) to iterate through the correct list of architectures. The second attempt (r363633) had to be reverted (r363779) due to a build failure. The failed build was using a modified Apple toolchain where the iOS simulator SDK was missing. This exposed a bug in the existing UBSan test generation code where it was assumed that `COMPILER_RT_ENABLE_IOS` implied that the toolchain supported both iOS and the iOS simulator. This is not true. This has been fixed by using the list `SANITIZER_COMMON_SUPPORTED_OS` for the list of supported Apple platforms for UBSan. For consistency with the other Sanitizers we also now intersect the list of architectures with UBSAN_SUPPORTED_ARCH. rdar://problem/50124489 Differential Revision: https://reviews.llvm.org/D61242 llvm-svn: 373405
* Avoid memory leak in ASan testKamil Rytarowski2019-09-211-0/+1
| | | | | | | | | | | | | | | | | | | Summary: Add missing free(3) for the malloc(3) call. Detected on NetBSD with LSan. Reviewers: joerg, mgorny, vitalybuka, dvyukov Reviewed By: vitalybuka Subscribers: llvm-commits, #sanitizers Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67330 llvm-svn: 372460
* [compiler-rt] Remove some cpplint filtersVitaly Buka2019-09-121-2/+2
| | | | llvm-svn: 371704
* Remove NOLINTs from compiler-rtVitaly Buka2019-09-115-6/+6
| | | | llvm-svn: 371687
* Update compiler-rt cpplint.pyVitaly Buka2019-09-113-5/+5
| | | | | | https://github.com/cpplint/cpplint/commit/adb3500107f409ac5491188ae652ac3f4d03d9d3 llvm-svn: 371675
* Enable LSan for NetBSD/i386 in test/asan/lit.cfg.pyKamil Rytarowski2019-09-081-1/+1
| | | | llvm-svn: 371354
* Stop marking 5 ASan tests as failing on NetBSD/i386Kamil Rytarowski2019-09-084-6/+0
| | | | | | | | | | Unexpected Passing Tests (4): AddressSanitizer-i386-netbsd :: TestCases/Posix/coverage-reset.cpp AddressSanitizer-i386-netbsd :: TestCases/Posix/coverage.cpp AddressSanitizer-i386-netbsd :: TestCases/Posix/interception-in-shared-lib-test.cpp AddressSanitizer-i386-netbsd :: TestCases/suppressions-library.cpp llvm-svn: 371337
* [ASan] Only run dlopen-mixed-c-cxx.c with static runtimeJonas Hahnfeld2019-09-081-2/+3
| | | | | | | | | | | | | | This is what the original bug (http://llvm.org/PR39641) and the fix in https://reviews.llvm.org/D63877 have been about. With the dynamic runtime the test only passes when the asan library is linked against libstdc++: In contrast to libc++abi, it does not implement __cxa_rethrow_primary_exception so the regex matches the line saying that asan cannot intercept this function. Indeed, there is no message that the runtime failed to intercept __cxa_throw. Differential Revision: https://reviews.llvm.org/D67298 llvm-svn: 371336
* Enable leak-detection for NetBSD/amd64 in test/asanKamil Rytarowski2019-09-081-1/+2
| | | | llvm-svn: 371335
* Further relax checks in asan-symbolize-bad-path.cppAlexander Richardson2019-08-281-2/+2
| | | | | | | | | | It turns out that the DarwinSymbolizer does not print the "in" part for invalid files but instead prints #0 0xabcdabcd (.../asan-symbolize-bad-path.cpp.tmp/bad/path:i386+0x1234) This tests is only checking that asan_symbolize.py doesn't hang or crash, so further relax the checks to ensure that the test passes on macOS. llvm-svn: 370243
* Fix asan-symbolize-bad-path.cpp on DarwinAlexander Richardson2019-08-271-1/+2
| | | | | | | | I accidentally made the CHECK line stricter when committing D65322. While it happens to work for Linux and FreeBSD, it broke on Darwin. This commit restores the previous behaviour. llvm-svn: 370110
* Relax test introduced in D65322Alexander Richardson2019-08-271-2/+2
| | | | | | | | | | | It is possible that addr2line returns a valid function and file name for the passed address on some build configuations. The test is only checking that asan_symbolize doesn't assert any more when passed a valid file with an invalid address so there is no need to check that it can't find a valid function name. This should fix http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux llvm-svn: 370021
* [asan_symbolize] Avoid blocking when llvm-symbolizer is installed as addr2lineAlexander Richardson2019-08-261-2/+13
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently, llvm-symbolizer will print -1 when presented with -1 and not print a second line. In that case we will block for ever trying to read the file name. This also happens for non-existent files, in which case GNU addr2line exits immediate, but llvm-symbolizer does not (see https://llvm.org/PR42754). While touching these lines, I also added some more debug logging to help diagnose this and potential future issues. Reviewers: kcc, eugenis, glider, samsonov Reviewed By: eugenis Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D65322 llvm-svn: 369924
* [sanitizer_common] Extend test after switch to posix_spawnJulian Lettner2019-08-191-0/+2
| | | | llvm-svn: 369311
* [sanitizer_common] Replace forkpty with posix_spawn on DarwinJulian Lettner2019-08-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | On Darwin, we currently use forkpty to communicate with the "atos" symbolizer. There are several problems that fork[pty] has, e.g. that after fork, interceptors are still active and this sometimes causes crashes or hangs. This is especially problematic for TSan, which uses interceptors for OS-provided locks and mutexes, and even Libc functions use those. This patch replaces forkpty with posix_spawn on Darwin. Since posix_spawn doesn't fork (at least on Darwin), the interceptors are not a problem. Another benefit is that we'll handle post-fork failures (e.g. sandbox disallows "exec") gracefully now. Related revisions and previous attempts that were blocked by or had to be revered due to test failures: https://reviews.llvm.org/D48451 https://reviews.llvm.org/D40032 Reviewed By: kubamracek Differential Revision: https://reviews.llvm.org/D65253 llvm-svn: 368947
* [asan_symbolize] Fix bug where the frame counter was not incremented.Dan Liew2019-08-122-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This bug occurred when a plug-in requested that a binary not be symbolized while the script is trying to symbolize a stack frame. In this case `self.frame_no` would not be incremented. This would cause subsequent stack frames that are symbolized to be incorrectly numbered. To fix this `get_symbolized_lines()` has been modified to take an argument that indicates whether the stack frame counter should incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)` is now used in in the case where we don't want to symbolize a line so that we can keep the frame counter increment in a single function. A test case is included. The test uses a dummy plugin that always asks `asan_symbolize.py` script to not symbolize the first binary that the script asks about. Prior to the patch this would cause the output to script to look something like ``` #0 0x0 #0 0x0 in do_access #1 0x0 in main ``` This is the second attempt at landing this patch. The first (r368373) failed due to failing some android bots and so was reverted in r368472. The new test is now disabled for Android. It turns out that the patch also fails for iOS too so it is also disabled for that family of platforms too. rdar://problem/49476995 Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D65495 llvm-svn: 368603
* Add support for FreeBSD's LD_32_LIBRARY_PATHDimitry Andric2019-08-102-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Because the dynamic linker for 32-bit executables on 64-bit FreeBSD uses the environment variable `LD_32_LIBRARY_PATH` instead of `LD_LIBRARY_PATH` to find needed dynamic libraries, running the 32-bit parts of the dynamic ASan tests will fail with errors similar to: ``` ld-elf32.so.1: Shared object "libclang_rt.asan-i386.so" not found, required by "Asan-i386-inline-Dynamic-Test" ``` This adds support for setting up `LD_32_LIBRARY_PATH` for the unit and regression tests. It will likely also require a minor change to the `TestingConfig` class in `llvm/utils/lit/lit`. Reviewers: emaste, kcc, rnk, arichardson Reviewed By: arichardson Subscribers: kubamracek, krytarowski, fedor.sergeev, delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D65772 llvm-svn: 368516
* Revert "[asan_symbolize] Fix bug where the frame counter was not incremented."Mitch Phillips2019-08-092-79/+0
| | | | | | | | | This reverts commit 52a36fae2a3f8560a5be690a67304db5edafc3fe. This commit broke the sanitizer_android buildbot. See comments at https://reviews.llvm.org/rL368373 for more details. llvm-svn: 368472
* [asan_symbolize] Fix bug where the frame counter was not incremented.Dan Liew2019-08-092-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This bug occurred when a plug-in requested that a binary not be symbolized while the script is trying to symbolize a stack frame. In this case `self.frame_no` would not be incremented. This would cause subsequent stack frames that are symbolized to be incorrectly numbered. To fix this `get_symbolized_lines()` has been modified to take an argument that indicates whether the stack frame counter should incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)` is now used in in the case where we don't want to symbolize a line so that we can keep the frame counter increment in a single function. A test case is included. The test uses a dummy plugin that always asks `asan_symbolize.py` script to not symbolize the first binary that the script asks about. Prior to the patch this would cause the output to script to look something like ``` #0 0x0 #0 0x0 in do_access #1 0x0 in main ``` rdar://problem/49476995 Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D65495 llvm-svn: 368373
* compiler-rt: Remove .cc from all lit config filesNico Weber2019-08-051-1/+1
| | | | | | All cc files have been renamed to cpp now. llvm-svn: 367911
* compiler-rt: Rename cc files below test/asan to cppNico Weber2019-08-05418-348/+348
| | | | | | See r367803 and similar other changes. llvm-svn: 367887
* compiler-rt: Rename cc files below test/sanitizer_common to cppNico Weber2019-08-051-1/+1
| | | | | | See r367803 and similar other changes. llvm-svn: 367863
* compiler-rt: Rename .cc file in lib/asan to .cppNico Weber2019-08-011-3/+3
| | | | | | Like r367463, but for asan. llvm-svn: 367558
* [Sanitizer][ASAN][MSAN] Fix infinite recursion on FreeBSDAlexander Richardson2019-07-312-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: MSAN was broken on FreeBSD by https://reviews.llvm.org/D55703: after this change accesses to the key variable call __tls_get_addr, which is intercepted. The interceptor then calls GetCurrentThread which calls MsanTSDGet which again calls __tls_get_addr, etc... Using the default implementation in the SANITIZER_FREEBSD case fixes MSAN for me. I then applied the same change to ASAN (introduced in https://reviews.llvm.org/D55596) but that did not work yet. In the ASAN case, we get infinite recursion again during initialization, this time because calling pthread_key_create() early on results in infinite recursion. pthread_key_create() calls sysctlbyname() which is intercepted but COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED returns true, so the interceptor calls internal_sysctlbyname() which then ends up calling the interceptor again. I fixed this issue by using dlsym() to get the libc version of sysctlbyname() instead. This fixes https://llvm.org/PR40761 Reviewers: vitalybuka, krytarowski, devnexen, dim, bsdjhb, #sanitizers, MaskRay Reviewed By: MaskRay Subscribers: MaskRay, emaste, kubamracek, jfb, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D65221 llvm-svn: 367442
* [ASan][test] XFAIL AddressSanitizer-*-sunos :: ↵Rainer Orth2019-07-301-0/+2
| | | | | | | | | | | | | | | | TestCases/intercept-rethrow-exception.cc on Solaris AddressSanitizer-*-sunos :: TestCases/intercept-rethrow-exception.cc currently FAILs on Solaris. This happens because std::rethrow_exception cannot be intercepted, as detailed in Bug 42703. To account for this and reduce testsuite noise, this patch XFAILs the test. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D65056 llvm-svn: 367293
* [NFC][ASAN] Add brackets around not commandLei Huang2019-07-231-1/+1
| | | | | | | | | Under certain execution conditions, the `not` command binds to the command the output is piped to rather than the command piping the output. In this case, that flips the return code of the FileCheck invocation, causing a failure when FileCheck succeeds. llvm-svn: 366805
* Fix asan infinite loop on undefined symbolSerge Guelton2019-07-201-0/+43
| | | | | | | | | | | | Fix llvm#39641 Recommit of r366413 Differential Revision: https://reviews.llvm.org/D63877 > llvm-svn: 366632 llvm-svn: 366638
* Revert "Fix asan infinite loop on undefined symbol"Serge Guelton2019-07-201-43/+0
| | | | | | | | This reverts commit cbd28cd05bb11e9d76d71c6cc2d38d89dbb1fe1a. Buildbot fail: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/22434/steps/64-bit%20check-asan-dynamic/ llvm-svn: 366634
* Fix asan infinite loop on undefined symbolSerge Guelton2019-07-201-0/+43
| | | | | | | | | | Fix llvm#39641 Recommit of r366413 Differential Revision: https://reviews.llvm.org/D63877 llvm-svn: 366632
* Revert "Fix asan infinite loop on undefined symbol"Matthew Voss2019-07-191-42/+0
| | | | | | | | This reverts commit 8e46275488ca453a24964cb26be0736172ad1db8. This was failing on sanitizer-x86_64-linux and our internal CI. llvm-svn: 366618
* Fix asan infinite loop on undefined symbolSerge Guelton2019-07-191-0/+42
| | | | | | | | | | Fix llvm#39641 Recommit of r366413 Differential Revision: https://reviews.llvm.org/D63877 llvm-svn: 366588
* [compiler-rt] Complete revert of r366413Matthew Voss2019-07-181-42/+0
| | | | | | | Incomplete revert. Mea culpa. This test is failing on sanitizer-x86_64-linux and our internal CI. llvm-svn: 366482
* Restrict asan + dlopen testcase to x86Serge Guelton2019-07-181-2/+2
| | | | llvm-svn: 366436
* Relax regexp to detect failed interception by asanSerge Guelton2019-07-181-1/+1
| | | | | | This should fix failed detection on aarch64/ppc64/thumbv8... llvm-svn: 366432
* Fix asan infinite loop on undefined symbolSerge Guelton2019-07-181-0/+42
| | | | | | | | Fix llvm#39641 Differential Revision: https://reviews.llvm.org/D63877 llvm-svn: 366413
* Enable compiler-rt on SPARCRainer Orth2019-07-121-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables compiler-rt on SPARC targets. Most of the changes are straightforward: - Add 32 and 64-bit sparc to compiler-rt - lib/builtins/fp_lib.h needed to check if the int128_t and uint128_t types exist (which they don't on sparc) There's one issue of note: many asan tests fail to compile on Solaris/SPARC: fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported. Therefore, while asan is still built, both asan and ubsan-with-asan testing is disabled. The goal is to check if asan keeps compiling on Solaris/SPARC. This serves asan in gcc, which doesn't have the problem above and works just fine. With this patch, sparcv9-sun-solaris2.11 test results are pretty good: Failing Tests (9): Builtins-sparc-sunos :: divtc3_test.c Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c Builtins-sparcv9-sunos :: divtc3_test.c [...] UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp The builtin failures are due to Bugs 42493 and 42496. The tree contained a few additonal patches either currently in review or about to be submitted. Tested on sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D40943 llvm-svn: 365880
OpenPOWER on IntegriCloud