Introduce -fsanitize-stats flag.

This is part of a new statistics gathering feature for the sanitizers.
See clang/docs/SanitizerStats.rst for further info and docs.

Differential Revision: http://re

Introduce -fsanitize-stats flag.

This is part of a new statistics gathering feature for the sanitizers.
See clang/docs/SanitizerStats.rst for further info and docs.

Differential Revision: http://reviews.llvm.org/D16175

llvm-svn: 257971

show more ...

Module debugging: Make the module format part of the module hash instead
of the file name. This is consistent with how other HeaderSearchOptions
are handled.

Due to the other inputs of the module ha

Module debugging: Make the module format part of the module hash instead
of the file name. This is consistent with how other HeaderSearchOptions
are handled.

Due to the other inputs of the module hash (revision number) this is not
really testable in a meaningful way.

llvm-svn: 257520

show more ...

Accidentally removed part of the file header. Restoring it back.

llvm-svn: 257291

[Driver] Add support for -fno-builtin-foo options.

Addresses PR4941 and rdar://6756912.
http://reviews.llvm.org/D15195

llvm-svn: 256937

[OpenMP] Reapply rL256842: [OpenMP] Offloading descriptor registration and device codegen.

This patch attempts to fix the regressions identified when the patch was committed initially.

Thanks to M

[OpenMP] Reapply rL256842: [OpenMP] Offloading descriptor registration and device codegen.

This patch attempts to fix the regressions identified when the patch was committed initially.

Thanks to Michael Liao for identifying the fix in the offloading metadata generation
related with side effects in evaluation of function arguments.


llvm-svn: 256933

show more ...

Avoid assert failure on some invalid cc1 options.

Addressing review comment in D13221.

Differential Revision: http://reviews.llvm.org/D15882

llvm-svn: 256897

[OpenMP] Revert rL256842: [OpenMP] Offloading descriptor registration and device codegen.

It was causing two regression, so I'm reverting until the cause is found.

llvm-svn: 256858

[OpenMP] Offloading descriptor registration and device codegen.

Summary:
In order to offloading work properly two things need to be in place:
- a descriptor with all the offloading information (devi

[OpenMP] Offloading descriptor registration and device codegen.

Summary:
In order to offloading work properly two things need to be in place:
- a descriptor with all the offloading information (device entry functions, and global variable) has to be created by the host and registered in the OpenMP offloading runtime library.
- all the device functions need to be emitted for the device and a convention has to be in place so that the runtime library can easily map the host ID of an entry point with the actual function in the device.

This patch adds support for these two things. However, only entry functions are being registered given that 'declare target' directive is not yet implemented.

About offloading descriptor:

The details of the descriptor are explained with more detail in http://goo.gl/L1rnKJ. Basically the descriptor will have fields that specify the number of devices, the pointers to where the device images begin and end (that will be defined by the linker), and also pointers to a the begin and end of table whose entries contain information about a specific entry point. Each entry has the type:
```
struct __tgt_offload_entry{
void *addr;
char *name;
int64_t size;
};
```
and will be implemented in a pre determined (ELF) section `.omp_offloading.entries` with 1-byte alignment, so that when all the objects are linked, the table is in that section with no padding in between entries (will be like a C array). The code generation ensures that all `__tgt_offload_entry` entries are emitted in the same order for both host and device so that the runtime can have the corresponding entries in both host and device in same index of the table, and efficiently implement the mapping.

The resulting descriptor is registered/unregistered with the runtime library using the calls `__tgt_register_lib` and `__tgt_unregister_lib`. The registration is implemented in a high priority global initializer so that the registration happens always before any initializer (that can potentially include target regions) is run.

The driver flag -omptargets= was created to specify a comma separated list of devices the user wants to support so that the new functionality can be exercised. Each device is specified with its triple.


About target codegen:

The target codegen is pretty much straightforward as it reuses completely the logic of the host version for the same target region. The tricky part is to identify the meaningful target regions in the device side. Unlike other programming models, like CUDA, there are no already outlined functions with attributes that mark what should be emitted or not. So, the information on what to emit is passed in the form of metadata in host bc file. This requires a new option to pass the host bc to the device frontend. Then everything is similar to what happens in CUDA: the global declarations emission is intercepted to check to see if it is an "interesting" declaration. The difference is that instead of checking an attribute, the metadata information in checked. Right now, there is only a form of metadata to pass information about the device entry points (target regions). A class `OffloadEntriesInfoManagerTy` was created to manage all the information and queries related with the metadata. The metadata looks like this:
```
!omp_offload.info = !{!0, !1, !2, !3, !4, !5, !6}

!0 = !{i32 0, i32 52, i32 77426347, !"_ZN2S12r1Ei", i32 479, i32 13, i32 4}
!1 = !{i32 0, i32 52, i32 77426347, !"_ZL7fstatici", i32 461, i32 11, i32 5}
!2 = !{i32 0, i32 52, i32 77426347, !"_Z9ftemplateIiET_i", i32 444, i32 11, i32 6}
!3 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 99, i32 11, i32 0}
!4 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 272, i32 11, i32 3}
!5 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 127, i32 11, i32 1}
!6 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 159, i32 11, i32 2}
```
The fields in each metadata entry are (in sequence):
Entry 1) an ID of the type of metadata - right now only zero is used meaning "OpenMP target region".
Entry 2) a unique ID of the device where the input source file that contain the target region lives.
Entry 3) a unique ID of the file where the input source file that contain the target region lives.
Entry 4) a mangled name of the function that encloses the target region.
Entries 5) and 6) line and column number where the target region was found.
Entry 7) is the order the entry was emitted.

Entry 2) and 3) are required to distinguish files that have the same function name.
Entry 4) is required to distinguish different instances of the same declaration (usually templated ones)
Entries 5) and 6) are required to distinguish the particular target region in body of the function (it is possible that a given target region is not an entry point - if clause can evaluate always to zero - and therefore we need to identify the "interesting" target regions. )

This patch replaces http://reviews.llvm.org/D12306.

Reviewers: ABataev, hfinkel, tra, rjmccall, sfantao

Subscribers: FBrygidyn, piotr.rak, Hahnfeld, cfe-commits

Differential Revision: http://reviews.llvm.org/D12614

llvm-svn: 256842

show more ...

Some minor correction based on David Blaikie post-commit code review for r255281.

llvm-svn: 256396

[clang-cl] Add support for /Brepro

The /Brepro flag controls whether or not the compiler should embed
timestamps into the object file. Object files which do not embed
timestamps are not suitable fo

[clang-cl] Add support for /Brepro

The /Brepro flag controls whether or not the compiler should embed
timestamps into the object file. Object files which do not embed
timestamps are not suitable for incremental linking but are suitable for
hermetic build systems and staged self-hosts of clang.

A normal clang spelling of this flag has been added,
-mincremental-linker-compatible.

llvm-svn: 256204

show more ...

Recommit CC1 part of debugger tuning; pass through setting from driver to LLVM.

Reapplies r256063, except instead of frugally re-using an LLVM enum,
we define a Clang enum, to avoid exposing too muc

Recommit CC1 part of debugger tuning; pass through setting from driver to LLVM.

Reapplies r256063, except instead of frugally re-using an LLVM enum,
we define a Clang enum, to avoid exposing too much LLVM interface.

Differential Revision: http://reviews.llvm.org/D15650

llvm-svn: 256078

show more ...

Revert r256063, it's killing clang-tools-extra

llvm-svn: 256066

CC1 part of debugger tuning; pass through setting from driver to LLVM.

Differential Revision: http://reviews.llvm.org/D15650

llvm-svn: 256063

Cross-DSO control flow integrity (Clang part).

Clang-side cross-DSO CFI.

* Adds a command line flag -f[no-]sanitize-cfi-cross-dso.
* Links a runtime library when enabled.
* Emits __cfi_slowpath cal

Cross-DSO control flow integrity (Clang part).

Clang-side cross-DSO CFI.

* Adds a command line flag -f[no-]sanitize-cfi-cross-dso.
* Links a runtime library when enabled.
* Emits __cfi_slowpath calls is bitset test fails.
* Emits extra hash-based bitsets for external CFI checks.
* Sets a module flag to enable __cfi_check generation during LTO.

This mode does not yet support diagnostics.

llvm-svn: 255694

show more ...

Do not generate DW_TAG_imported_module for anonymous namespaces (even nested) for all the platforms except PS4.
For PS4, generate explicit import for anonymous namespaces and mark it by DW_AT_artific

Do not generate DW_TAG_imported_module for anonymous namespaces (even nested) for all the platforms except PS4.
For PS4, generate explicit import for anonymous namespaces and mark it by DW_AT_artificial attribute.

Differential Revision: http://reviews.llvm.org/D12624

llvm-svn: 255281

show more ...

[ThinLTO] Option to invoke ThinLTO backend passes and importing

Summary:
Adds new option -fthinlto-index=<file> to invoke the LTO pipeline
along with function importing via clang using the supplied

[ThinLTO] Option to invoke ThinLTO backend passes and importing

Summary:
Adds new option -fthinlto-index=<file> to invoke the LTO pipeline
along with function importing via clang using the supplied function
summary index file. This supports invoking the parallel ThinLTO
backend processes in a distributed build environment via clang.

Additionally, this causes the module linker to be invoked on the bitcode
file being compiled to perform any necessary promotion and renaming of
locals that are exported via the function summary index file.

Add a couple tests that confirm we get expected errors when we try to
use the new option on a file that isn't bitcode, or specify an invalid
index file. The tests also confirm that we trigger the expected function
import pass.

Depends on D15024

Reviewers: joker.eph, dexonsmith

Subscribers: joker.eph, davidxl, cfe-commits

Differential Revision: http://reviews.llvm.org/D15025

llvm-svn: 254927

show more ...

[modules] Add -cc1 flag -fmodules-embed-all-files.

This flag causes all files that were read by the compilation to be embedded
into a produced module file. This is useful for distributed build syste

[modules] Add -cc1 flag -fmodules-embed-all-files.

This flag causes all files that were read by the compilation to be embedded
into a produced module file. This is useful for distributed build systems that
use an include scanning system to determine which files are "needed" by a
compilation, and only provide those files to remote compilation workers. Since
using a module can require any file that is part of that module (or anything it
transitively includes), files that are not found by an include scanner can be
required in a regular build using explicit modules. With this flag, only files
that are actually referenced by transitively-#included files are required to be
present on the build machine.

llvm-svn: 253950

show more ...

Disable frame pointer elimination when using -pg

(Re-apply patch after bug fixing)

This diff makes sure that the driver does not pass
-fomit-frame-pointer or -momit-leaf-frame-pointer to
the front

Disable frame pointer elimination when using -pg

(Re-apply patch after bug fixing)

This diff makes sure that the driver does not pass
-fomit-frame-pointer or -momit-leaf-frame-pointer to
the frontend when -pg is used. Currently, clang gives
an error if -fomit-frame-pointer is used in combination
with -pg, but -momit-leaf-frame-pointer was forgotten.
Also, disable frame pointer elimination in the frontend
when -pg is set.

Patch by Stefan Kempf.

llvm-svn: 253886

show more ...

Revert r253846 (build bot failure))

llvm-svn: 253851

Disable frame pointer elimination when using -pg

This diff makes sure that the driver does not pass
-fomit-frame-pointer or -momit-leaf-frame-pointer to
the frontend when -pg is used. Currently, cla

Disable frame pointer elimination when using -pg

This diff makes sure that the driver does not pass
-fomit-frame-pointer or -momit-leaf-frame-pointer to
the frontend when -pg is used. Currently, clang gives
an error if -fomit-frame-pointer is used in combination
with -pg, but -momit-leaf-frame-pointer was forgotten.
Also, disable frame pointer elimination in the frontend
when -pg is set.

Patch by Stefan Kempf.

llvm-svn: 253846

show more ...

Revert "Make FP_CONTRACT ON the default."

This reverts commit r253269.

This leads to assert / segfault triggering on the following reduced example:
float foo(float U, float base, float cell) { retu

Revert "Make FP_CONTRACT ON the default."

This reverts commit r253269.

This leads to assert / segfault triggering on the following reduced example:
float foo(float U, float base, float cell) { return (U = 2 * base) - cell; }

llvm-svn: 253337

show more ...

Make FP_CONTRACT ON the default.

Differential Revision: D14200

llvm-svn: 253269

Revert r240335.

This failed to solve the problem it was aimed at, and introduced just as many
issues as it resolved. Realistically, we need to deal with the possibility that
multiple modules might d

Revert r240335.

This failed to solve the problem it was aimed at, and introduced just as many
issues as it resolved. Realistically, we need to deal with the possibility that
multiple modules might define different internal linkage symbols with the same
name, and this isn't a problem unless two such symbols are simultaneously
visible.

The case where two modules define equivalent internal linkage symbols is
handled by r252063: if lookup finds multiple sufficiently-similar entities from
different modules, we just pick one of them as an extension (but we keep them
separate).

llvm-svn: 252957

show more ...

[EABI] Add Clang support for -meabi flag

The -meabi flag to control LLVM EABI version.

Without '-meabi' or with '-meabi default' imply LLVM triple default.
With '-meabi gnu' sets EABI GNU.
With '-m

[EABI] Add Clang support for -meabi flag

The -meabi flag to control LLVM EABI version.

Without '-meabi' or with '-meabi default' imply LLVM triple default.
With '-meabi gnu' sets EABI GNU.
With '-meabi 4' or '-meabi 5' set EABI version 4 and 5 respectively.

A similar patch was introduced in LLVM.

Patch by Vinicius Tinti.

llvm-svn: 252463

show more ...

After some discussion, promote -fobjc-weak to a driver option.

rdar://problem/23415863

llvm-svn: 252187