trying to track origins in the memory sanitizer since the backend
instrumentation pass currently takes names from the Instruction.
Fixes all of the origin tracking tests in compiler-rt after the
-discard-value-name option was added.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263412 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This flag is enabled by default in the driver when NDEBUG is set. It
is forwarded on the LLVMContext to discard all value names (but
GlobalValue) for performance purpose.
This an improved version of D18024
Reviewers: echristo, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18127
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263394 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes cc1 option for PGO profile use from
-fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>.
-fprofile-instr-use=<path> is now a driver only option.
In addition to decouple the cc1 option from the driver level option, this patch
also enables IR level profile use. cc1 option handling now reads the profile
header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM}
-- this is a common enum for -fprofile-instrument={}, for the profile
instrumentation), and invoke the pipeline to enable the respective PGO use pass.
Reviewers: silvas, davidxl
Differential Revision: http://reviews.llvm.org/D17737
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262515 91177308-0d34-0410-b5e6-96231b3b80d8
In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then includes the header
with `-include foo.h` and if a .gch file exists for that header it gets used.
This is documented at
http://clang.llvm.org/docs/UsersManual.html#precompiled-headers
cl.exe's model is fairly different, and controlled by the two flags /Yc and
/Yu. A pch file is generated as a side effect of a regular compilation when
/Ycheader.h is passed. While the compilation is running, the compiler keeps
track of #include lines in the main translation unit and writes everything up
to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells
the compiler to skip all code in the main TU up to and including `#include
"header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu
without an argument, in that case a `#pragma hrdstop` takes the role of
controlling the point where pch ends and real code begins.)
This patch implements limited support for this in that it requires the pch
header to be passed as a /FI force include flag – with this restriction,
it can be implemented almost completely in the driver with fairly small amounts
of code. For /Yu, this is trivial, and for /Yc a separate pch action is added
that runs before the actual compilation. After r261774, the first failing
command makes a compilation stop – this means if the pch fails to build the
main compilation won't run, which is what we want. However, in /fallback builds
we need to run the main compilation even if the pch build fails so that the
main compilation's fallback can run. To achieve this, add a ForceSuccessCommand
that pretends that the pch build always succeeded in /fallback builds (the main
compilation will then fail to open the pch and run the fallback cl.exe
invocation).
If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl
will now emit a "not implemented yet; flag ignored" warning that can be
disabled using -Wno-clang-cl-pch.
Since clang-cl doesn't yet serialize some important things (most notably
`pragma comment(lib, ...)`, this feature is disabled by default and only
enabled by an internal driver flag. Once it's more stable, this internal flag
will disappear.
(The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not
as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it
does. Implementing support for this should be possible with the approach in
this patch with minimal frontend changes by passing a --stop-at / --start-at
flag from the driver to the frontend. This is left for a follow-up. I don't
think we ever want to support `#pragma hdrstop`, and supporting it with this
approach isn't easy: This approach relies on the driver knowing the pch
filename in advance, and `#pragma hdrstop(out.pch)` can set the output
filename, so the driver can't know about it in advance.)
clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe
would put them, but the pch file format is of course incompatible. This has
ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in
/fallback builds.
http://reviews.llvm.org/D17695
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262420 91177308-0d34-0410-b5e6-96231b3b80d8
This patch expands cc1 option -fprofile-instrument= with a new value: -fprofile-instrument=llvm
which enables IR level PGO instrumentation.
Reviewers: davidxl, silvas
Differential Revision: http://reviews.llvm.org/D17622
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262239 91177308-0d34-0410-b5e6-96231b3b80d8
The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.
When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.
To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.
Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:
"overlay-relative": "true",
"roots": [
...
"type": "directory",
"name": "/usr/include",
"contents": [
{
"type": "file",
"name": "stdio.h",
"external-contents": "/usr/include/stdio.h"
},
...
Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.
This is a useful feature for debugging module crashes in machines other than
the one where the error happened.
Differential Revision: http://reviews.llvm.org/D17457
rdar://problem/24499339
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261552 91177308-0d34-0410-b5e6-96231b3b80d8
The -EHc flag implicitly adds a nothrow attribute to any extern "C"
function when exceptions are enabled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261425 91177308-0d34-0410-b5e6-96231b3b80d8
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261372 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Different devices may in some cases require different code generation schemes in order to implement OpenMP. This is required not only for performance reasons, but also because it may not be possible to have the current (default) implementation working for these devices. E.g. GPU's cannot implement the same scheme a target such as powerpc or x86b would use, in the sense that it does not have the ability to fork threads, instead all the threads are always executing and need to be managed by the implementation.
This patch proposes a reorganization of the code in the OpenMP code generation to pave the way to have specialized implementation of OpenMP support. More than a "real" patch this is more a request for comments in order to understand if what is proposed is acceptable or if there are better/easier ways to do it.
In this patch part of the common OpenMP codegen infrastructure is moved to a new file under a new namespace (CGOpenMPCommon) so it can be shared between the default implementation and the specialized one. When CGOpenMPRuntime is created, an attempt to select a specialized implementation is done.
In the patch a specialization for nvptx targets is done which currently checks if the target is an OpenMP device and trap if it is not.
Let me know comments suggestions you may have.
Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev
Subscribers: Hahnfeld, cfe-commits, fraggamuffin, caomhin, jholewinski
Differential Revision: http://reviews.llvm.org/D16784
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259977 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes cc1 option -fprofile-instr-generate to an enum option
-fprofile-instrument={clang|none}. It also changes cc1 options
-fprofile-instr-generate= to -fprofile-instrument-path=.
The driver level option -fprofile-instr-generate and -fprofile-instr-generate=
remain intact. This change will pave the way to integrate new PGO
instrumentation in IR level.
Review: http://reviews.llvm.org/D16730
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259811 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Turns out the variadic function checking added in r258643 was too strict
for some existing users; give them an escape valve. When
-fcuda-allow-variadic-functions is passed, the front-end makes no
attempt to disallow C-style variadic functions. Calls to va_arg are
still not allowed.
Reviewers: tra
Subscribers: cfe-commits, jhen, echristo, bkramer
Differential Revision: http://reviews.llvm.org/D16559
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258822 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257520 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256933 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256842 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256204 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255694 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254927 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253950 91177308-0d34-0410-b5e6-96231b3b80d8
(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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253886 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253846 91177308-0d34-0410-b5e6-96231b3b80d8
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; }
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253337 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252957 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252463 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce the notion of a module file extension, which introduces
additional information into a module file at the time it is built that
can then be queried when the module file is read. Module file
extensions are identified by a block name (which must be unique to the
extension) and can write any bitstream records into their own
extension block within the module file. When a module file is loaded,
any extension blocks are matched up with module file extension
readers, that are per-module-file and are given access to the input
bitstream.
Note that module file extensions can only be introduced by
programmatic clients that have access to the CompilerInvocation. There
is only one such extension at the moment, which is used for testing
the module file extension harness. As a future direction, one could
imagine allowing the plugin mechanism to introduce new module file
extensions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251955 91177308-0d34-0410-b5e6-96231b3b80d8
Linking options for particular file depend on the option that specifies the file.
Currently there are two:
* -mlink-bitcode-file links in complete content of the specified file.
* -mlink-cuda-bitcode links in only the symbols needed by current TU.
Linked symbols are internalized. This bitcode linking mode is used to
link device-specific bitcode provided by CUDA.
Files are linked in order they are specified on command line.
-mlink-cuda-bitcode replaces -fcuda-uses-libdevice flag.
Differential Revision: http://reviews.llvm.org/D13913
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251427 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251041 91177308-0d34-0410-b5e6-96231b3b80d8
Add -fcoroutines flag (just for -cc1 for now) to enable the feature. Early
indications are that this will be part of -std=c++1z.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250980 91177308-0d34-0410-b5e6-96231b3b80d8
The ELF symbol visibilities are:
- internal: Not visibile across DSOs, cannot pass address across DSOs
- hidden: Not visibile across DSOs, can be called indirectly
- default: Usually visible across DSOs, possibly interposable
- protected: Visible across DSOs, not interposable
LLVM only supports the latter 3 visibilities. Internal visibility is in
theory useful, as it allows you to assume that the caller is maintaining
a PIC register for you in %ebx, or in some other pre-arranged location.
As far as LLVM is concerned, this isn't worth the trouble. Using hidden
visibility is always correct, so we can just do that.
Resolves PR9183.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250954 91177308-0d34-0410-b5e6-96231b3b80d8
This recommits r250398 with fixes to the tests for bot failures.
Add "-target x86_64-unknown-linux" to the clang invocations that
check for the gold plugin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250455 91177308-0d34-0410-b5e6-96231b3b80d8
Rolling this back for now since there are a couple of bot failures on
the new tests I added, and I won't have a chance to look at them in detail
until later this afternoon. I think the new tests need some restrictions on
having the gold plugin available.
This reverts commit r250398.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250402 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add clang support for -flto=thin option, which is used to set the
EmitFunctionSummary code gen option on compiles.
Add -flto=full as an alias to the existing -flto.
Add tests to check for proper overriding of -flto variants on the
command line, and convert grep tests to FileCheck.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, cfe-commits
Differential Revision: http://reviews.llvm.org/D11908
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250398 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for the `-fdebug-prefix-map=` option as in GCC. The syntax is
`-fdebug-prefix-map=OLD=NEW`. When compiling files from a path beginning with
OLD, change the debug info to indicate the path as start with NEW. This is
particularly helpful if you are preprocessing in one path and compiling in
another (e.g. for a build cluster with distcc).
Note that the linearity of the implementation is not as terrible as it may seem.
This is normally done once per file with an expectation that the map will be
small (1-2) entries, making this roughly linear in the number of input paths.
Addresses PR24619.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250094 91177308-0d34-0410-b5e6-96231b3b80d8
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249655 91177308-0d34-0410-b5e6-96231b3b80d8
In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes. It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure). There is a
desire to support __declspec in Playstation code, and possibly other
environments. This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword. Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.
Patch by Warren Ristow!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249279 91177308-0d34-0410-b5e6-96231b3b80d8
* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target specific preprocessor macros.
* pulls in target-specific builtins from aux target.
* sets appropriate host or device attribute on builtins.
Differential Revision: http://reviews.llvm.org/D12917
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248299 91177308-0d34-0410-b5e6-96231b3b80d8
The patch makes it possible to parse CUDA files that contain host/device
functions with identical signatures, but different attributes without
having to physically split source into host-only and device-only parts.
This change is needed in order to parse CUDA header files that have
a lot of name clashes with standard include files.
Gory details are in design doc here: https://goo.gl/EXnymm
Feel free to leave comments there or in this review thread.
This feature is controlled with CC1 option -fcuda-target-overloads
and is disabled by default.
Differential Revision: http://reviews.llvm.org/D12453
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248295 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Do not include default sanitizer blacklists into -M/-MM/-MD/-MMD output.
Introduce a frontend option -fdepfile-entry, and only insert them
for the user-defined sanitizer blacklists. In frontend, grab ExtraDeps
from -fdepfile-entry, instead of -fsanitize-blacklist.
Reviewers: rsmith, pcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12544
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246700 91177308-0d34-0410-b5e6-96231b3b80d8
to enable the use of external type references in the debug info
(a.k.a. module debugging).
The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs"
and passes that to cc1. All this does at the moment is set a flag
codegenopts.
http://reviews.llvm.org/D11958
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246192 91177308-0d34-0410-b5e6-96231b3b80d8
file in the .pcm files. This allows a smaller set of files to be sent to a
remote build worker when building with explicit modules (for instance, module
map files need not be sent along with the corresponding precompiled modules).
This doesn't actually make the embedded files visible to header search, so
it's not useful as a packaging format for public header files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245028 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Clang sanitizers, such as AddressSanitizer, ThreadSanitizer, MemorySanitizer,
Control Flow Integrity and others, use blacklists to specify which types / functions
should not be instrumented to avoid false positives or suppress known failures.
This change adds the blacklist filenames to the list of dependencies of the rules,
generated with -M/-MM/-MD/-MMD. This lets CMake/Ninja recognize that certain
C/C++/ObjC files need to be recompiled (if a blacklist is updated).
Reviewers: pcc
Subscribers: rsmith, honggyu.kim, pcc, cfe-commits
Differential Revision: http://reviews.llvm.org/D11968
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244867 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can
force emission of one or both by passing -gcodeview and -gdwarf to
either driver.
Reviewers: dblaikie, hans
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11742
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244097 91177308-0d34-0410-b5e6-96231b3b80d8
The new EH instructions make it possible for LLVM to generate .xdata
tables that the MSVC personality routines will be happy about. Because
this is experimental, hide it behind a -cc1 flag (-fnew-ms-eh).
Differential Revision: http://reviews.llvm.org/D11405
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243767 91177308-0d34-0410-b5e6-96231b3b80d8
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243642 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, -save-temp will cause ObjCARC optimization to be dropped,
sanitizer pass to run early in the pipeline, and profiling
instrumentation to run twice.
Fix the issue by properly disable all passes in the optimization
pipeline when generating bitcode output and parse some of the Language
Options even when the input is bitcode so the passes can be setup
correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242565 91177308-0d34-0410-b5e6-96231b3b80d8
- introduces a new cc1 option -fmodule-format=[raw,obj]
with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
a PCHContainerReader.
Thanks to Richard Smith for reviewing this patch!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242499 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is the same except for the addition of a new test for the
issue that required reverting the dependent llvm commit.
--Original Commit Message--
Pass down the -flto option to the -cc1 job, and from there into the
CodeGenOptions and onto the PassManagerBuilder. This enables gating
the new EliminateAvailableExternally module pass on whether we are
preparing for LTO.
If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not
included as we want to preserve available externally functions for possible
link time inlining.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241467 91177308-0d34-0410-b5e6-96231b3b80d8
Any extra features from -fmodule-feature are part of the module hash and
need to get validated on load. Also print them with -module-file-info.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240433 91177308-0d34-0410-b5e6-96231b3b80d8
Such conflicts are an accident waiting to happen, and this feature conflicts
with the desire to include existing headers into multiple modules and merge the
results. (In an ideal world, it should not be possible to export internal
linkage symbols from a module, but sadly the glibc and libstdc++ headers
provide 'static inline' functions in a few cases.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240335 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240105 91177308-0d34-0410-b5e6-96231b3b80d8
We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.
The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239789 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The goal of this patch is to make `-verify` easier to use when testing libc++. The `notes` attached to compile error diagnostics are numerous and relatively unstable when they reference libc++ header internals. This patch allows libc++ to write stable compilation failure tests by allowing unexpected diagnostic messages to be ignored where they are not relevant.
This patch adds a new CC1 flag called `-verify-ignore-unexpected`. `-verify-ignore-unexpected` tells `VerifyDiagnosticsConsumer` to ignore *all* unexpected diagnostic messages. `-verify-ignore-unexpected=<LevelList>` can be used to only ignore certain diagnostic levels. `<LevelList>` is a comma separated list of diagnostic levels to ignore. The supported levels are `note`, `remark`, `warning` and `error`.
Reviewers: bogner, grosser, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10138
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239665 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenOptions and onto the PassManagerBuilder. This enables gating
the new EliminateAvailableExternally module pass on whether we are
preparing for LTO.
If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not
included as we want to preserve available externally functions for possible
link time inlining.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239481 91177308-0d34-0410-b5e6-96231b3b80d8
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238601 91177308-0d34-0410-b5e6-96231b3b80d8
in-progress implementation of the Concepts TS. The recommended feature
test macro __cpp_experimental_concepts is set to 1 (as opposed to
201501) to indicate that the feature is enabled, but the
implementation is incomplete.
The link to the Concepts TS in cxx_status is updated to refer to the
PDTS (N4377). Additional changes related to __has_feature and
__has_extension are to follow in a later change.
Relevant tests include:
test/Lexer/cxx-features.cpp
The test file is updated with testing of the C++14 + Concepts TS mode.
The expected behaviour is the same as that of the C++14 modes except
for the case of __cpp_experimental_concepts."
- Hubert Tong.
Being committed for Hubert (as per his understanding with Richard Smith) as we start work on the concepts-ts following our preliminary strategy session earlier today.
The patch is tiny and seems quite standard.
Thanks Hubert!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237982 91177308-0d34-0410-b5e6-96231b3b80d8
-fopenmp turns on OpenMP support and links libiomp5 as OpenMP library. Also there is -fopenmp={libiomp5|libgomp} option that allows to override effect of -fopenmp and link libgomp library (if -fopenmp=libgomp is specified).
Differential Revision: http://reviews.llvm.org/D9736
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237769 91177308-0d34-0410-b5e6-96231b3b80d8
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237473 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
r235215 enables support in LLVM for legalizing f16 type in the IR. AArch64
already had support for this. r235215 and some backend patches brought support
for ARM, X86, X86-64, Mips and Mips64.
This change exposes the LangOption 'NativeHalfType' in the command line, so the
backend legalization can be used if desired. NativeHalfType is enabled for
OpenCL (current behavior) or if '-fnative-half-type' is set.
Reviewers: olista01, steven_wu, ab
Subscribers: cfe-commits, srhines, aemerson
Differential Revision: http://reviews.llvm.org/D9781
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237406 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we were setting LangOptions::GNUInline (which controls whether we
use traditional GNU inline semantics) if the language did not have the C99
feature flag set. The trouble with this is that C++ family languages also
do not have that flag set, so we ended up setting this flag in C++ modes
(and working around it in a few places downstream by also checking CPlusPlus).
The fix is to check whether the C89 flag is set for the target language,
rather than whether the C99 flag is cleared. This also lets us remove most
CPlusPlus checks. We continue to test CPlusPlus when deciding whether to
pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC.
There is a change in semantics in two other places
where we weren't checking both CPlusPlus and GNUInline
(FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and
FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to
put us back into line with GCC's semantics (test case: test/CodeGen/inline.c).
While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it,
it didn't have any effect before, and supporting it just makes things more
complicated.
Differential Revision: http://reviews.llvm.org/D9333
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237299 91177308-0d34-0410-b5e6-96231b3b80d8
- added -fcuda-include-gpubinary option to incorporate results of
device-side compilation into host-side one.
- generate code to register GPU binaries and associated kernels
with CUDA runtime and clean-up on exit.
- added test case for init/deinit code generation.
Differential Revision: http://reviews.llvm.org/D9507
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236765 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236756 91177308-0d34-0410-b5e6-96231b3b80d8
This flag specifies that the normal visibility rules should be used even for
local submodules (submodules of the currently-being-built module). Thus names
will only be visible if a header / module that declares them has actually been
included / imported, and not merely because a submodule that happened to be
built earlier declared those names. This also removes the need to modularize
bottom-up: textually-included headers will be included into every submodule
that includes them, since their include guards will not leak between modules.
So far, this only governs visibility of macros, not of declarations, so is not
ready for real use yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236350 91177308-0d34-0410-b5e6-96231b3b80d8
This change is the third of 3 patches to add support for specifying
the profile output from the command line via -fprofile-instr-generate=<path>,
where the specified output path/file will be overridden by the
LLVM_PROFILE_FILE environment variable.
This patch adds the necessary support to the clang frontend, and adds a
new test.
The compiler-rt and llvm parts are r236055 and r236288, respectively.
Patch by Teresa Johnson. Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236289 91177308-0d34-0410-b5e6-96231b3b80d8
NMake is a Make-like builder that comes with Microsoft Visual Studio.
Jom (https://wiki.qt.io/Jom) is an NMake-compatible build tool.
Dependency files for NMake/Jom need to use double-quotes to wrap
filespecs containing special characters, instead of the backslash
escapes that GNU Make wants.
Adds the -MV option, which specifies to use double-quotes as needed
instead of backslash escapes when writing the dependency file.
Differential Revision: http://reviews.llvm.org/D9260
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235903 91177308-0d34-0410-b5e6-96231b3b80d8
For CUDA source, Sema checks that the targets of call expressions make sense
(e.g. a host function can't call a device function).
Adding a flag that lets us skip this check. Motivation: for source-to-source
translation tools that have to accept code that's not strictly kosher CUDA but
is still accepted by nvcc. The source-to-source translation tool can then fix
the code and leave calls that are semantically valid for the actual compilation
stage.
Differential Revision: http://reviews.llvm.org/D9036
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235049 91177308-0d34-0410-b5e6-96231b3b80d8
Stop relying on `cl::opt` to pass along the driver's decision to
preserve use-lists. Create a new `-cc1` option called
`-emit-llvm-uselists` that does the right thing (when -emit-llvm-bc).
Note that despite its generic name, it *doesn't* do the right thing when
-emit-llvm (LLVM assembly) yet. I'll hook that up soon.
This doesn't really change the behaviour of the driver. The default is
still to preserve use-lists for `clang -emit-llvm` and `clang
-save-temps`, and nothing else. But it stops relying on global state
(and also is a nicer interface for hackers using `clang -cc1`).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234962 91177308-0d34-0410-b5e6-96231b3b80d8
Follow-up to r234666. With this, the -m[no-]global-merge options
have the expected behavior. Previously, -mglobal-merge was ignored,
and there was no way of enabling the optimization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234668 91177308-0d34-0410-b5e6-96231b3b80d8
The driver currently accepts but ignores the -freciprocal-math flag.
This patch passes the flag through and enables 'arcp' fast-math-flag
generation in IR.
Note that this change does not actually enable the optimization for
any target. The reassociation optimization that this flag specifies
was implemented by http://reviews.llvm.org/D6334 :
http://llvm.org/viewvc/llvm-project?view=revision&revision=222510
Because the optimization is done in the backend rather than IR,
the backend must be modified to understand instruction-level
fast-math-flags or a new function-level attribute must be created.
Also note that -freciprocal-math is independent of any target-specific
usage of reciprocal estimate hardware instructions. That requires
its own flag ('-mrecip').
https://llvm.org/bugs/show_bug.cgi?id=20912
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234493 91177308-0d34-0410-b5e6-96231b3b80d8
Decide whether or not to use thread-safe statics depending on whether or
not we have an explicit request from the driver. If we don't have an
explicit request, infer which behavior to use depending on the
compatibility version we are targeting.
N.B. CodeGen support is still ongoing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232906 91177308-0d34-0410-b5e6-96231b3b80d8
There are no widely deployed standard libraries providing sized
deallocation functions, so we have to punt and ask the user if they want
us to use sized deallocation. In the future, when such libraries are
deployed, we can teach the driver to detect them and enable this
feature.
N3536 claimed that a weak thunk from sized to unsized deallocation could
be emitted to avoid breaking backwards compatibility with standard
libraries not providing sized deallocation. However, this approach and
other variations don't work in practice.
With the weak function approach, the thunk has to have default
visibility in order to ensure that it is overridden by other DSOs
providing sized deallocation. Weak, default visibility symbols are
particularly expensive on MachO, so John McCall was considering
disabling this feature by default on Darwin. It also changes behavior
ELF linking behavior, causing certain otherwise unreferenced object
files from an archive to be pulled into the link.
Our second approach was to use an extern_weak function declaration and
do an inline conditional branch at the deletion call site. This doesn't
work because extern_weak only works on MachO if you have some archive
providing the default value of the extern_weak symbol. Arranging to
provide such an archive has the same challenges as providing the symbol
in the standard library. Not to mention that extern_weak doesn't really
work on COFF.
Reviewers: rsmith, rjmccall
Differential Revision: http://reviews.llvm.org/D8467
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232788 91177308-0d34-0410-b5e6-96231b3b80d8
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232622 91177308-0d34-0410-b5e6-96231b3b80d8
This exposes the optional exit block placement logic from r232438 as a
clang -cc1 option. There is a test on the llvm side, but there isn't
really a way to inspect the gcov options from clang to test it here as
well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232439 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the -fapplication-extension option, along with the
ios_app_extension and macosx_app_extension availability attributes.
Patch by Ted Kremenek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230989 91177308-0d34-0410-b5e6-96231b3b80d8
Currently -fms-extensions controls this behavior, which doesn't make
much sense. It means we can't identify what is and isn't a system header
when compiling our own preprocessed output, because #line doesn't
represent this information.
If someone is feeding Clang's preprocessed output to another compiler,
they can use this flag.
Fixes PR20553.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D5217
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230587 91177308-0d34-0410-b5e6-96231b3b80d8
For now -funique-section-names is the default, so no change in default behavior.
The total .o size in a build of llvm and clang goes from 241687775 to 230649031
bytes if -fno-unique-section-names is used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230031 91177308-0d34-0410-b5e6-96231b3b80d8
If this flag is set, we error out when a module build is required. This is
useful in environments where all required modules are passed via -fmodule-file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230006 91177308-0d34-0410-b5e6-96231b3b80d8
I didn't realize how easily the hostname could change - for example just
changing wireless networks seems to prompt it in some cases.
Users can always set their own local module cache path to avoid this.
This reverts commits r228592, 228594, 228601 and 228613.
rdar://19287368
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229815 91177308-0d34-0410-b5e6-96231b3b80d8
The current implementation causes link-time ODR violations when the delete symbols are exported into the dynamic table.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229241 91177308-0d34-0410-b5e6-96231b3b80d8
The /volatile:ms semantics turn volatile loads and stores into atomic
acquire and release operations. This distinction is important because
volatile memory operations do not form a happens-before relationship
with non-atomic memory. This means that a volatile store is not
sufficient for implementing a mutex unlock routine.
Differential Revision: http://reviews.llvm.org/D7580
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229082 91177308-0d34-0410-b5e6-96231b3b80d8
Don't assume it will provide an error or null-terminate the string on
truncation, since POSIX doesn't guarantee either behaviour (although
Linux and Darwin at least will do the 'right thing').
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228613 91177308-0d34-0410-b5e6-96231b3b80d8
If gethostname() is not successful, just skip adding the hostname to the
module hash. And don't bother setting hostname[255] = 0, since if
gethostname() is successful, it will be null-terminated already (and if
it's not successful we don't read the string now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228601 91177308-0d34-0410-b5e6-96231b3b80d8
Sharing between hosts will cause problems for the LockFileManager, which
can timeout waiting for a process that has already died.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228592 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Allow user to provide multiple blacklists by passing several
-fsanitize-blacklist= options. These options now don't override
default blacklist from Clang resource directory, which is always
applied (which fixes PR22431).
-fno-sanitize-blacklist option now disables all blacklists that
were specified earlier in the command line (including the default
one).
This change depends on http://reviews.llvm.org/D7367.
Test Plan: regression test suite
Reviewers: timurrrr
Subscribers: cfe-commits, kcc, pcc
Differential Revision: http://reviews.llvm.org/D7368
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228156 91177308-0d34-0410-b5e6-96231b3b80d8
This allows clang-based tools to specify custom features that can be
tested by the 'requires' declaration in a module map file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227868 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch add a new option to dis-allow all inline asm.
Any GCC style inline asm will be reported as an error.
Reviewers: rnk, echristo
Reviewed By: rnk, echristo
Subscribers: bob.wilson, rnk, echristo, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D6870
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226340 91177308-0d34-0410-b5e6-96231b3b80d8
Sorry for the noise, I managed to miss a bunch of recent regressions of
include orderings here. This should actually sort all the includes for
Clang. Again, no functionality changed, this is just a mechanical
cleanup that I try to run periodically to keep the #include lines as
regular as possible across the project.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225979 91177308-0d34-0410-b5e6-96231b3b80d8
A pass that adds random noops to X86 binaries to introduce diversity with the goal of increasing security against most return-oriented programming attacks.
Command line options:
-noop-insertion // Enable noop insertion.
-noop-insertion-percentage=X // X% of assembly instructions will have a noop prepended (default: 50%, requires -noop-insertion)
-max-noops-per-instruction=X // Randomly generate X noops per instruction. ie. roll the dice X times with probability set above (default: 1). This doesn't guarantee X noop instructions.
In addition, the following 'quick switch' in clang enables basic diversity using default settings (currently: noop insertion and schedule randomization; it is intended to be extended in the future).
-fdiversify
This is the clang part of the patch.
llvm part: D3392
http://reviews.llvm.org/D3393
Patch by Stephen Crane (@rinon)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225910 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225719 91177308-0d34-0410-b5e6-96231b3b80d8
Allow blessed access to the symbol rewriter from the driver. Although the
symbol rewriter could be invoked through tools like opt and llc, it would not
accessible from the frontend. This allows us to read the rewrite map files in
the frontend rather than the backend and enable symbol rewriting for actually
performing the symbol interpositioning.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225504 91177308-0d34-0410-b5e6-96231b3b80d8
getMainExecutable() returns a std::string, assigning its result
to StringRef immediately creates a dangling pointer. This was
detected by half-broken fast-MSan-bootstrap bot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224956 91177308-0d34-0410-b5e6-96231b3b80d8
a CLANG_LIBDIR_SUFFIX down from the build system and using that as part
of the default resource dir computation.
Without this, essentially nothing that uses the clang driver works when
building clang with a libdir suffix. This is probably the single biggest
missing piece of support for multilib as without this people could hack
clang to end up installed in the correct location, but it would then
fail to find its own basic resources. I know of at least one distro that
has some variation on this patch to hack around this; hopefully they'll
be able to use the libdir suffix functionality directly as the rest of
these bits land.
This required fixing a copy of the code to compute Clang's resource
directory that is buried inside of the frontend (!!!). It had bitrotted
significantly relative to the driver code. I've made it essentially
a clone of the driver code in order to keep tests (which use cc1
heavily) passing. This copy should probably just be removed and the
frontend taught to always rely on an explicit resource directory from
the driver, but that is a much more invasive change for another day.
I've also updated one test which actually encoded the resource directory
in its checked output to tolerate multilib suffixes.
Note that this relies on a prior LLVM commit to add a stub to the
autoconf build system for this variable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224924 91177308-0d34-0410-b5e6-96231b3b80d8
-trigraphs is now an alias for -ftrigraphs. -fno-trigraphs makes it possible
to explicitly disable trigraphs, which couldn't be done before.
clang -std=c++11 -fno-trigraphs
now builds without GNU extensions, but with trigraphs disabled. Previously,
trigraphs were only disabled in GNU modes or with -std=c++1z.
Make the new -f flags the cc1 interface too. This requires changing -trigraphs
to -ftrigraphs in a few cc1 tests.
Related to PR21974.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224790 91177308-0d34-0410-b5e6-96231b3b80d8
The default value of Opts.Trigraphs now no longer depends solely on the
language input kind, so move the code out of setLangDefaults(). Also make
sure that Opts.MSVCCompat is set before the Trigraph code runs.
Related to PR21974.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224719 91177308-0d34-0410-b5e6-96231b3b80d8
We were checking the value after truncating it to a bitfield.
Thanks to Yunzhong Gao for noticing it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224378 91177308-0d34-0410-b5e6-96231b3b80d8
Remove Sema::UnqualifiedTyposCorrected, a cache of corrected typos. It would only cache typo corrections that didn't provide ValidateCandidate of which there were few left, and it had a bug when we had the same identifier spelled wrong twice. See the last two tests in typo-correction.cpp for cases this fires.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224375 91177308-0d34-0410-b5e6-96231b3b80d8
arithmetic relaxation flags:
-cl-no-signed-zeros
-cl-unsafe-math-optimizations
-cl-finite-math-only
-cl-fast-relaxed-math
Propagate the info to FP instruction flags as well
as function attributes where they are available.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223928 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223913 91177308-0d34-0410-b5e6-96231b3b80d8
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223753 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Allow CUDA host device functions with two code paths using __CUDA_ARCH__
to differentiate between code path being compiled.
For example:
__host__ __device__ void host_device_function(void) {
#ifdef __CUDA_ARCH__
device_only_function();
#else
host_only_function();
#endif
}
Patch by Jacques Pienaar.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D6457
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223271 91177308-0d34-0410-b5e6-96231b3b80d8
This option sets language mode for the compilation of a source file to be OpenCL v2.0.
Example: clang -cc1 -cl-std=CL2.0 myfile.cl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222444 91177308-0d34-0410-b5e6-96231b3b80d8
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221963 91177308-0d34-0410-b5e6-96231b3b80d8
Get rid of ugly SanitizerOptions class thrust into LangOptions:
* Make SanitizeAddressFieldPadding a regular language option,
and rely on default behavior to initialize/reset it.
* Make SanitizerBlacklistFile a regular member LangOptions.
* Introduce the helper class "SanitizerSet" to represent the
set of enabled sanitizers and make it a member of LangOptions.
It is exactly the entity we want to cache and modify in CodeGenFunction,
for instance. We'd also be able to reuse SanitizerSet in
CodeGenOptions for storing the set of recoverable sanitizers,
and in the Driver to represent the set of sanitizers
turned on/off by the commandline flags.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221653 91177308-0d34-0410-b5e6-96231b3b80d8
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221558 91177308-0d34-0410-b5e6-96231b3b80d8
,-objcmt-migrate-property-dot-syntax, when migarting to use
property-dot syntax in place of messaging expression.
rdar://18839124
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221001 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, when --serialize-diagnostics is passed this only includes
the diagnostics from clang -cc1, and driver diagnostics are
dropped. This causes issues for tools that use the serialized
diagnostics, since stderr is lost and these diagnostics aren't seen at
all.
We handle this by merging the diagnostics from the CC1 process and the
driver diagnostics into a single file when the driver invokes CC1.
Fixes rdar://problem/10585062
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220525 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When using a profile, we used to require the use -gmlt so that we could
get access to the line locations. This is used to match line numbers in
the input profile to the line numbers in the function's IR.
But this is actually not necessary. The driver can provide source
location tracking without the emission of debug information. In these
cases, the annotation 'llvm.dbg.cu' is missing from the IR, but the
actual line location annotations are still present.
This patch tells the driver to only emit source location tracking
when -fprofile-sample-use is present in the command line.
Reviewers: echristo, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5888
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220383 91177308-0d34-0410-b5e6-96231b3b80d8
Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.
This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220359 91177308-0d34-0410-b5e6-96231b3b80d8
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220244 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a flag called -fseh-exceptions that uses the native Windows
.pdata and .xdata unwind mechanism to throw exceptions. The other EH
possibilities are DWARF and SJLJ exceptions.
Patch by Martell Malone!
Reviewed By: asl, rnk
Differential Revision: http://reviews.llvm.org/D3419
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217790 91177308-0d34-0410-b5e6-96231b3b80d8
People have been incorrectly using "-analyzer-disable-checker" to
silence analyzer warnings on a file, when analyzing a project. Add
the "-analyzer-disable-all-checks" option, which would allow the
suppression and suggest it as part of the error message for
"-analyzer-disable-checker". The idea here is to compose this with
"--analyze" so that users can selectively opt out specific files from
static analysis.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216763 91177308-0d34-0410-b5e6-96231b3b80d8
ACLE 2.0 allows __fp16 to be used as a function argument or return
type. This enables this for AArch64.
This also fixes an existing bug that causes clang to not allow
homogeneous floating-point aggregates with a base type of __fp16. This
is valid for AAPCS64, but not for AAPCS-VFP.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216558 91177308-0d34-0410-b5e6-96231b3b80d8
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215982 91177308-0d34-0410-b5e6-96231b3b80d8
anyway. If -ast-dump *is* also provided, then dump the AST declarations as well
as the lookup results. This is invaluable for cross-correlating the lookup
information with the declarations actually found.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215393 91177308-0d34-0410-b5e6-96231b3b80d8
intent when we added remark support, but was never implemented in the general
case, because the first -R flags didn't need it. (-Rpass= had special handling
to accomodate its argument.)
-Rno-foo, -Reverything, and -Rno-everything can be used to turn off a remark,
or to turn on or off all remarks. Per discussion on cfe-commits, -Weverything
does not affect remarks, and -Reverything does not affect warnings or errors.
The only "real" -R flag we have right now is -Rmodule-build; that flag is
effectively renamed from -Wmodule-build to -Rmodule-build by this change.
-Wpass and -Wno-pass (and their friends) are also renamed to -Rpass and
-Rno-pass by this change; it's not completely clear whether we intended to have
a -Rpass (with no =pattern), but that is unchanged by this commit, other than
the flag name. The default pattern is effectively one which matches no passes.
In future, we may want to make the default pattern be .*, so that -Reverything
works for -Rpass properly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215046 91177308-0d34-0410-b5e6-96231b3b80d8
to instruct the code generator to not enforce a higher alignment
than the given number (of bytes) when accessing memory via an opaque
pointer or reference. Patch reviewed by John McCall (with post-commit
review pending). rdar://16254558
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214911 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the '-fcoverage-mapping' option which
allows clang to generate the coverage mapping information
that can be used to provide code coverage analysis using
the execution counts obtained from the instrumentation
based profiling (-fprofile-instr-generate).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214752 91177308-0d34-0410-b5e6-96231b3b80d8
This flag specifies that we are building an implementation file of the
module <name>, preventing importing <name> as a module. This does not
consider this to be the 'current module' for the purposes of doing
modular checks like decluse or non-modular-include warnings, unlike
-fmodule-name.
This is needed as a stopgap until:
1) we can resolve relative includes to a VFS-mapped module (or can
safely import a header textually and as part of a module)
and ideally
2) we can safely do incremental rebuilding when implementation files
import submodules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213767 91177308-0d34-0410-b5e6-96231b3b80d8
This restores the original behaviour of -fmsc-version. The older option
remains as a mechanism for specifying the basic version information. A
secondary option, -fms-compatibility-version permits the user to specify an
extended version to the driver.
The new version takes the value as a dot-separated value rather than the
major * 100 + minor format that -fmsc-version format. This makes it easier to
specify the value as well as a more flexible manner for specifying the value.
Specifying both values is considered an error.
The older parameter is left solely as a driver option, which is normalised into
the newer parameter. This allows us to retain a single code path in the
compiler itself whilst preserving the semantics of the old parameter as well as
avoid having to determine which of two formats are being used by the invocation.
The test changes are due to the fact that the compiler no longer supports the
old option, and is a direct conversion to the new option.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213119 91177308-0d34-0410-b5e6-96231b3b80d8
There are slight differences between /GR- and -fno-rtti which made
mapping one to the other inappropriate.
-fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related
information for the v-table.
/GR- does not generate complete object locators and thus will not
reference them in vftables. However, constructs like dynamic_cast and
typeid are permitted.
This should bring our implementation of RTTI up to semantic parity with
MSVC modulo bugs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212138 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This new debug emission kind supports emitting line location
information in all instructions, but stops code generation
from emitting debug info to the final output.
This mode is useful when the backend wants to track source
locations during code generation, but it does not want to
produce debug info. This is currently used by optimization
remarks (-Rpass, -Rpass-missed and -Rpass-analysis).
When one of the -Rpass flags is used, the front end will enable
location tracking, only if no other debug option is enabled.
To prevent debug information from being generated, a new debug
info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to
not emit the llvm.dbg.cu annotation. This blocks final code generation
from generating debug info in the back end.
Depends on D4234.
Reviewers: echristo, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4235
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211610 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure that we properly handle the case where just the major version component
is provided by the user.
Thanks to Alp Toker for pointing out that this was not handled correctly!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211506 91177308-0d34-0410-b5e6-96231b3b80d8
The version information for Visual Studio is spread over multiple variables.
The newer Windows SDK has started making use of some of the extended versioning
variables that were previously undefined. Enhance our compatibility definitions
for these cases.
_MSC_VER is defined to be the Major * 100 + Minor. _MSC_FULL_VER is defined to
be Major * 10000000 + Minor * 100000 + Build. And _MSC_BUILD is the build
revision of the compiler.
Extend the -fmsc-version option in a compatible manner. If the value is the
previous form of MMmm, then we assume that the build number is 0. Otherwise, a
specific build number may be passed by using the form MMmmbbbbb. Due to
bitwidth limitations of the option, it is currently not possible to define a
revision value.
The version information can be passed as either the decimal encoded value
(_MSC_FULL_VER or _MSC_VER) or as a dot-delimited value.
The change to the TextDiagnostic is to deal with the updated encoding of the
version information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211420 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the -module-dependency-dir to clang -cc1, which specifies a
directory to copy all of a module's dependencies into in a form
suitable to be used as a VFS using -ivfsoverlay with the generated
vfs.yaml.
This is useful for crashdumps that involve modules, so that the module
dependencies will be intact when a crash report script is used to
reproduce a problem on another machine.
We currently encode the absolute path to the dump directory, due to
limitations in the VFS system. Until we can handle relative paths in
the VFS, users of the VFS map may need to run a simple search and
replace in the file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211303 91177308-0d34-0410-b5e6-96231b3b80d8
The parsing for -Rpass= had been factored into the function
GenerateOptimizationRemarkRegex, but at the time I forgot to remove
the original code that just handled OPT_Rpass_EQ.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211122 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
These two flags are in the same family as -Rpass, but are used in
different situations.
-Rpass-missed is used by optimizers to inform the user when they tried
to apply an optimization but couldn't (or wouldn't).
-Rpass-analysis is used by optimizers to report analysis results back
to the user (e.g., why the transformation could not be applied).
Depends on D3682.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3683
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209839 91177308-0d34-0410-b5e6-96231b3b80d8
Also provide an out-of-line dtor for CompilerInvocation.
Cleanup work that may help reduce header inclusion for IntrusiveRefCntPtr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208512 91177308-0d34-0410-b5e6-96231b3b80d8
This addresses an existing FIXME item in the driver. The code model flag was
parsed in the actual tool rather than in the driver. This was problematic since
the value may be invalid. In that case, we would silently treat it as a default
value in non-assert builds, and abort in assert builds. Add a check in the
driver to validate that the value being passed is valid, and if not provide a
proper error message.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208275 91177308-0d34-0410-b5e6-96231b3b80d8
whether the definition of the template is visible rather than checking whether
the instantiated definition happens to be in an imported module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208150 91177308-0d34-0410-b5e6-96231b3b80d8
After this patch clang will ignore -fdwarf2-cfi-asm and -ffno-dwarf2-cfi-asm and
always print assembly that uses cfi directives.
In llvm, MC itself supports cfi since the end of 2010 (support started
in r119972, is reported in the 2.9 release notes).
In binutils the support has been around for much longer. It looks like
support started to be added in May 2003. It is available in 2.15
(31-Aug-2011, 2.14 is from 12-Jun-2003).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207602 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds a new flag -Rpass=. The flag indicates the name
of the optimization pass that should emit remarks stating when it
made a transformation to the code.
This implements the design I proposed in:
https://docs.google.com/document/d/1FYUatSjZZO-zmFBxjOiuOzAy9mhHA8hqdvklZv68WuQ/edit?usp=sharing
Other changes:
- Add DiagnosticIDs::isRemark(). Use it in printDiagnosticOptions to
print "-R" instead of "-W" in the diagnostic message.
- In BackendConsumer::OptimizationRemarkHandler, get a SourceLocation
object out of the file name, line and column number. Use that location
in the call to Diags.Report().
- When -Rpass is used without debug info a note is emitted alerting
the user that they need to use -gline-tables-only -gcolumn-info to
get this information.
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3226
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206401 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This allows them to be used without -cc1 the same way as -I and -isystem.
Renamed the options to --system-header-prefix=/--no-system-header-prefix to avoid interference with -isystem and make the intent of the option cleaner.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3185
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204775 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204346 91177308-0d34-0410-b5e6-96231b3b80d8
Since "half" is an OpenCL keyword and clang accepts __fp16 as an extension for
other languages, error messages and metadata (and hence debug info) should refer
to the half-precision floating point as "__fp16" instead of "half" when
compiling for non-OpenCL languages. This patch creates a new printing policy for
half in a similar manner to what is done for bool and wchar_t.
Differential Revision: http://llvm-reviews.chandlerc.com/D2952
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204164 91177308-0d34-0410-b5e6-96231b3b80d8
This is because the PCH is tied to the module files, if one of the module files changes or gets removed
the build system should re-build the PCH file.
rdar://16321245
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203885 91177308-0d34-0410-b5e6-96231b3b80d8
When enabled, always validate the system headers when loading a module.
The end result of this is that when these headers change, we will notice
and rebuild the module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203630 91177308-0d34-0410-b5e6-96231b3b80d8
This is used to avoid conflicts with user modules with the same name from different workspaces.
rdar://16042513
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202683 91177308-0d34-0410-b5e6-96231b3b80d8
Reads the description of a virtual filesystem from a file and overlays
it over the real file system.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202176 91177308-0d34-0410-b5e6-96231b3b80d8
The integrated assembler is a feature. This makes the new flags the default
option, and the previous versions aliases. Ideally, at some point the aliases
would be entirely removed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201963 91177308-0d34-0410-b5e6-96231b3b80d8
These features are new in VS 2013 and are necessary in order to layout
std::ostream correctly. Currently we have an ABI incompatibility when
self-hosting with the 2013 stdlib in our convertible_fwd_ostream wrapper
in gtest.
This change adds another implicit attribute, MSVtorDispAttr, because
implicit attributes are currently the best way to make sure the
information stays on class templates through instantiation.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2746
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201274 91177308-0d34-0410-b5e6-96231b3b80d8
the build
When Clang loads the module, it verifies the user source files that the module
was built from. If any file was changed, the module is rebuilt. There are two
problems with this:
1. correctness: we don't verify system files (there are too many of them, and
stat'ing all of them would take a lot of time);
2. performance: the same module file is verified again and again during a
single build.
This change allows the build system to optimize source file verification. The
idea is based on the fact that while the project is being built, the source
files don't change. This allows us to verify the module only once during a
single build session. The build system passes a flag,
-fbuild-session-timestamp=, to inform Clang of the time when the build started.
The build system also requests to enable this feature by passing
-fmodules-validate-once-per-build-session. If these flags are not passed, the
behavior is not changed. When Clang verifies the module the first time, it
writes out a timestamp file. Then, when Clang loads the module the second
time, it finds a timestamp file, so it can compare the verification timestamp
of the module with the time when the build started. If the verification
timestamp is too old, the module is verified again, and the timestamp file is
updated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201224 91177308-0d34-0410-b5e6-96231b3b80d8
This option will:
- load the given pch file
- verify it is not out of date by stat'ing dependencies, and
- return 0 on success and non-zero on error
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200884 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199372 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199250 91177308-0d34-0410-b5e6-96231b3b80d8
Full language modes usually get listed before minor language extensions in
LangOpts, so that subsequent sub-modes can predicate on the major modes.
This also lends to a cleanup in CompilerInvocation to better indicate to the
reader that MSVCCompat is a superset of MicrosoftExt.
Cleanup only.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199210 91177308-0d34-0410-b5e6-96231b3b80d8
There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.
MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.
MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.
Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.
See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'
No change in behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199209 91177308-0d34-0410-b5e6-96231b3b80d8
It controls everything that -flimit-debug-info used to, plus the
vtable type optimization. The old -fno-limit-debug-info option is now an
alias to -fstandalone-debug and vice versa.
Standalone is the default on Darwin until dtrace is updated to work with
non-standalone debug info (rdar://problem/15758808).
Note: I kept the LimitedDebugInfo name in CodeGenOptions::DebugInfoKind
because NoStandaloneDebugInfo sounded even more confusing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198655 91177308-0d34-0410-b5e6-96231b3b80d8
There are about 30 removed in this patch, generated by a new FixIt I haven't
got round to submitting yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195814 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently with clang:
$ clang -O20 foo.c
error: invalid value '20' in '-O20'
With the patch:
$ clang -O20 foo.c
warning: optimization level '-O20' is unsupported; using '-O3' instead.
1 warning generated.
This matches the gcc behavior (with a warning added)
Pass all tests:
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 94.14s
Expected Passes : 6721
Expected Failures : 20
Unsupported Tests : 17
(which was not the case of http://llvm-reviews.chandlerc.com/D2125)
Differential Revision: http://llvm-reviews.chandlerc.com/D2212
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195009 91177308-0d34-0410-b5e6-96231b3b80d8
This adds -freroll-loops (and -fno-reroll-loops in the usual way) to enable
loop rerolling as part of the optimization pass manager. This transformation
can enable vectorization, reduce code size (or both).
Briefly, loop rerolling can transform a loop like this:
for (int i = 0; i < 3200; i += 5) {
a[i] += alpha * b[i];
a[i + 1] += alpha * b[i + 1];
a[i + 2] += alpha * b[i + 2];
a[i + 3] += alpha * b[i + 3];
a[i + 4] += alpha * b[i + 4];
}
into this:
for (int i = 0; i < 3200; ++i) {
a[i] += alpha * b[i];
}
Loop rerolling is currently disabled by default at all optimization levels.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194967 91177308-0d34-0410-b5e6-96231b3b80d8
Trying to fix test failures since earlier today.
One of the tests added in this commit is outputting test/Driver/clang_f_opts.s
which the builders that build in-tree (eg. clang-native-arm-cortex-a9) are
trying to run as a test case, causing failures.
clang_f_opts.c:
If -### doesn't emit the warning then this test probably shouldn't be in
here in the first place. Frontend maybe?
invalid-o-level.c:
Running %clang_cc1 in the Driver tests doesn't make sense because -cc1
bypasses the driver. (I'm not reverting the commit that introduced this but
please fix instead of keeping it this way.)
Reverting to fix the build failures and also so that the tests can be thought
out more thoroughly.
This reverts commit r194817.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194845 91177308-0d34-0410-b5e6-96231b3b80d8
This options accepts a path to a directory, collects the filenames of the files
it contains, and the migrator will only modify files with the same filename.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194710 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a new option -fprofile-sample-use=filename to Clang. It
tells the driver to schedule the SampleProfileLoader pass and passes
on the name of the profile file to use.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194567 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently with clang:
$ clang -O20 foo.c
error: invalid value '20' in '-O20'
With the patch:
$ clang -O20 foo.c
warning: invalid value '20' in '-O20'. Fall back on value '3'
Reviewers: rengolin, hfinkel
Reviewed By: rengolin
CC: cfe-commits, hfinkel, rengolin
Differential Revision: http://llvm-reviews.chandlerc.com/D2125
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194403 91177308-0d34-0410-b5e6-96231b3b80d8
NS_RETURNS_INNER_POINTER under -objcmt-returns-innerpointer-property
flag (off by default), as older compilers do not support such annotations.
// rdar://15396636
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194100 91177308-0d34-0410-b5e6-96231b3b80d8
deallocation function (and the corresponding unsized deallocation function has
been declared), emit a weak discardable definition of the function that
forwards to the corresponding unsized deallocation.
This allows a C++ standard library implementation to provide both a sized and
an unsized deallocation function, where the unsized one does not just call the
sized one, for instance by putting both in the same object file within an
archive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194055 91177308-0d34-0410-b5e6-96231b3b80d8
-fobjc-subscripting-legacy-runtime which is off
by default and on only when using ObjectiveC
legacy runtime. Use this flag to allow
array and dictionary subscripting and disallow
objectiveC pointer arithmatic in ObjectiveC
legacy runtime. // rdar://15363492
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193889 91177308-0d34-0410-b5e6-96231b3b80d8
Use -no-struct-path-tbaa to turn it off.
This is the same as r191695, which was reverted because it depends on a
commit that has issues.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192497 91177308-0d34-0410-b5e6-96231b3b80d8
-f{function,data}-sections had no tests at all, add some, and verify that the
-fno variants work as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192413 91177308-0d34-0410-b5e6-96231b3b80d8
instead, it's enabled by the -cc1 flag -fsized-deallocation, until we sort out
the backward-compatibility issues.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191629 91177308-0d34-0410-b5e6-96231b3b80d8
We want the modern behavior most of the time, so inverting the option simplifies
the driver and the tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191551 91177308-0d34-0410-b5e6-96231b3b80d8
With this option, arbitrarily named module map files can be specified
to be loaded as required for headers in the respective (sub)directories.
This, together with the extern module declaration allows for specifying
module maps in a modular fashion without the need for files called
"module.map".
Among other things, this allows a directory to contain two modules that
are completely independent of one another.
Review: http://llvm-reviews.chandlerc.com/D1697.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191284 91177308-0d34-0410-b5e6-96231b3b80d8
Review: http://llvm-reviews.chandlerc.com/D1546.
I have picked up this patch form Lawrence
(http://llvm-reviews.chandlerc.com/D1063) and did a few changes.
From the original change description (updated as appropriate):
This patch adds a check that ensures that modules only use modules they
have so declared. To this end, it adds a statement on intended module
use to the module.map grammar:
use module-id
A module can then only use headers from other modules if it 'uses' them.
This enforcement is off by default, but may be turned on with the new
option -fmodules-decluse.
When enforcing the module semantics, we also need to consider a source
file part of a module. This is achieved with a compiler option
-fmodule-name=<module-id>.
The compiler at present only applies restrictions to the module directly
being built.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191283 91177308-0d34-0410-b5e6-96231b3b80d8
This solves two problems:
1) MSBuild will not flag the build as unsuccessful just because we print
an error in the output, since "error(clang):" doesn't seem to match
the regex it's using.
2) It becomes more clear that the diagnostic is coming from clang as
supposed to cl.exe.
Differential Revision: http://llvm-reviews.chandlerc.com/D1735
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191250 91177308-0d34-0410-b5e6-96231b3b80d8
address spaces which is both (1) a "semantic" concept and
(2) possibly a hardware level restriction. It is desirable to
be able to discard/merge the LLVM-level address spaces on arguments for which
there is no difference to the current backend while keeping
track of the semantic address spaces in a funciton prototype. To do this
enable addition of the address space into the name-mangling process. Add
some tests to document this behaviour against inadvertent changes.
Patch by Michele Scandale!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190684 91177308-0d34-0410-b5e6-96231b3b80d8
Some build systems use pipes for stdin/stderr. On nix-ish platforms colored
output can be forced by -fcolor-diagnostics. On Windows this option has
no effect in these cases because LLVM uses the console API (which only
operates on the console buffer) even if a console wrapper capable of
interpreting ANSI escape codes is used.
The -fansi-escape-codes option allows switching from the console API to
ANSI escape codes. It has no effect on other platforms.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190464 91177308-0d34-0410-b5e6-96231b3b80d8
languages, as well as specifying errno is not set by the math functions. Make the
clang front-end set those appropriately when the OpenCL language option is set.
Patch by Erik Schnetter!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190296 91177308-0d34-0410-b5e6-96231b3b80d8
instance methods returning non-void. This will be quite noisy. So, it is
placed under a new migrator flag -objcmt-migrate-readonly-property.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189537 91177308-0d34-0410-b5e6-96231b3b80d8
The original idea was to implement it all on the driver, but to do that the
driver needs to know the sse level and to do that it has to know the default
features of a cpu.
Benjamin Kramer pointed out that if one day we decide to implement support for
' __attribute__ ((__target__ ("arch=core2")))', then the frontend needs to
keep its knowledge of default features of a cpu.
To avoid duplicating which part of clang handles default cpu features,
it is probably better to handle -mfpmath in the frontend.
For ARM this patch is just a small improvement. Instead of a cpu list, we
check if neon is enabled, which allows us to reject things like
-mcpu=cortex-a9 -mfpu=vfp -mfpmath=neon
For X86, since LLVM doesn't support an independent ssefp feature, we just
make sure the selected -mfpmath matches the sse level.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188939 91177308-0d34-0410-b5e6-96231b3b80d8
This once again restores notes to following their associated warnings
in -analyzer-output=text mode. (This is still only intended for use as a
debugging aid.)
One twist is that the warning locations in "regular" analysis output modes
(plist, multi-file-plist, html, and plist-html) are reported at a different
location on the command line than in the output file, since the command
line has no path context. This commit makes -analyzer-output=text behave
like a normal output format, which means that the *command line output
will be different* in -analyzer-text mode. Again, since -analyzer-text is
a debugging aid and lo-fi stand-in for a regular output mode, this change
makes sense.
Along the way, remove a few pieces of stale code related to the path
diagnostic consumers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188514 91177308-0d34-0410-b5e6-96231b3b80d8
'-fno-unroll-loops'. The option to the backend is even called
'DisableUnrollLoops'. This is precisely the form that Clang *didn't*
support. We didn't recognize the flag, we didn't pass it to the CC1
layer, and even if we did we wouldn't use it. Clang only inspected the
positive form of the flag, and only did so to enable loop unrolling when
the optimization level wasn't high enough. This only occurs for an
optimization level that even has a chance of running the loop unroller
when optimizing for size.
This commit wires up the 'no' variant, and switches the code to actually
follow the standard flag pattern of using the last flag and allowing
a flag in either direction to override the default.
I think this is still wrong. I don't know why we disable the loop
unroller entirely *from Clang* when optimizing for size, as the loop
unrolling pass *already has special logic* for the case where the
function is attributed as optimized for size! We should really be
trusting that. Maybe in a follow-up patch, I don't really want to change
behavior here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187969 91177308-0d34-0410-b5e6-96231b3b80d8
These flags set some preprocessor macros and injects a dependency
on the runtime library into the object file, which later is picked up
by the linker.
This also adds a new CC1 flag for adding a dependent library.
Differential Revision: http://llvm-reviews.chandlerc.com/D1315
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187945 91177308-0d34-0410-b5e6-96231b3b80d8
We already reject flags that don't have the CC1Option flag,
but we would previously do so after parsing the command-line
arguments.
Since the option parser now has a parameter for excluding options,
we should just use that instead.
Differential Revision: http://llvm-reviews.chandlerc.com/D1270
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187668 91177308-0d34-0410-b5e6-96231b3b80d8
These options will add a module flag with name "Dwarf Version".
The behavior flag is currently set to Warning, so when two values disagree,
a warning will be emitted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184276 91177308-0d34-0410-b5e6-96231b3b80d8
The big changes are:
- Deleting Driver/(Arg|Opt)*
- Rewriting includes to llvm/Option/ and re-sorting
- 'using namespace llvm::opt' in clang::driver
- Fixing the autoconf build by adding option everywhere
As discussed in the review, this change includes using directives in
header files. I'll make follow up changes to remove those in favor of
name specifiers.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D975
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183989 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, allow the flags that fall under this umbrella (i.e., -O3,
-ffast-math, and -fstrict-aliasing) to be overridden/disabled with the
individual -O[0|1|2|s|z]/-fno- flags.
This also fixes the handling of various floating point optimization
flags that are modified by -ffast-math (and thus -Ofast as well).
Part of rdar://13622687
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180204 91177308-0d34-0410-b5e6-96231b3b80d8
- There is no reason to have a modules specific flag for disabling
autolinking. Instead, convert the existing flag into -fno-autolink (which
should cover other autolinking code generation paths like #pragmas if and
when we support them).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179612 91177308-0d34-0410-b5e6-96231b3b80d8
This is a Darwin-SDK-specific hash criteria used to identify a
particular SDK without having to hash the contents of all of its
headers. If other platforms have such versioned files, we should add
those checks here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179346 91177308-0d34-0410-b5e6-96231b3b80d8
Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to
the actual type and 0, and are updated in EmitLValueForField.
Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar.
Added command line option -struct-path-tbaa.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178797 91177308-0d34-0410-b5e6-96231b3b80d8
support.
Caveat: Other than the existing segmented stacks support, no
claims are made of this working.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178744 91177308-0d34-0410-b5e6-96231b3b80d8
This option can be useful for end users who want to know why they
ended up with a ton of different variants of the "std" module in their
module cache. This problem should go away over time, as we reduce the
need for module variants, but it will never go away entirely.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178148 91177308-0d34-0410-b5e6-96231b3b80d8
emit function names in .gcda files by default, and the flag turns that off!
Rename the flag to make it match what it actually does. This keeps the default
format compatible with gcc 4.2.
Also add a test for this flag.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177475 91177308-0d34-0410-b5e6-96231b3b80d8
is enabled. Also add a new -test-coverage cc1 flag which makes testing coverage
possible and add our first clang-side coverage test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177470 91177308-0d34-0410-b5e6-96231b3b80d8
string to be emitted, and two properties about the files themselves.
Use $PWD to absolut-ify the path to the coverage file. Yes, this is what GCC
does. Reverts my own r175706.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176617 91177308-0d34-0410-b5e6-96231b3b80d8
and through to the debug info in the module. In order to make the
testcase a bit more efficient allow the filename to go through
compilation for compile and not assemble jobs and turn off the
extract for cases where we don't create an object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175935 91177308-0d34-0410-b5e6-96231b3b80d8
Add an ability to specify custom documentation block comment commands via a new
class CommentOptions. The intention is that this class will hold future
customizations for comment parsing, including defining documentation comments
with specific numbers of parameters, etc.
CommentOptions instance is a member of LangOptions.
CommentOptions is controlled by a new command-line parameter
-fcomment-block-commands=Foo,Bar,Baz.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175892 91177308-0d34-0410-b5e6-96231b3b80d8
to control the check for the C 5.2.4.1 / C++ [implimits] restriction on nesting
levels for parentheses, brackets and braces.
Some code with heavy macro use exceeds the default limit of 256, but we don't
want to increase it generally to avoid stack overflow on stack-constrained
systems.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175855 91177308-0d34-0410-b5e6-96231b3b80d8
We treat this as an alternative to -fvisibility=<?>
which changes the default value visibility to "hidden"
and the default type visibility to "default".
Expose a -cc1 option for changing the default type
visibility, repurposing -fvisibility as the default
value visibility option (also setting type visibility
from it in the absence of a specific option).
rdar://13079314
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175480 91177308-0d34-0410-b5e6-96231b3b80d8
The use of this flag enables a modules optimization where a given set
of macros can be labeled as "ignored" by the modules
system. Definitions of those macros will be completely ignored when
building the module hash and will be stripped when actually building
modules. The overall effect is that this flag can be used to
drastically reduce the number of
Eventually, we'll want modules to tell us what set of macros they
respond to (the "configuration macros"), and anything not in that set
will be excluded. However, that requires a lot of per-module
information that must be accurate, whereas this option can be used
more readily.
Fixes the rest of <rdar://problem/13165109>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174560 91177308-0d34-0410-b5e6-96231b3b80d8
since only one of them is allowed in command-line, process them separately.
Otherwise, if more than one is specified in the command-line, one is processed normally
and the others are going to be treated and included as header files.
Related to radar://13140508
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174385 91177308-0d34-0410-b5e6-96231b3b80d8
Redefine the shallow mode to inline all functions for which we have a
definite definition (ipa=inlining). However, only inline functions that
are up to 4 basic blocks large and cut the max exploded nodes generated
per top level function in half.
This makes shallow faster and allows us to keep inlining small
functions. For example, we would keep inlining wrapper functions and
constructors/destructors.
With the new shallow, it takes 104s to analyze sqlite3, whereas
the deep mode is 658s and previous shallow is 209s.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173958 91177308-0d34-0410-b5e6-96231b3b80d8
People use the C preprocessor for things other than C files. Some of them
have Unicode characters. We shouldn't warn about Unicode characters
appearing outside of identifiers in this case.
There's not currently a way for the preprocessor to tell if it's in -E mode,
so I added a new flag, derived from the PreprocessorOutputOptions. This is
only used by the Unicode warnings for now, but could conceivably be used by
other warnings or even behavioral differences later.
<rdar://problem/13107323>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173881 91177308-0d34-0410-b5e6-96231b3b80d8
- The only group where it makes sense for the "ExternC" bit is System, so this
simplifies having to have the extra isCXXAware (or ImplicitExternC, depending
on what code you talk to) bit caried around.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173859 91177308-0d34-0410-b5e6-96231b3b80d8
- This slightly decouples the path handling, since before the group sometimes
dominated the "use sysroot" bit, but it was still passed in via the API.
- No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173855 91177308-0d34-0410-b5e6-96231b3b80d8
implementation; this is much more inline with the original implementation
(i.e., pre-ubsan) and does not require run-time library support.
The trapping implementation can be invoked using either '-fcatch-undefined-behavior'
or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter
being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173848 91177308-0d34-0410-b5e6-96231b3b80d8
Eric Christopher