llvm-svn: 172808

rather than doing it ourselves. This reflects the API changes in r171681.

llvm-svn: 171683

passes to a create-pass function instead of a direct constructor call.

llvm-svn: 171622

reflect the migration in r171366.

Re-sort the #include lines to reflect the new paths.

llvm-svn: 171369

Removes a duplicate #include as well as cleaning up some sort order
regressions since I last ran the script over Clang.

llvm-svn: 171364

llvm-svn: 171184

llvm-svn: 171020

llvm/Target/TargetMachine.h will not provide "llvm/TargetTransformInfo.h" any more.

llvm-svn: 169816

This prevents the functions generated by that pass from using the red zone.
<rdar://problem/12843084>

llvm-svn: 169755

uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237

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

llvm-svn: 169124

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

llvm-svn: 168782

llvm-svn: 168510

more sense anyway - it determines how expressions are codegen'd. It also ensures
that -ffp-contract=fast has the intended effect when compiling LLVM IR.

llvm-svn: 168027

us from having to make any backend changes.

llvm-svn: 167623

rdar://12340498

llvm-svn: 167619

*Sanitizer to Sanitize* in preparation for later patches.

llvm-svn: 167405

Many of our tests specify triples that are not built into clang.
In this commit we allow clang to fail loading the triple if we are only
using clang to emit llvm ir.

llvm-svn: 166543

and use it to initialize the TargetTransformInfo analysis pass.
We need the TTI information for the loop vectorizer.

rdar://12464901

llvm-svn: 166532

llvm-svn: 166497

 - We create two TargetLoweringInfo instances for different pass managers, and
   they weren't consistent (the one for codegen didn't have the right info). I'm
   not sure this mattered anywhere in practice.

llvm-svn: 166299

llvm-svn: 166263

Nadav's llvm change r165665 caused problems with an LTO bootstrap of clang,
so I'm reverting it for now, along with follow-on patches like this one.

llvm-svn: 166164

[asan] make AddressSanitizer to be a FunctionPass instead of ModulePass. clang part: for FunctionPass we need to run asan at a different point, otherwise it will run before inlining

llvm-svn: 165937

llvm-svn: 165741

llvm-svn: 165395

PR9673

llvm-svn: 162285

This flag sets the 'fp-contract' mode, which controls the formation of fused
floating point operations. Available modes are:

- Fast: Form fused operations anywhere. 
- On: Form fused operations where allowed by FP_CONTRACT. This is the default
      mode.
- Off: Don't form fused operations (in future this may be relaxed to forming
       fused operations where it can be proved that the result won't be
       affected).

Currently clang doesn't support the FP_CONTRACT pragma, so the 'On' and 'Off'
modes are equivalent.

llvm-svn: 159794

option. On the driver, check if we are using libraries from gcc 4.7 or newer
and if so pass -fuse-init-array to the frontend.
The crtbegin*.o files in gcc 4.7 no longer call the constructors listed in
.ctors, so we have to use .init_array.

llvm-svn: 158694

llvm-svn: 157262

llvm-svn: 155697

case as we don't currently have any way of dumping target options or
otherwise observing this. Another small step toward fixing PR12380. With
this we generate TLS accesses using the static model instead of the
dynamic model, but we're still generating suboptimal code under the
mistaken assumption that the TLS offset might be greater than 2^32, and
therefor not viable as an immediate offset of a segment register.

llvm-svn: 154298

llvm-svn: 154052

llvm-svn: 153356

This flag enables ThreadSanitizer instrumentation committed to llvm as r150423.
The patch includes one test for -fthread-sanitizer and one similar test for -faddress-sanitizer.
This patch does not modify the linker flags (as we do it for -faddress-sanitizer) because the run-time library is not yet
committed and it's structure in compiler-rt is not 100% clear.
The users manual wil be changed in a separate commit.

llvm-svn: 151846

by the BAA pass, which uses the default TargetLibraryInfo constructor.
Unfortunately, the default TargetLibraryInfo constructor assumes all library
calls are available and thus ignores -fno-builtin.
rdar://10947759

llvm-svn: 151745

rdar://10921594

llvm-svn: 151430

llvm-svn: 150000