summaryrefslogtreecommitdiffstats
path: root/clang/test/Driver/fsanitize.c
Commit message (Collapse)AuthorAgeFilesLines
...
* CFI: Introduce -fsanitize=cfi-icall flag.Peter Collingbourne2015-09-101-1/+4
| | | | | | | | | | This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism. Differential Revision: http://reviews.llvm.org/D11857 llvm-svn: 247238
* Add an experimental flag -fsanitize-memory-use-after-dtor.Evgeniy Stepanov2015-07-101-0/+3
| | | | | | | | | | | This flag will enable detection of use-after-destructor (but before memory deallocation) bugs. No actual functionality yet. https://code.google.com/p/address-sanitizer/issues/detail?id=73 Patch by Naomi Musgrave. llvm-svn: 241935
* Driver: enable support for -fsanitize=cfi on Windows.Peter Collingbourne2015-07-081-0/+4
| | | | | | | | | There are known issues, but the current implementation is good enough for the check-cfi test suite. Differential Revision: http://reviews.llvm.org/D11030 llvm-svn: 241728
* Driver: add support for linking the UBSan runtime library on Windows.Peter Collingbourne2015-07-021-0/+9
| | | | | | | | | | | | | | On Windows the user may invoke the linker directly, so we might not have an opportunity to add runtime library flags to the linker command line. Instead, instruct the code generator to embed linker directive in the object file that cause the required runtime libraries to be linked. We might also want to do something similar for ASan, but it seems to have its own special complexities which may make this infeasible. Differential Revision: http://reviews.llvm.org/D10862 llvm-svn: 241225
* [CFI] Diagnose when we CFI in diagnostic mode is unavailable on a toolchain.Alexey Samsonov2015-06-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: Namely, we must have proper C++ABI support in UBSan runtime. We don't have a good way to check for that, so just assume that C++ABI support is there whenever -fsanitize=vptr is supported (i.e. only on handful of platforms). Exact diagnostic is also tricky. It's not "cfi" that is unsupported, just the diagnostic mode. So, I suggest to report that "-fno-sanitize-trap=cfi-foobar" is incompatible with a given target toolchain. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10751 llvm-svn: 240716
* Teach Clang about the PPC64 memory sanitizer implementation.Jay Foad2015-06-251-0/+4
| | | | | | | | | | | | | | | | Summary: This is the Clang part of the PPC64 memory sanitizer implementation in D10648. Reviewers: kcc, eugenis, willschm, wschmidt, samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10650 llvm-svn: 240628
* [UBSan] Allow to use -fsanitize=vptr only on Mac OS 10.9+Alexey Samsonov2015-06-251-1/+7
| | | | | | | See https://llvm.org/bugs/show_bug.cgi?id=23539 for why this is necessary. llvm-svn: 240618
* [Sanitizers] Provide better diagnostic for sanitizers unsupported for target ↵Alexey Samsonov2015-06-191-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | triple. Introduce ToolChain::getSupportedSanitizers() that would return the set of sanitizers available on given toolchain. By default, these are sanitizers which don't necessarily require runtime support and are not toolchain- or architecture-dependent. Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function without runtime library are marked as supported only on platforms for which we actually build these runtimes. This would allow more fine-grained checks in the future: for instance, we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+ (PR23539). Update test cases accrodingly: add tests for certain unsupported configurations, remove test cases for -fsanitize=vptr + PS4 integration, as we don't build the runtime for PS4 at the moment. This change was first submitted as r239953 and reverted in r239958. The problem was and still is in Darwin toolchains, which get the knowledge about target platform too late after initializaition, while now we require this information when ToolChain::getSanitizerArgs() is called. r240170 works around this issue. llvm-svn: 240179
* [CFI] Require -flto instead of implying it.Alexey Samsonov2015-06-191-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is unfortunate, but would let us land http://reviews.llvm.org/D10467, that makes ToolChains responsible for computing the set of sanitizers they support. Unfortunately, Darwin ToolChains doesn't know about actual OS they target until ToolChain::TranslateArgs() is called. In particular, it means we won't be able to construct SanitizerArgs for these ToolChains before that. This change removes SanitizerArgs::needsLTO() method, so that now ToolChain::IsUsingLTO(), which is called very early, doesn't need SanitizerArgs to implement this method. Docs and test cases are updated accordingly. See https://llvm.org/bugs/show_bug.cgi?id=23539, which describes why we start all these. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10560 llvm-svn: 240170
* [ASan] Initial support for Kernel AddressSanitizerAlexander Potapenko2015-06-191-0/+12
| | | | | | | | | This patch adds initial support for the -fsanitize=kernel-address flag to Clang. Right now it's quite restricted: only out-of-line instrumentation is supported, globals are not instrumented, some GCC kasan flags are not supported. Using this patch I am able to build and boot the KASan tree with LLVMLinux patches from github.com/ramosian-glider/kasan/tree/kasan_llvmlinux. To disable KASan instrumentation for a certain function attribute((no_sanitize("kernel-address"))) can be used. llvm-svn: 240131
* Introduce -fsanitize-trap= flag.Peter Collingbourne2015-06-181-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
* Revert "[Sanitizers] Provide better diagnostic for sanitizers unsupported ↵Alexey Samsonov2015-06-171-8/+2
| | | | | | | | | for target triple." This reverts commit r239953, while I'm investigating assertion failure from http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/9994/ llvm-svn: 239958
* [Sanitizers] Provide better diagnostic for sanitizers unsupported for target ↵Alexey Samsonov2015-06-171-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | triple. Summary: Introduce ToolChain::getSupportedSanitizers() that would return the set of sanitizers available on given toolchain. By default, these are sanitizers which don't necessarily require runtime support (i.e. set from -fsanitize=undefined-trap). Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function without runtime library are marked as supported only on platforms for which we actually build these runtimes. This would allow more fine-grained checks in the future: for instance, we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+ (PR23539) Update test cases accrodingly: add tests for certain unsupported configurations, remove test cases for -fsanitize=vptr + PS4 integration, as we don't build the runtime for PS4 at the moment. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits, filcab, eugenis, thakis, kubabrecka, emaste, rsmith Differential Revision: http://reviews.llvm.org/D10467 llvm-svn: 239953
* Protection against stack-based memory corruption errors using SafeStack: ↵Peter Collingbourne2015-06-151-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Clang command line option and function attribute This patch adds the -fsanitize=safe-stack command line argument for clang, which enables the Safe Stack protection (see http://reviews.llvm.org/D6094 for the detailed description of the Safe Stack). This patch is our implementation of the safe stack on top of Clang. The patches make the following changes: - Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang to control safe stack usage (the safe stack is disabled by default). - Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be used to disable the safe stack for individual functions even when enabled globally. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6095 llvm-svn: 239762
* [Driver] Improve unused-argument diagnostic for extra sanitizer features.Alexey Samsonov2015-05-211-0/+6
| | | | | | | | | | | | | | | Don't print unused-argument warning for sanitizer-specific feature flag if this sanitizer was eanbled, and later disabled in the command line. For example, now: clang -fsanitize=address -fsanitize-coverage=bb -fno-sanitize=address a.cc doesn't print warning, but clang -fsanitize-coverage=bb does. Same holds for -fsanitize-address-field-padding= and -fsanitize-memory-track-origins= flags. Fixes PR23604. llvm-svn: 237870
* [SanitizerCoverage] Give clang-cc1 the power to precisly specify needed ↵Alexey Samsonov2015-05-071-26/+0
| | | | | | | | | | | | | | | | | | sanitizier coverage mode. Summary: The next step is to add user-friendly control over these options to driver via -fsanitize-coverage= option. Test Plan: regression test suite Reviewers: kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D9545 llvm-svn: 236756
* Allow UBSan+MSan and UBSan+TSan combinations (Clang part).Alexey Samsonov2015-04-281-3/+0
| | | | | | | | Embed UBSan runtime into TSan and MSan runtimes in the same as we do in ASan. Extend UBSan test suite to also run tests for these combinations. llvm-svn: 235953
* Implement CFI type checks for non-virtual calls.Peter Collingbourne2015-04-021-3/+5
| | | | | | | | | | | | This uses the same class metadata currently used for virtual call and cast checks. The new flag is -fsanitize=cfi-nvcall. For consistency, the -fsanitize=cfi-vptr flag has been renamed -fsanitize=cfi-vcall. Differential Revision: http://reviews.llvm.org/D8756 llvm-svn: 233874
* Make -fsanitize-coverage flag a core option so it's available via the ↵Timur Iskhodzhanov2015-03-271-0/+8
| | | | | | | | clang-cl driver too Reviewed at http://reviews.llvm.org/D8663 llvm-svn: 233384
* [UBSan] Don't allow to use UBSan with anything except for ASan.Alexey Samsonov2015-03-201-0/+3
| | | | | | | | | | We are not able to make a reliable solution for using UBSan together with other sanitizers with runtime support (and sanitizer_common). Instead, we want to follow the path used for LSan: have a "standalone" UBSan tool, and plug-in UBSan that would be explicitly embedded into specific sanitizers (in short term, it will be only ASan). llvm-svn: 232829
* Allow -fsanitize-coverage with -fsanitize=dataflowKostya Serebryany2015-03-201-1/+1
| | | | | | | | | | | | | | | | Summary: Allow -fsanitize-coverage with -fsanitize=dataflow Test Plan: check-clang Reviewers: pcc Reviewed By: pcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D8476 llvm-svn: 232787
* Implement bad cast checks using control flow integrity information.Peter Collingbourne2015-03-141-2/+7
| | | | | | | | | | | This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class. Differential Revision: http://reviews.llvm.org/D8312 llvm-svn: 232241
* Add deprecation notice for -f(no-)sanitize-recover flags.Alexey Samsonov2015-03-111-2/+7
| | | | | | | These flags should be replaced with corresponding -f(no-)sanitize-recover=<list> flags. llvm-svn: 231983
* [UBSan] Split -fsanitize=shift into -fsanitize=shift-base and ↵Alexey Samsonov2015-03-091-8/+11
| | | | | | | | | | | | | | | | -fsanitize=shift-exponent. This is a recommit of r231150, reverted in r231409. Turns out that -fsanitize=shift-base check implementation only works if the shift exponent is valid, otherwise it contains undefined behavior itself. Make sure we check that exponent is valid before we proceed to check the base. Make sure that we actually report invalid values of base or exponent if -fsanitize=shift-base or -fsanitize=shift-exponent is specified, respectively. llvm-svn: 231711
* Revert "[UBSan] Split -fsanitize=shift into -fsanitize=shift-base and ↵Alexey Samsonov2015-03-051-11/+8
| | | | | | | | | | | -fsanitize=shift-exponent." It's not that easy. If we're only checking -fsanitize=shift-base we still need to verify that exponent has sane value, otherwise UBSan-inserted checks for base will contain undefined behavior themselves. llvm-svn: 231409
* [UBSan] Split -fsanitize=shift into -fsanitize=shift-base and ↵Alexey Samsonov2015-03-031-8/+11
| | | | | | | | | | | | | | | | | | | | | -fsanitize=shift-exponent. -fsanitize=shift is now a group that includes both these checks, so exisiting users should not be affected. This change introduces two new UBSan kinds that sanitize only left-hand side and right-hand side of shift operation. In practice, invalid exponent value (negative or too large) tends to cause more portability problems, including inconsistencies between different compilers, crashes and inadequeate results on non-x86 architectures etc. That is, -fsanitize=shift-exponent failures should generally be addressed first. As a bonus, this change simplifies CodeGen implementation for emitting left shift (separate checks for base and exponent are now merged by the existing generic logic in EmitCheck()), and LLVM IR for these checks (the number of basic blocks is reduced). llvm-svn: 231150
* [msan] Change track-origins default mode from 1 to 2.Evgeniy Stepanov2015-02-261-4/+6
| | | | | | | | | | | Change -fsanitize-memory-track-origins to be equivalent to -fsanitize-memory-track-origins=2. Track-origins=2 provides a lot more detailed reports at the cost of some additional slowdown (ranging from none to, sometimes, 3x; ~3% average on SPEC2006). llvm-svn: 230644
* Implement Control Flow Integrity for virtual calls.Peter Collingbourne2015-02-201-0/+4
| | | | | | | | | | | | | | | This patch introduces the -fsanitize=cfi-vptr flag, which enables a control flow integrity scheme that checks that virtual calls take place using a vptr of the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst file. It also introduces the -fsanitize=cfi flag, which is currently a synonym for -fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented in Clang. Differential Revision: http://reviews.llvm.org/D7424 llvm-svn: 230055
* Improve our handling of rtti/sanitize=vptr/sanitize=undefinedFilipe Cabecinhas2015-02-191-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the huge blob of code that is dealing with rtti/exceptions/sanitizers and replaces it with: A ToolChain function which, for a given set of Args, figures out if rtti should be: - enabled - disabled implicitly - disabled explicitly A change in the way SanitizerArgs figures out what sanitizers to enable (or if it should error out, or warn); And a check for exceptions/rtti interaction inside addExceptionArgs. The RTTIMode algorithm is: - If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly; - If -frtti was passed or we're not targetting the PS4, rtti is enabled; - If -fexceptions or -fcxx-exceptions was passed and we're targetting the PS4, rtti was enabled implicitly; - If we're targetting the PS4, rtti is disabled implicitly; - Otherwise, rtti is enabled; Since the only flag needed to pass to -cc1 is -fno-rtti if we want to disable it, there's no problem in saying rtti is enabled if we're compiling C code, so we don't look at the input file type. addExceptionArgs now looks at the RTTIMode and warns that rtti is being enabled implicitly if targetting the PS4 and exceptions are on. It also errors out if, targetting the PS4, -fno-rtti was passed, and exceptions were turned on. SanitizerArgs now errors out if rtti was disabled explicitly and the vptr sanitizer was enabled implicitly, but just turns off vptr if rtti is disabled but -fsanitize=undefined was passed. Also fixed tests, removed duplicate name from addExceptionArgs comment, and added one or two surrounding lines when running clang-format. This changes test/Driver/fsanitize.c to make it not expect a warning when passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on. Removed all users and definition of SanitizerArgs::sanitizesVptr(). Reviewers: samsonov Subscribers: llvm-commits, samsonov, rsmith Differential Revision: http://reviews.llvm.org/D7525 llvm-svn: 229801
* Append -fno-assume-sane-operator-new in ASan builds.Sergey Matveev2015-02-171-0/+2
| | | | | | | This should help LSan detect leaks where operator new would otherwise be optimized out. llvm-svn: 229498
* Reimplement -fsanitize-recover family of flags.Alexey Samsonov2015-01-121-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
* Allow -fsanitize-coverage=N with ubsan, clang partKostya Serebryany2015-01-061-0/+6
| | | | | | | | | | | | | | | | | | | | Summary: Allow -fsanitize-coverage=N with ubsan, clang part. This simply allows the flag combination. The LLVM will work out of the box, the compile-rt part will follow as a separate patch. Test Plan: check-clang Reviewers: samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6849 llvm-svn: 225229
* Allow to disable all sanitizers with "-fno-sanitize=all" option.Alexey Samsonov2014-12-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds "all" sanitizer group. A shortcut "-fno-sanitize=all" can be used to disable all sanitizers for a given source file. "-fsanitize=all" option makes no sense, and will produce an error. This group can also be useful when we add "-fsanitize-recover=<list>" options (patch in http://reviews.llvm.org/D6302), as it would allow to conveniently enable/disable recovery for all specified sanitizers. Test Plan: regression test suite Reviewers: kcc, rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6733 llvm-svn: 224596
* [sanitizer] allow -fsanitize-coverage=N w/ -fsanitize=leak, clang partKostya Serebryany2014-12-171-0/+1
| | | | llvm-svn: 224462
* [msan] allow -fsanitize-coverage=N together with -fsanitize=memory, clang partKostya Serebryany2014-12-031-0/+1
| | | | llvm-svn: 223311
* Fix test after r222526.Dmitry Vyukov2014-11-211-2/+1
| | | | llvm-svn: 222530
* [Sanitizer] Parse and produce all sanitizer-relevant arguments in SanitizerArgs.Alexey Samsonov2014-11-161-5/+5
| | | | | | | | | | | | | In particular, make SanitizerArgs responsible for parsing and passing down to frontend -fsanitize-recover and -fsanitize-undefined-trap-on-error flags. Simplify parsing -f(no-)sanitize= flags parsing: get rid of too complex filterUnsupportedKinds function. No functionality change. llvm-svn: 222105
* Introduce -fsanitize-coverage=N flagKostya Serebryany2014-11-111-0/+10
| | | | | | | | | | | | | | | | | | | Summary: This change makes the asan-coverge (formerly -mllvm -asan-coverge) accessible via a clang flag. Companion patch to LLVM is http://reviews.llvm.org/D6152 Test Plan: regression tests, chromium Reviewers: samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6153 llvm-svn: 221719
* clang-cl: Diagnose the usage of ASAN with a debug runtime libraryEhsan Akhgari2014-10-141-0/+18
| | | | | | | | | | | | | | | | Summary: AddressSanitizer currently doesn't support this configuration, and binaries built with it will just get into an infinite loop during startup. Test Plan: Includes an automated test. Reviewers: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5764 llvm-svn: 219744
* Add experimental clang/driver flag -fsanitize-address-field-padding=NKostya Serebryany2014-10-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change adds an experimental flag -fsanitize-address-field-padding=N (0, 1, 2) to clang and driver. With this flag ASAN will be able to detect some cases of intra-object-overflow bugs, see https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow There is no actual functionality here yet, just the flag parsing. The functionality is being reviewed at http://reviews.llvm.org/D5687 Test Plan: Build and run SPEC, LLVM Bootstrap, Chrome with this flag. Reviewers: samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5676 llvm-svn: 219417
* Implement nonnull-attribute sanitizerAlexey Samsonov2014-09-081-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a new UBSan check, which verifies that function arguments declared to be nonnull with __attribute__((nonnull)) are actually nonnull in runtime. To implement this check, we pass FunctionDecl to CodeGenFunction::EmitCallArgs (where applicable) and if function declaration has nonnull attribute specified for a certain formal parameter, we compare the corresponding RValue to null as soon as it's calculated. Test Plan: regression test suite Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits, rnk Differential Revision: http://reviews.llvm.org/D5082 llvm-svn: 217389
* [UBSan] Add returns-nonnull sanitizer.Alexey Samsonov2014-08-131-4/+4
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds a runtime check verifying that functions annotated with "returns_nonnull" attribute do in fact return nonnull pointers. It is based on suggestion by Jakub Jelinek: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223693.html. Test Plan: regression test suite Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4849 llvm-svn: 215485
* Remove top-level Clang -fsanitize= flags for optional ASan features.Alexey Samsonov2014-06-131-21/+0
| | | | | | | | | | | | | Init-order and use-after-return modes can currently be enabled by runtime flags. use-after-scope mode is not really working at the moment. The only problem I see is that users won't be able to disable extra instrumentation for init-order and use-after-scope by a top-level Clang flag. But this instrumentation was implicitly enabled for quite a while and we didn't hear from users hurt by it. llvm-svn: 210924
* Kill deprecated -fbounds-checking flagAlexey Samsonov2014-03-211-3/+3
| | | | llvm-svn: 204436
* [msan] -fsanitize-memory-track-origins=[level] flag and docs.Evgeniy Stepanov2014-03-201-2/+21
| | | | | | | | | This change turns -fsanitize-memory-track-origins into -fsanitize-memory-track-origins=[level] flag (keeping the old one for compatibility). Possible levels are 0 (off), 1 (default) and 2 (incredibly detailed). See docs (part of this patch) for more info. llvm-svn: 204346
* Kill -faddress-sanitizer, -fthread-sanitizer and -fcatch-undefined-behavior ↵Alexey Samsonov2014-03-201-17/+2
| | | | | | | | | flags. These flags are deprecated since at least Clang 3.3. Users should instead use -fsanitize= with appropriate values. llvm-svn: 204330
* Turn on PIC by default on Android (http://llvm-reviews.chandlerc.com/D2603)Alexey Bataev2014-01-281-1/+1
| | | | llvm-svn: 200290
* [asan] Remove -fsanitize-address-zero-base-shadow command lineEvgeniy Stepanov2014-01-161-20/+0
| | | | | | | | | | | | | | | | flag from clang, and disable zero-base shadow support on all platforms where it is not the default behavior. - It is completely unused, as far as we know. - It is ABI-incompatible with non-zero-base shadow, which means all objects in a process must be built with the same setting. Failing to do so results in a segmentation fault at runtime. - It introduces a backward dependency of compiler-rt on user code, which is uncommon and complicates testing. This is the Clang part of a larger change. llvm-svn: 199372
* SanitizerArgs: add ability to filter/diagnose unsupported sanitizers.Peter Collingbourne2013-11-011-5/+32
| | | | | | | | | | | | The thread, memory, dataflow and function sanitizers are now diagnosed if enabled explicitly on an unsupported platform. Unsupported sanitizers which are enabled implicitly (as part of a larger group) are silently disabled. As a side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain. Differential Revision: http://llvm-reviews.chandlerc.com/D1990 llvm-svn: 193875
* Split -fsanitize=bounds to -fsanitize=array-bounds (for the frontend-insertedRichard Smith2013-10-221-4/+4
| | | | | | | | | | | | | | check using the ubsan runtime) and -fsanitize=local-bounds (for the middle-end check which inserts traps). Remove -fsanitize=local-bounds from -fsanitize=undefined. It does not produce useful diagnostics and has false positives (PR17635), and is not a good compromise position between UBSan's checks and ASan's checks. Map -fbounds-checking to -fsanitize=local-bounds to restore Clang's historical behavior for that flag. llvm-svn: 193205
OpenPOWER on IntegriCloud