New clang option -mpie-copy-relocations to use copy relocations for PIE builds.

Differential Revision: https://reviews.llvm.org/D19996

llvm-svn: 284638

Reapply [Driver][Diagnostics] Make 'show option names' default for driver warnings

Reapply r283827 by fixing the tests to not be target specific

Currently, driver level warnings do not show option

Reapply [Driver][Diagnostics] Make 'show option names' default for driver warnings

Reapply r283827 by fixing the tests to not be target specific

Currently, driver level warnings do not show option names (e.g. warning:
complain about foo [-Woption-name]) in a diagnostic unless
-fdiagnostics-show-option is explictly specified. OTOH, the driver by
default turn this option on for CC1. Change the logic to show option
names by default in the driver as well.

Differential Revision: https://reviews.llvm.org/D24516

rdar://problem/27300909

llvm-svn: 283913

show more ...

Revert "[Driver][Diagnostics] Make 'show option names' default for driver warnings"

This reverts commit r283827, as it's breaking all ARM/AARch64 bots.

llvm-svn: 283868

Add an option to save the backend-produced YAML optimization record to a file

The backend now has the capability to save information from optimizations, the
same information that can be used to gene

Add an option to save the backend-produced YAML optimization record to a file

The backend now has the capability to save information from optimizations, the
same information that can be used to generate optimization diagnostics but in
machine-consumable form, into an output file. This can be enabled when using
opt (see r282539), and this change enables it when using clang. The idea is
that other tools will be able to consume these files, and perhaps in
combination with the original source code, produce various kinds of
optimization reports for users (and for compiler developers).

We now have at-least two tools that can consume these files:
* tools/llvm-opt-report
* utils/opt-viewer

Using the flag -fsave-optimization-record will cause the YAML file to be
generated; the file name will be based on the output file name (if we're using
-c or -S and have an output name), or the input file name. When we're using
CUDA, or some other offloading mechanism, separate files are generated for each
backend target. The output file name can be specified by the user using
-foptimization-record-file=filename.

Differential Revision: https://reviews.llvm.org/D25225

llvm-svn: 283834

show more ...

[Driver][Diagnostics] Make 'show option names' default for driver warnings

Currently, driver level warnings do not show option names (e.g. warning:
complain about foo [-Woption-name]) in a diagnosti

[Driver][Diagnostics] Make 'show option names' default for driver warnings

Currently, driver level warnings do not show option names (e.g. warning:
complain about foo [-Woption-name]) in a diagnostic unless
-fdiagnostics-show-option is explictly specified. OTOH, the driver by
default turn this option on for CC1. Change the logic to show option
names by default in the driver as well.

Differential Revision: https://reviews.llvm.org/D24516

rdar://problem/27300909

llvm-svn: 283827

show more ...

Add -fno-sanitize-address-use-after-scope flag

Reviewers: eugenis

Differential Revision: https://reviews.llvm.org/D25453

llvm-svn: 283801

[CUDA] Rename cuda_builtin_vars.h to __clang_cuda_builtin_vars.h.

Summary: This matches the idiom we use for our other CUDA wrapper headers.

Reviewers: tra

Subscribers: beanz, mgorny, cfe-commits

[CUDA] Rename cuda_builtin_vars.h to __clang_cuda_builtin_vars.h.

Summary: This matches the idiom we use for our other CUDA wrapper headers.

Reviewers: tra

Subscribers: beanz, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D24978

llvm-svn: 283679

show more ...

[coroutines] Rename driver flag -fcoroutines to -fcoroutines-ts

Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.

Patch mostly by EricWF.

Reviewers: rnk, cfe-commits, rsmith, E

[coroutines] Rename driver flag -fcoroutines to -fcoroutines-ts

Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.

Patch mostly by EricWF.

Reviewers: rnk, cfe-commits, rsmith, EricWF

Subscribers: mehdi_amini

Differential Revision: https://reviews.llvm.org/D25130

llvm-svn: 283064

show more ...

P0035R4: add predefined __STDCPP_DEFAULT_NEW_ALIGNMENT__ macro. By default, we
assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a G

P0035R4: add predefined __STDCPP_DEFAULT_NEW_ALIGNMENT__ macro. By default, we
assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a GNU OS, where glibc's malloc guarantees
to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit
systems. This can be controlled by the command-line -fnew-alignment flag.

llvm-svn: 282974

show more ...

CC1: Add -save-stats option

This option behaves in a similar spirit as -save-temps and writes
internal llvm statistics in json format to a file.

Differential Revision: https://reviews.llvm.org/D248

CC1: Add -save-stats option

This option behaves in a similar spirit as -save-temps and writes
internal llvm statistics in json format to a file.

Differential Revision: https://reviews.llvm.org/D24820

llvm-svn: 282426

show more ...

Revert "set the underlying value of “#pragma STDC FP_CONTRACT” on by default"

This reverts commit r282259, as it broke the AArch64 test-suite bots.

llvm-svn: 282289

set the underlying value of “#pragma STDC FP_CONTRACT” on by default

Clang has the default FP contraction setting of “-ffp-contract=on”, which
doesn't really mean “on” in the conventional sense of t

set the underlying value of “#pragma STDC FP_CONTRACT” on by default

Clang has the default FP contraction setting of “-ffp-contract=on”, which
doesn't really mean “on” in the conventional sense of the word, but rather
really means “according to the per-statement effective value of the relevant
pragma”.

Before this patch, Clang has that pragma defaulting to “off”. Since the
“-ffp-contract=on” mode is really an AND of two booleans and the second of them
defaults to “off”, the whole thing effectively defaults to “off”. This patch
changes the default value of the pragma to “on”, thus making the default pair of
booleans (on, on) rather than (on, off). This makes FP optimization slightly
more aggressive than before when not using either “-Ofast”, “-ffast-math”, or
“-ffp-contract=fast”. Even with this patch the compiler still respects
“-ffp-contract=off”.

As per a suggestion by Steve Canon, the added code does _not_ require “-O3” or
higher. This is so as to try our best to preserve identical floating-point
results for unchanged source code compiling for an unchanged target when only
changing from any optimization level in the set (“-O0”, “-O1”, “-O2”, “-O3”) to
any other optimization level in that set. “-Os” and “-Oz” seem to be behaving
identically, i.e. should probably be considered a part of the aforementioned
set, but I have not reviewed this rigorously. “-Ofast” is explicitly _not_ a
member of that set.

Patch authored by Abe Skolnik [a.skolnik@samsung.com] and Stephen Canon [scanon@apple.com].

Differential Revision: https://reviews.llvm.org/D24481

llvm-svn: 282259

show more ...

[sanitizer-coverage] add yet another flavour of coverage instrumentation: trace-pc-guard. The intent is to eventually replace all of {bool coverage, 8bit-counters, trace-pc} with just this one. Clang

[sanitizer-coverage] add yet another flavour of coverage instrumentation: trace-pc-guard. The intent is to eventually replace all of {bool coverage, 8bit-counters, trace-pc} with just this one. Clang part

llvm-svn: 281432

show more ...

Reapply r281276 with passing -emit-llvm in one of the tests

Original commit message:

Add -fdiagnostics-show-hotness

Summary:
I've recently added the ability for optimization remarks to include the

Reapply r281276 with passing -emit-llvm in one of the tests

Original commit message:

Add -fdiagnostics-show-hotness

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334

The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.

That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)

For the record, Hal has already expressed support for the idea of this
patch on IRC.

Differential Revision: https://reviews.llvm.org/D23284

llvm-svn: 281293

show more ...

Revert "Add -fdiagnostics-show-hotness"

This reverts commit r281276.

Many bots are failing.

llvm-svn: 281279

Add -fdiagnostics-show-hotness

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the o

Add -fdiagnostics-show-hotness

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334

The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.

That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)

For the record, Hal has already expressed support for the idea of this
patch on IRC.

Differential Revision: https://reviews.llvm.org/D23284

llvm-svn: 281276

show more ...

Add -fprofile-dir= to clang.

-fprofile-dir=path allows the user to specify where .gcda files should be
emitted when the program is run. In particular, this is the first flag that
causes the .gcno an

Add -fprofile-dir= to clang.

-fprofile-dir=path allows the user to specify where .gcda files should be
emitted when the program is run. In particular, this is the first flag that
causes the .gcno and .o files to have different paths, LLVM is extended to
support this. -fprofile-dir= does not change the file name in the .gcno (and
thus where lcov looks for the source) but it does change the name in the .gcda
(and thus where the runtime library writes the .gcda file). It's different from
a GCOV_PREFIX because a user can observe that the GCOV_PREFIX_STRIP will strip
paths off of -fprofile-dir= but not off of a supplied GCOV_PREFIX.

To implement this we split -coverage-file into -coverage-data-file and
-coverage-notes-file to specify the two different names. The !llvm.gcov
metadata node grows from a 2-element form {string coverage-file, node dbg.cu}
to 3-elements, {string coverage-notes-file, string coverage-data-file, node
dbg.cu}. In the 3-element form, the file name is already "mangled" with
.gcno/.gcda suffixes, while the 2-element form left that to the middle end
pass.

llvm-svn: 280306

show more ...

Unrevert r280035 now that the clang-cl bug it exposed has been fixed by
r280133. Original commit message:

C++ Modules TS: driver support for building modules.

This works as follows: we add --precom

Unrevert r280035 now that the clang-cl bug it exposed has been fixed by
r280133. Original commit message:

C++ Modules TS: driver support for building modules.

This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.

The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.

As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.

This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.

llvm-svn: 280134

show more ...

Revert r280035 (and followups r280057, r280085), it caused PR30195

llvm-svn: 280091

This adds new options -fdenormal-fp-math and passes through option -ffast-math
to CC1, which are translated to function attributes and can e.g. be mapped on
build attributes FP_exceptions and FP_deno

This adds new options -fdenormal-fp-math and passes through option -ffast-math
to CC1, which are translated to function attributes and can e.g. be mapped on
build attributes FP_exceptions and FP_denormal. Setting these build attributes
allows better selection of floating point libraries.

Differential Revision: https://reviews.llvm.org/D23840

llvm-svn: 280064

show more ...

[sanitizer-coverage] add two more modes of instrumentation: trace-div and trace-gep, mostly usaful for value-profile-based fuzzing; clang part

llvm-svn: 280044

C++ Modules TS: driver support for building modules.

This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc

C++ Modules TS: driver support for building modules.

This works as follows: we add --precompile to the existing gamut of options for
specifying how far to go when compiling an input (-E, -c, -S, etc.). This flag
specifies that an input is taken to the precompilation step and no further, and
this can be specified when building a .pcm from a module interface or when
building a .pch from a header file.

The .cppm extension (and some related extensions) are implicitly recognized as
C++ module interface files. If --precompile is /not/ specified, the file is
compiled (via a .pcm) to a .o file containing the code for the module (and then
potentially also assembled and linked, if -S, -c, etc. are not specified). We
do not yet suppress the emission of object code for other users of the module
interface, so for now this will only work if everything in the .cppm file has
vague linkage.

As with the existing support for module-map modules, prebuilt modules can be
provided as compiler inputs either via the -fmodule-file= command-line argument
or via files named ModuleName.pcm in one of the directories specified via
-fprebuilt-module-path=.

This also exposes the -fmodules-ts cc1 flag in the driver. This is still
experimental, and in particular, the concrete syntax is subject to change as
the Modules TS evolves in the C++ committee. Unlike -fmodules, this flag does
not enable support for implicitly loading module maps nor building modules via
the module cache, but those features can be turned on separately and used in
conjunction with the Modules TS support.

llvm-svn: 280035

show more ...

Add support for -fdiagnostics-absolute-paths: printing absolute paths in diagnostics

Differential Revision: https://reviews.llvm.org/D23816

llvm-svn: 279827

C++ Modules TS: add frontend support for building pcm files from module
interface files. At the moment, all declarations (and no macros) are exported,
and 'export' declarations are not supported yet.

C++ Modules TS: add frontend support for building pcm files from module
interface files. At the moment, all declarations (and no macros) are exported,
and 'export' declarations are not supported yet.

llvm-svn: 279794

show more ...

DebugInfo: Add flag to CU to disable emission of inline debug info into the skeleton CU

In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inli

DebugInfo: Add flag to CU to disable emission of inline debug info into the skeleton CU

In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inline info can save a substantial
amount of space - see the original r221306 for more details there.

llvm-svn: 279651

show more ...