This patch adds flags -fno-profile-instr-generate and
-fno-profile-instr-use, and the GCC aliases -fno-profile-generate and
-fno-profile-use.

These flags are used in situations where users need to disable profile
generation or use for specific files in a build, without affecting other
files.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244153 91177308-0d34-0410-b5e6-96231b3b80d8

(Because, hey, who wouldn't?)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243901 91177308-0d34-0410-b5e6-96231b3b80d8

This will be used for old targets like Android that do not
support ELF TLS models.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243441 91177308-0d34-0410-b5e6-96231b3b80d8

This patch adds support for specifying where the profile is emitted in a
way similar to GCC. These flags are used to specify directories instead
of filenames. When -fprofile-generate=DIR is used, the compiler will
generate code to write to <DIR>/default.profraw.

The patch also adds a couple of extensions: LLVM_PROFILE_FILE can still be
used to override the directory and file name to use and -fprofile-use
accepts both directories and filenames.

To simplify the set of flags used in the backend, all the flags get
canonicalized to -fprofile-instr-{generate,use} when passed to the
backend. The decision to use a default name for the profile is done
in the driver.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241825 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This is unfortunate, but would let us land http://reviews.llvm.org/D10467,
that makes ToolChains responsible for computing the set of sanitizers
they support.

Unfortunately, Darwin ToolChains doesn't know about actual OS they
target until ToolChain::TranslateArgs() is called. In particular, it
means we won't be able to construct SanitizerArgs for these ToolChains
before that.

This change removes SanitizerArgs::needsLTO() method, so that now
ToolChain::IsUsingLTO(), which is called very early, doesn't need
SanitizerArgs to implement this method.

Docs and test cases are updated accordingly. See
https://llvm.org/bugs/show_bug.cgi?id=23539, which describes why we
start all these.

Test Plan: regression test suite

Reviewers: pcc

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240170 91177308-0d34-0410-b5e6-96231b3b80d8

This causes programs compiled with this flag to print a diagnostic when
a control flow integrity check fails instead of aborting. Diagnostics are
printed using UBSan's runtime library.

The main motivation of this feature over -fsanitize=vptr is fidelity with
the -fsanitize=cfi implementation: the diagnostics are printed under exactly
the same conditions as those which would cause -fsanitize=cfi to abort the
program. This means that the same restrictions apply regarding compiling
all translation units with -fsanitize=cfi, cross-DSO virtual calls are
forbidden, etc.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240109 91177308-0d34-0410-b5e6-96231b3b80d8

This flag controls whether a given sanitizer traps upon detecting
an error. It currently only supports UBSan. The existing flag
-fsanitize-undefined-trap-on-error has been made an alias of
-fsanitize-trap=undefined.

This change also cleans up some awkward behavior around the combination
of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we
would reject command lines containing the combination of these two flags,
as -fsanitize=vptr is not compatible with trapping. This required the
creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr
(and -fsanitize=function, but this seems like an oversight).

Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap,
and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr
as an "unsupported" flag, which means that we error out if the flag is
specified explicitly, but implicitly disable it if the flag was implied
by -fsanitize=undefined.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240105 91177308-0d34-0410-b5e6-96231b3b80d8

Protection against stack-based memory corruption errors using SafeStack: Clang command line option and function attribute

This patch adds the -fsanitize=safe-stack command line argument for clang,
which enables the Safe Stack protection (see http://reviews.llvm.org/D6094
for the detailed description of the Safe Stack).

This patch is our implementation of the safe stack on top of Clang. The
patches make the following changes:

- Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang
  to control safe stack usage (the safe stack is disabled by default).

- Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be
  used to disable the safe stack for individual functions even when enabled
  globally.

Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239762 91177308-0d34-0410-b5e6-96231b3b80d8

This clarifies the relationship between instrumentation and sampling based PGO,
code coverage analysis and the different formats supported by sample
profiling.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238504 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238031 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237463 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236793 91177308-0d34-0410-b5e6-96231b3b80d8

NMake is a Make-like builder that comes with Microsoft Visual Studio.
Jom (https://wiki.qt.io/Jom) is an NMake-compatible build tool.
Dependency files for NMake/Jom need to use double-quotes to wrap
filespecs containing special characters, instead of the backslash
escapes that GNU Make wants.

Adds the -MV option, which specifies to use double-quotes as needed
instead of backslash escapes when writing the dependency file.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235903 91177308-0d34-0410-b5e6-96231b3b80d8

This uses the same class metadata currently used for virtual call and
cast checks.

The new flag is -fsanitize=cfi-nvcall. For consistency, the -fsanitize=cfi-vptr
flag has been renamed -fsanitize=cfi-vcall.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233874 91177308-0d34-0410-b5e6-96231b3b80d8

We are not able to make a reliable solution for using UBSan together
with other sanitizers with runtime support (and sanitizer_common).
Instead, we want to follow the path used for LSan: have a "standalone"
UBSan tool, and plug-in UBSan that would be explicitly embedded into
specific sanitizers (in short term, it will be only ASan).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232829 91177308-0d34-0410-b5e6-96231b3b80d8

This scheme checks that pointer and lvalue casts are made to an object of
the correct dynamic type; that is, the dynamic type of the object must be
a derived class of the pointee type of the cast. The checks are currently
only introduced where the class being casted to is a polymorphic class.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232241 91177308-0d34-0410-b5e6-96231b3b80d8

This is a recommit of r231150, reverted in r231409. Turns out
that -fsanitize=shift-base check implementation only works if the
shift exponent is valid, otherwise it contains undefined behavior
itself.

Make sure we check that exponent is valid before we proceed to
check the base. Make sure that we actually report invalid values
of base or exponent if -fsanitize=shift-base or
-fsanitize=shift-exponent is specified, respectively.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231711 91177308-0d34-0410-b5e6-96231b3b80d8

It's not that easy. If we're only checking -fsanitize=shift-base we
still need to verify that exponent has sane value, otherwise
UBSan-inserted checks for base will contain undefined behavior
themselves.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231409 91177308-0d34-0410-b5e6-96231b3b80d8

-fsanitize=shift is now a group that includes both these checks, so
exisiting users should not be affected.

This change introduces two new UBSan kinds that sanitize only left-hand
side and right-hand side of shift operation. In practice, invalid
exponent value (negative or too large) tends to cause more portability
problems, including inconsistencies between different compilers, crashes
and inadequeate results on non-x86 architectures etc. That is,
-fsanitize=shift-exponent failures should generally be addressed first.

As a bonus, this change simplifies CodeGen implementation for emitting left
shift (separate checks for base and exponent are now merged by the
existing generic logic in EmitCheck()), and LLVM IR for these checks
(the number of basic blocks is reduced).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231150 91177308-0d34-0410-b5e6-96231b3b80d8

Change -fsanitize-memory-track-origins to be equivalent to
-fsanitize-memory-track-origins=2.

Track-origins=2 provides a lot more detailed reports at the cost of
some additional slowdown (ranging from none to, sometimes, 3x; ~3% average on
SPEC2006).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230644 91177308-0d34-0410-b5e6-96231b3b80d8

This patch introduces the -fsanitize=cfi-vptr flag, which enables a control
flow integrity scheme that checks that virtual calls take place using a vptr of
the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst
file.

It also introduces the -fsanitize=cfi flag, which is currently a synonym for
-fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented
in Clang.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230055 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228814 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

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

The reasoning is that this construct is accepted by all compilers and valid in
C++11, so it doesn't seem like a useful warning to have enabled by default.
Building with -pedantic, -Wbind-to-temporary-copy, or -Wc++98-compat still
shows the warning.

The motivation is that I built re2, and this was the only warning that was
emitted during the build. Both changing re2 to fix the warning and detecting
clang and suppressing the warning in re2's build seem inferior than just giving
the compiler a good default for this warning.

Also move the cxx98compat version of this warning to CXX98CompatPedantic, and
update tests accordingly.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218008 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch implements a new UBSan check, which verifies
that function arguments declared to be nonnull with __attribute__((nonnull))
are actually nonnull in runtime.

To implement this check, we pass FunctionDecl to CodeGenFunction::EmitCallArgs
(where applicable) and if function declaration has nonnull attribute specified
for a certain formal parameter, we compare the corresponding RValue to null as
soon as it's calculated.

Test Plan: regression test suite

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits, rnk

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217389 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch adds a runtime check verifying that functions
annotated with "returns_nonnull" attribute do in fact return nonnull pointers.
It is based on suggestion by Jakub Jelinek:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223693.html.

Test Plan: regression test suite

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215485 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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214777 91177308-0d34-0410-b5e6-96231b3b80d8

This patch flips the default value for -gcolumn-info to be on by
default. I discussed the rationale and provided compile/size data
in:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/074290.html

This also updates the documentation and some tests that relied on
the lack of column information. Some tests had column information
in the expected output, but it was wrong (the tsan tests). Others
were using the driver to execute.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212781 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

<rdar://problem/16771671>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211085 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210958 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210938 91177308-0d34-0410-b5e6-96231b3b80d8

manual.

rdar://problem/17307006

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210936 91177308-0d34-0410-b5e6-96231b3b80d8

Init-order and use-after-return modes can currently be enabled
by runtime flags. use-after-scope mode is not really working at the
moment.

The only problem I see is that users won't be able to disable extra
instrumentation for init-order and use-after-scope by a top-level Clang flag.
But this instrumentation was implicitly enabled for quite a while and
we didn't hear from users hurt by it.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210924 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This adds documentation for -Rpass, -Rpass-missed and -Rpass-analysis.
It also adds release notes for 3.5.

Reviewers: rsmith

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209841 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206997 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206996 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206995 91177308-0d34-0410-b5e6-96231b3b80d8