Add Clang flags -fsanitize-blacklist and -fno-sanitize-blacklist. Make this flag usable for ASan. Blacklisting can be used to disable sanitizer checks for particular file/function/object.

llvm-svn: 169144

to enable/disable support of GOT larger than 64k.

llvm-svn: 169098

llvm-svn: 169089

llvm-svn: 169088

llvm-svn: 169066

1) init-order sanitizer: initialization-order checker.
Status: usable, but may produce false positives w/o proper blacklisting.
2) use-after-return sanitizer
Status: implemented, but heavily understed.
Should be optional, as it significanlty slows program down.
3) use-after-scope sanitizer
Status: in progress.

llvm-svn: 168950

before libstdc++ like we do with ubsan.

llvm-svn: 168918

llvm-svn: 168908

llvm-svn: 168907

rdar://12771737

llvm-svn: 168841

Refactor -fsanitize, -f*-sanitizer arguments parsing. Provide a more careful diagnostic for invalid sets of sanitizers

llvm-svn: 168794

Introduces new sanitizer "unsigned-integer-overflow".

llvm-svn: 168701

llvm-svn: 168562

llvm-svn: 168510

Previously, this flag to CC1 was never exposed at the clang driver
layer, and if you happened to enable it (by being on Android or GCC 4.7
platform), you couldn't *disable* it, because there was no 'no' variant.
The whole thing was confusingly implemented.

Now, the target-specific flag processing gets the driver arg list, and
we use standard hasFlag with a default based on the GCC version and/or
Android platform. The user can still pass the 'no-' variant to forcibly
disable the flag, or pass the positive variant to clang itself to enable
the flag.

The test has also been substantially cleaned up and extended to cover
these use cases.

llvm-svn: 168473

llvm-svn: 168431

FIXME: It could be /dev/null.
llvm-svn: 168429

[Sanitizer] force linking with static sanitizer runtimes on Darwin even if they are not found in resource directory. Add test checking sanitizer linker flags on Darwin.

llvm-svn: 168428

According to Android ABI, we have to link with
libdl.so, if we are linking with non-static libgcc.

Besides, this also fixes MIPS link error of
undefined references to `_Unwind_Find_FDE' and
`dl_iterate_phdr'.

llvm-svn: 168310

The dynamic linker of Android does not support .ctors/.dtors.
We should emit .init_array and .fini_array regardless the
gcc version.

NOTE: This patch does not affect the ARM backend, because
it is required to generate .init_array and .fini_array
for program targeting ARM AAPCS and AEABI.

llvm-svn: 168309

There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
   have been fixed in trunk GCC, and this fixes Clang as well. Notably,
   the logic was always intended to be last-match-wins like any other
   flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
   It also allowed the use of this flag on non-Darwin platforms where it
   has no actual meaning. Now this option is handled directly based on
   tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
   of dynamic-no-pic leaking through them. They also had the
   implementation details of the LLVM relocation model flag names
   leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
   many cases. For example, Darwin *always* uses PIC level 2 if it uses
   in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
   the flags specified, including -fPIE. Darwin never compiles in PIE
   mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
   a supported mode at all and may have caused some fallout in builds
   with complex PIC and PIE interactions.

The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.

Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.

llvm-svn: 168297

This was causing different behavior when using -x objective-c++-cpp-output as
compared to -x objc++-cpp-output.  Specifically, the driver was not adding the
-fcxx-exceptions flag in the latter case.
rdar://12680312

llvm-svn: 168212

to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031 

llvm-svn: 168063

This patch makes the behavior of clang consistent with the behavior of gcc 4.6 in cases where both -fPIC and -fPIE is used.

- Separately check if -fPIE was specified in the command line and define both __PIC__ and __PIE__ when -fPIE is used. We need to check this separately because -fPIE will infer -fPIC even if its not explicitly used.
- Fixed existing tests.
- Added new tests for cases where both -fPIC and -fPIE is used.

Author: Tareq A. Siraj <tareq.a.siraj@intel.com>
Fixes: PR13221
Review: http://llvm-reviews.chandlerc.com/D94
llvm-svn: 167846

the driver (the options defined in CC1Options.td) and exclude their help from
"clang --help".

llvm-svn: 167638

us from having to make any backend changes.

llvm-svn: 167623

llvm-svn: 167621

We can now rely on the -mios-simulator-version-min command line option
and remove the awful hack. <rdar://problem/10304510>

llvm-svn: 167603

triple.

 - Translate the special case of powerpc to its expected -arch name.

llvm-svn: 167571

More cleanups to follow in separate commits....

llvm-svn: 167566

llvm-svn: 167559

clang/test/Driver/fsanitize.c: Speculative fix to improve test on win32, not to mix emissions into stdout.

llvm-svn: 167485

llvm-svn: 167472

-fno-address-sanitizer, -fthread-sanitizer, -fno-thread-sanitizer, and
-fcatch-undefined-behavior as deprecated: produce a warning if they are used
pointing to the corresponding -fsanitize= option. In passing add the missing
'-' to some diagnostics.

llvm-svn: 167429

-fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the
various UBSan checks to be enabled and disabled separately. Right now, the
different modes can't be combined, but the intention is that combining UBSan
and the other sanitizers will be permitted in the near future.

Currently, the UBSan checks will all be enabled if any of them is; that will be
fixed by the next patch.

llvm-svn: 167411

* -Bsymbolic must be added for x86 as well.
* Default CPU name also set to 'core2' for x86 android.
Patch by Edwin Vane.

llvm-svn: 167307

llvm-svn: 167306

diagnostics script.

This addresses the FIXME pertaining to quoted arguments.  We also delineate
between those flags that have an argument (e.g., -D macro, -MF file) and
those that do not (e.g., -M, -MM, -MG).  Finally, we add the -dwarf-debug-flags
to the list of flags to be removed.
rdar://12329974

llvm-svn: 167152

is not a directory, Driver::GetProgramPath() routine does not try to append
the program name as a "path component" to it. It just joins the "prefix" with
the program name and checks the resulting path existence.

The patch reviewed by Rafael Espindola.

llvm-svn: 167114

llvm-svn: 167093