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
-fno-modules-global-index -cc1 option to allow one to disable the
index for performance testing purposes, but with a 10% win in
-fsyntax-only time, there is no reason a user would do this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173707 91177308-0d34-0410-b5e6-96231b3b80d8
"-fmodules-global-index" and expand its behavior to include both the
use and generation of the global module index.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173404 91177308-0d34-0410-b5e6-96231b3b80d8
The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173385 91177308-0d34-0410-b5e6-96231b3b80d8
The global module index is a "global" index for all of the module
files within a particular subdirectory in the module cache, which
keeps track of all of the "interesting" identifiers and selectors
known in each of the module files. One can perform a fast lookup in
the index to determine which module files will have more information
about entities with a particular name/selector. This information can
help eliminate redundant lookups into module files (a serious
performance problem) and help with creating auto-import/auto-include
Fix-Its.
The global module index is created or updated at the end of a
translation unit that has triggered a (re)build of a module by
scraping all of the .pcm files out of the module cache subdirectory,
so it catches everything. As with module rebuilds, we use the file
system's atomicity to synchronize.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173301 91177308-0d34-0410-b5e6-96231b3b80d8
operations (as opposed to storage only half/fp16).
Also add some semantic checks for OpenCL half types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173254 91177308-0d34-0410-b5e6-96231b3b80d8
Also, it was the only reason that `argc` and `argv` were being passed
into createDiagnostics, so remove those parameters and clean up callers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172945 91177308-0d34-0410-b5e6-96231b3b80d8
option. MS-style inline asm can now be enabled by either -fasm-blocks or
-fms-extensions.
rdar://12808010
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169445 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168063 91177308-0d34-0410-b5e6-96231b3b80d8
more sense anyway - it determines how expressions are codegen'd. It also ensures
that -ffp-contract=fast has the intended effect when compiling LLVM IR.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168027 91177308-0d34-0410-b5e6-96231b3b80d8
working with preprocessed testcases. This causes source locations in
diagnostics to point at the spelling location instead of the presumed location,
while still keeping the semantic effects of the line directives (entering and
leaving system-header mode, primarily).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168004 91177308-0d34-0410-b5e6-96231b3b80d8
generate expanded signature encoding to include types as we
already do this for protocol method lists.
// rdar://12109031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167997 91177308-0d34-0410-b5e6-96231b3b80d8
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167413 91177308-0d34-0410-b5e6-96231b3b80d8
-fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the
various UBSan checks to be enabled and disabled separately. Right now, the
different modes can't be combined, but the intention is that combining UBSan
and the other sanitizers will be permitted in the near future.
Currently, the UBSan checks will all be enabled if any of them is; that will be
fixed by the next patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167411 91177308-0d34-0410-b5e6-96231b3b80d8
header-search options into the module hash. We're just using
ADT/Hashing.hpp for this, which isn't as cryptographically strong as
I'd like, but it'll do. If someone contributes (say) and MD4
implementation, we'd happily switch to that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167397 91177308-0d34-0410-b5e6-96231b3b80d8
After every 1000 CFGElements processed, the ExplodedGraph trims out nodes
that satisfy a number of criteria for being "boring" (single predecessor,
single successor, and more). Rather than controlling this with a cc1 option,
which can only disable this behavior, we now have an analyzer-config option,
'graph-trim-interval', which can change this interval from 1000 to something
else. Setting the value to 0 disables reclamation.
The next commit relies on this behavior to actually test anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166528 91177308-0d34-0410-b5e6-96231b3b80d8
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166508 91177308-0d34-0410-b5e6-96231b3b80d8
implicitly-included PTH files during initialization, delaying the
mapping down to the "original source file" until after later in the
initialization process.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166452 91177308-0d34-0410-b5e6-96231b3b80d8
Each option has a set of prefixes. When matching an argument such as
-funroll-loops. First the leading - is removed as it is a prefix. Then
a lower_bound search for "funroll-loops" is done against the option table by
option name. From there each option prefix + option name combination is tested
against the argument.
This allows us to support Microsoft style options where both / and - are valid
prefixes. It also simplifies the cases we already have where options come in
both - and -- forms. Almost every option for gnu-ld happens to have this form.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166444 91177308-0d34-0410-b5e6-96231b3b80d8
are no known current users of column info. Robustify and fix up
a few tests in the process. Reduces the size of debug information
by a small amount.
Part of PR14106
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166236 91177308-0d34-0410-b5e6-96231b3b80d8
passing -fretain-comments-from-system-headers. By default, the
compiler no longer parses such documentation comments, as they
can result in a noticeable compile time/PCH slowdown.
Fixes <rdar://problem/11860820>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163778 91177308-0d34-0410-b5e6-96231b3b80d8
While destructors will continue to not be inlined (unless the analyzer
config option 'c++-inlining' is set to 'destructors'), leaving them out
of the CFG is an incomplete model of the behavior of an object, and
can cause false positive warnings (like PR13751, now working).
Destructors for temporaries are still not on by default, since
(a) we haven't actually checked this code to be sure it's fully correct
(in particular, we probably need to be very careful with regard to
lifetime-extension when a temporary is bound to a reference,
C++11 [class.temporary]p5), and
(b) ExprEngine doesn't actually do anything when it sees a temporary
destructor in the CFG -- not even invalidate the object region.
To enable temporary destructors, set the 'cfg-temporary-dtors' analyzer
config option to '1'. The old -cfg-add-implicit-dtors cc1 option, which
controlled all implicit destructors, has been removed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163264 91177308-0d34-0410-b5e6-96231b3b80d8
There are two tests regressions that come from the fact that the Retain
Count checker does not cancel out inlining of ObjC methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162950 91177308-0d34-0410-b5e6-96231b3b80d8
a comma separated collection of key:value pairs (which are strings). This
allows a general way to provide analyzer configuration data from the command line.
No clients yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162827 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen option to a LangOpt option. In turn, hoist the guard into the parser
so that we avoid the new (and fairly unstable) Sema/AST/CodeGen logic. This
should restore the behavior of clang to that prior to r158325.
<rdar://problem/12163681>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162602 91177308-0d34-0410-b5e6-96231b3b80d8
Under -analyzer-ipa=basic-inlining, only C functions, blocks, and C++ static
member functions are inlined -- essentially, the calls that behave like simple
C function calls. This is essentially the behavior in Xcode 4.4.
C++ support still has some rough edges, and we don't want users to be worried
about them if they download and run their own checker. (In particular, the
massive number of false positives for analyzing LLVM comes from inlining
defensively-written code in contexts where more aggressive assumptions are
implicitly made. This problem is not unique to C++, but it is exacerbated by
the higher proportion of code that lives in header files in C++.)
The eventual goal is to be comfortable enough with C++ support (and simple
Objective-C support) to advance to -analyzer-ipa=inlining as the default
behavior. See the IPA design notes for more details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162318 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostics for bad deployment targets and adding a few
more predicates. Includes a patch by Jonathan Schleifer
to enable ARC for ObjFW.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162252 91177308-0d34-0410-b5e6-96231b3b80d8
Add some tests for __OPTIMIZE_SIZE__ and __NO_INLINE__,
removing the superfluous copies in the target-specific
tests, since it's target-independent.
This uncovered a bug in the handling of -Oz: it would
attempt to store the value 2 in the 1-bit bitfield OptimizeSize,
leaving a value of 0 and never defining __OPTIMIZE_SIZE__.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161495 91177308-0d34-0410-b5e6-96231b3b80d8
This macro was being unconditionally set to zero, preceded by a FIXME comment.
This fixes <rdar://problem/11845441>. Patch by Michael Gottesman!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160491 91177308-0d34-0410-b5e6-96231b3b80d8
This flag sets the 'fp-contract' mode, which controls the formation of fused
floating point operations. Available modes are:
- Fast: Form fused operations anywhere.
- On: Form fused operations where allowed by FP_CONTRACT. This is the default
mode.
- Off: Don't form fused operations (in future this may be relaxed to forming
fused operations where it can be proved that the result won't be
affected).
Currently clang doesn't support the FP_CONTRACT pragma, so the 'On' and 'Off'
modes are equivalent.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159794 91177308-0d34-0410-b5e6-96231b3b80d8
attached to a declaration in the completion string.
Since extracting comments isn't free, a new code completion option is
introduced.
A new code completion option that enables including brief comments
into CodeCompletionString should be a, err, code completion option.
But because ASTUnit caches global declarations during parsing before
even completion consumer is created, the option is duplicated as a
translation unit option (in both libclang and ASTUnit, like the option
to cache code completion results).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159539 91177308-0d34-0410-b5e6-96231b3b80d8
comparison between two templated types when they both appear in a diagnostic.
Type elision will remove indentical template arguments, which can be disabled
with -fno-elide-type. Cyan highlighting is applied to the differing types.
For more formatting, -fdiagnostic-show-template-tree will output the template
type as an indented text tree, with differences appearing inline. Template
tree works with or without type elision.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159216 91177308-0d34-0410-b5e6-96231b3b80d8
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158793 91177308-0d34-0410-b5e6-96231b3b80d8
Add error checking for the static qualifier which is now allowed in certain situations for OpenCL 1.2. Use the CL version to turn on this feature.
Added test case for 1.2 static storage class feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158759 91177308-0d34-0410-b5e6-96231b3b80d8
option. On the driver, check if we are using libraries from gcc 4.7 or newer
and if so pass -fuse-init-array to the frontend.
The crtbegin*.o files in gcc 4.7 no longer call the constructors listed in
.ctors, so we have to use .init_array.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158694 91177308-0d34-0410-b5e6-96231b3b80d8
override whether headers are system headers by checking for prefixes of the
header name specified in the #include directive.
This allows warnings to be disabled for third-party code which is found in
specific subdirectories of include paths.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158418 91177308-0d34-0410-b5e6-96231b3b80d8
When enabled, clang generates bounds checks for array and pointers dereferences. Work to follow in LLVM's backend.
OK'ed by Chad; thanks for the review.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156431 91177308-0d34-0410-b5e6-96231b3b80d8
It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.
Reviewed by Eric Christopher.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156160 91177308-0d34-0410-b5e6-96231b3b80d8
First, this patch cleans up the parsing of the PIC and PIE family of
options in the driver. The existing logic failed to claim arguments all
over the place resulting in kludges that marked the options as unused.
Instead actually walk all of the arguments and claim them properly.
We now treat -f{,no-}{pic,PIC,pie,PIE} as a single set, accepting the
last one on the commandline. Previously there were lots of ordering bugs
that could creep in due to the nature of the parsing. Let me know if
folks would like weird things such as "-fPIE -fno-pic" to turn on PIE,
but disable full PIC. This doesn't make any sense to me, but we could in
theory support it.
Options that seem to have intentional "trump" status (-static, -mkernel,
etc) continue to do so and are commented as such.
Next, a -pie-level flag is threaded into the frontend, rigged to
a language option, and handled preprocessor, setting up the appropriate
defines. We'll now have the correct defines when compiling with -fpie.
The one place outside of the preprocessor that was inspecting the PIC
level (as opposed to the relocation model, which is set and handled
separately, yay!) is in the GNU ObjC runtime. I changed it to exactly
preserve existing behavior. If folks want to change its behavior in the
face of PIE, they can do that in a separate patch.
Essentially the only functionality changed here is the preprocessor
defines and bug-fixes to the argument management.
Tests have been updated and extended to test all of this a bit more
thoroughly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154291 91177308-0d34-0410-b5e6-96231b3b80d8
flag as GCC uses: -fstrict-enums). There is a *lot* of code making
unwarranted assumptions about the underlying type of enums, and it
doesn't seem entirely reasonable to eagerly break all of it.
Much more importantly, the current state of affairs is *very* good at
optimizing based upon this information, which causes failures that are
very distant from the actual enum. Before we push for enabling this by
default, I think we need to implement -fcatch-undefined-behavior support
for instrumenting and trapping whenever we store or load a value outside
of the range. That way we can track down the misbehaving code very
quickly.
I discussed this with Rafael, and currently the only important cases he
is aware of are the bool range-based optimizations which are staying
hard enabled. We've not seen any issue with those either, and they are
much more important for performance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153550 91177308-0d34-0410-b5e6-96231b3b80d8
The analyzer gives up path exploration under certain conditions. For
example, when the same basic block has been visited more than 4 times.
With inlining turned on, this could lead to decrease in code coverage.
Specifically, if we give up inside the inlined function, the rest of
parent's basic blocks will not get analyzed.
This commit introduces an option to enable re-run along the failed path,
in which we do not inline the last inlined call site. This is done by
enqueueing the node before the processing of the inlined call site
with a special policy encoded in the state. The policy tells us not to
inline the call site along the path.
This lead to ~10% increase in the number of paths analyzed. Even though
we expected a much greater coverage improvement.
The option is turned off by default for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153534 91177308-0d34-0410-b5e6-96231b3b80d8
list of identifiers that that 'public' names at the end of the
translation unit, e.g., defined macros or identifiers with top-level
names, in sorted order. Meant to support <rdar://problem/10921596>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153522 91177308-0d34-0410-b5e6-96231b3b80d8
Due to lack of move semantics we would create a temporary std::string from the
string literal, copy it into the vector and discard the temporary. This leads
to massive code bloat, optimizing it saves 50k on i386-linux-Release+Asserts.
While there add a two-element overload for push_back, simplifying code a bit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153441 91177308-0d34-0410-b5e6-96231b3b80d8
-fno-inline-functions.
This behaves much like -fno-inline in gcc, but based on a discussion with
Daniel it was decided that -fno-inline-functions should subsume -fno-inline.
Please speak up if you object. The -fno-inline flag remains ignored.
Final part of rdar://10972766
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152754 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, only diagnostics thrown by the cc1 process were
actually honoring the diagnostic options given on the command line,
like -Werror.
Reuse the existing code in Frontend currently used for cc1,
adjusting it to not interpret -Wl, linker flags as warnings.
Also fix a faulty test exposed by this change.
It wasn't actually testing anything, and was giving this warning:
clang-3: warning: argument unused during compilation: '-verify'
Which -Werror didn't turn into an error because it was output
by the driver, not the cc1 process, and diagnostic options
weren't parsed by the driver. And you couldn't see the warning
when running the test suite.
Fixes PR12181.
Patch by Dylan Noblesmith <nobled@dreamwidth.org>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152660 91177308-0d34-0410-b5e6-96231b3b80d8
We do not reanalyze a function, which has already been analyzed as an
inlined callee. As per PRELIMINARY testing, this gives over
50% run time reduction on some benchmarks without decreasing of the
number of bugs found.
Turning the mode on by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152440 91177308-0d34-0410-b5e6-96231b3b80d8
PR12196: The module hash strings are not actually hashing the compiler version
string; the entire version string is being included in the hash. Depending on
the module cache directory name, that can lead to failures where the path
names become too long. As a temporary workaround, just remove the version
string from the hash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152266 91177308-0d34-0410-b5e6-96231b3b80d8
the new Objective-C NSArray/NSDictionary/NSNumber literal syntax.
This introduces a new library, libEdit, which provides a new way to support
migration of code that improves on the original ARC migrator. We now believe
that most of its functionality can be refactored into the existing libraries,
and thus this new library may shortly disappear.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152141 91177308-0d34-0410-b5e6-96231b3b80d8
command line options for inlining tuning.
This adds the option for stack depth bound as well as function size
bound.
+ minor doxygenification
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151930 91177308-0d34-0410-b5e6-96231b3b80d8
This flag enables ThreadSanitizer instrumentation committed to llvm as r150423.
The patch includes one test for -fthread-sanitizer and one similar test for -faddress-sanitizer.
This patch does not modify the linker flags (as we do it for -faddress-sanitizer) because the run-time library is not yet
committed and it's structure in compiler-rt is not 100% clear.
The users manual wil be changed in a separate commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151846 91177308-0d34-0410-b5e6-96231b3b80d8
The class name is long enough without the llvm:: added.
Also bring in RefCountedBase and RefCountedBaseVPTR.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150958 91177308-0d34-0410-b5e6-96231b3b80d8
This option was added in r129614 and doesn't have any use case that I'm aware
of. It's possible that external tools are using these names - and if that's
the case we can certainly reassess the functionality, but for now it lets us
shave out a few unneeded bits from clang.
Move the "StaticDiagNameIndex" table into the only remaining consumer, diagtool.
This removes the actual diagnostic name strings from clang entirely.
Reviewed by Chris Lattner & Ted Kremenek.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150612 91177308-0d34-0410-b5e6-96231b3b80d8
want to provide "po"-like functionality which
treats the result of an expression implicitly as
"id" (if it is not otherwise known) and prints
it as an Objective-C object.
This has in the past been gated by the
"DebuggerSupport" language option, but that is
too general. Debuggers also provide other commands
like "print" that do not make any assumptions
about whether the object is an Objective-C object.
This patch makes the assumption conditional on a
new language option: DebuggerCastResultToId. I
have also made corresponding modifications to the
testsuite.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149735 91177308-0d34-0410-b5e6-96231b3b80d8
That llvm change removed the -trap-func backend option, so that using
-ftrap-function with clang would cause the backend to complain. Fix it
by adding the trap function name to the CodeGenOptions and passing it through
to the TargetOptions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149679 91177308-0d34-0410-b5e6-96231b3b80d8
like Darwin that don't support it. We should also complain about
invalid -fvisibility=protected, but that information doesn't seem
to exist at the most appropriate time, so I've left a FIXME behind.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149186 91177308-0d34-0410-b5e6-96231b3b80d8
leaves "finalize' behind and in arc mode, does not
include it. This allows the migrated source to be compiled
in both gc and arc mode. // rdar://10532441
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149079 91177308-0d34-0410-b5e6-96231b3b80d8
provide the layout of records, rather than letting Clang compute
the layout itself. LLDB provides the motivation for this feature:
because various layout-altering attributes (packed, aligned, etc.)
don't get reliably get placed into DWARF, the record layouts computed
by LLDB from the reconstructed records differ from the actual layouts,
and badness occurs. This interface lets the DWARF data drive layout,
so we don't need the attributes preserved to get the answer write.
The testing methodology for this change is fun. I've introduced a
variant of -fdump-record-layouts called -fdump-record-layouts-simple
that always has the simple C format and provides size/alignment/field
offsets. There is also a -cc1 option -foverride-record-layout=<file>
to take the output of -fdump-record-layouts-simple and parse it to
produce a set of overridden layouts, which is introduced into the AST
via a testing-only ExternalASTSource (called
LayoutOverrideSource). Each test contains a number of records to lay
out, which use various layout-changing attributes, and then dumps the
layouts. We then run the test again, using the preprocessor to
eliminate the layout-changing attributes entirely (which would give us
different layouts for the records), but supplying the
previously-computed record layouts. Finally, we diff the layouts
produced from the two runs to be sure that they are identical.
Note that this code makes the assumption that we don't *have* to
provide the offsets of bases or virtual bases to get the layout right,
because the alignment attributes don't affect it. I believe this
assumption holds, but if it does not, we can extend
LayoutOverrideSource to also provide base offset information.
Fixes the Clang side of <rdar://problem/10169539>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149055 91177308-0d34-0410-b5e6-96231b3b80d8
-fixit-recompile
applies fixits and recompiles the result
-fixit-to-temporary
applies fixits to temporary files
-fix-only-warnings">,
applies fixits for warnings only, not errors
Combining "-fixit-recompile -fixit-to-temporary" allows testing the result of fixits
without touching the original sources.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149027 91177308-0d34-0410-b5e6-96231b3b80d8
specific to migrator. Use its first option to
warn migrating from GC to arc when
NSAllocateCollectable/NSReallocateCollectable is used.
// rdar://10532541
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148887 91177308-0d34-0410-b5e6-96231b3b80d8
the front end into its own class, FrontendInputFile, to make it easier
to introduce new per-input data. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148546 91177308-0d34-0410-b5e6-96231b3b80d8
module imports from -fauto-module-import to -fmodules. The new name
will eventually be used to enable modules, and the #include/#import
mapping is a crucial part of the feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147447 91177308-0d34-0410-b5e6-96231b3b80d8
Clang driver. This involves a bunch of silly option parsing code to try
to carefully emulate GCC's options. Currently, this takes a conservative
approach, and unless all of the unsafe optimizations are enabled, none
of them are. The fine grained control doesn't seem particularly useful.
If it ever becomes useful, we can add that to LLVM first, and then
expose it here.
This also fixes a few tiny bugs in the flag management around
-fhonor-infinities and -fhonor-nans; the flags now form proper sets both
for enabling and disabling, with the last flag winning.
I've also implemented a moderately terrifying GCC feature where
a language change is also provided by the '-ffast-math' flag by defining
the __FAST_MATH__ preprocessor macro. This feature is tracked and
serialized in the frontend but it isn't used yet. A subsequent patch
will add the preprocessor macro and tests for it.
I've manually tested that codegen appears to respect this, but I've not
dug in enough to see if there is an easy way to test codegen options w/o
relying on the particulars of LLVM's optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147434 91177308-0d34-0410-b5e6-96231b3b80d8
Also drop -Wc1x-extensions in favor of -Wc11-extensions. I don't think we need to keep this around for compatibility.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147221 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the FIXMEs in ParseAnalyzeArgs. (Also a
precursor to moving the analyzer into an AST plugin.)
For consistency, do the same with AssemblerInvocation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147218 91177308-0d34-0410-b5e6-96231b3b80d8
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control the maximum number of notes so
produced (default 10). Fix APValue printing to be able to pretty-print all
APValue types, and move the testing for this functionality from a unittest to
a -verify test now that it's visible in clang's output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146749 91177308-0d34-0410-b5e6-96231b3b80d8
-ffinite-math-only.
- No test case yet, I don't know how to construct a situation where this
matters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146297 91177308-0d34-0410-b5e6-96231b3b80d8
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145444 91177308-0d34-0410-b5e6-96231b3b80d8
semantics and defaults as the corresponding g++ arguments. The historical g++
argument -ftemplate-depth-N is kept for compatibility, but modern g++ versions
no longer document that option.
Add -cc1 argument -fconstexpr-depth N to implement the corresponding
functionality.
The -ftemplate-depth=N part of this fixes PR9890.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145045 91177308-0d34-0410-b5e6-96231b3b80d8
a bug where the reference count is copied in the copy constructor, which means that there were cases when the CompilerInvocation
objects created by ASTUnit were actually leaked. When I fixed that bug locally, it showed that a whole bunch of code assumed
that the LangOptions object that was part of CompilerInvocation was still alive. By making it heap-allocated and reference counted,
we can keep it around after the CompilerInvocation object goes away.
As part of this change, change CompilerInvocation:getLangOptions() to return a pointer, acting as another clue that this
object may outlive the CompilerInvocation object.
This commit doesn't fix the CompilerInvocation leak itself. That will come when I commit the fix to llvm::RefCountedBase<T> to
mainline LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144930 91177308-0d34-0410-b5e6-96231b3b80d8
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143917 91177308-0d34-0410-b5e6-96231b3b80d8
actually manage the builtin header file includes as well as the system
ones.
This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.
Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.
Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143801 91177308-0d34-0410-b5e6-96231b3b80d8
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.
There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.
Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143798 91177308-0d34-0410-b5e6-96231b3b80d8
The motivation for this new DiagnosticConsumer is to provide a way for tools invoking the compiler
to get its diagnostics via a libclang interface, rather than textually parsing the compiler output.
This gives us flexibility to change the compiler's textual output, but have a structured data format
for clients to use to get the diagnostics via a stable API.
I have no tests for this, but llvm-bcanalyzer so far shows that the emitted file is well-formed.
More work to follow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143259 91177308-0d34-0410-b5e6-96231b3b80d8
r142300 but not this patch, clang -S may emit .s files that assemblers other
than llvm-mc can't parse.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142301 91177308-0d34-0410-b5e6-96231b3b80d8
as part of the hash rather than ignoring them. This means we'll end up
building more module variants (overall), but it allows configuration
macros such as NDEBUG to work so long as they're specified via command
line. More to come in this space.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142187 91177308-0d34-0410-b5e6-96231b3b80d8
This frontend-only flag is used by the IR generator to determine
whether to filter CUDA declarations for the host or for the device.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141301 91177308-0d34-0410-b5e6-96231b3b80d8
Rafael Espindola