If a parameter to a function is known non-null, use the existing parameter attributes to record that fact at the call site. This has no optimization benefit by itself - that I know of - but is an enabling change for http://reviews.llvm.org/D9129.

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

llvm-svn: 239795

Mark CodeGen/DIEValues.def as a textual inclusion to fix the
`LLVM_ENABLE_MODULES` build.

llvm-svn: 239794

Fix a build failure with `LLVM_ENABLE_MODULES` due to
`ProfileData::instr` conflicting with a function `instr()` in
`<curses.h>`.

llvm-svn: 239793

-fno-module-maps). The old names are preserved for compatibility.

llvm-svn: 239792

llvm-svn: 239791

This commit serializes the simple, scalar attributes from the 
'MachineFunction' class.

Reviewers: Duncan P. N. Exon Smith

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

llvm-svn: 239790

We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.

The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.

llvm-svn: 239789

This commit decouples the MIR printer and the MIR printing pass so
that it will be possible to move the MIR printer into a separate 
machine IR library later on.

Reviewers: Duncan P. N. Exon Smith
llvm-svn: 239788

These driver options never did anything (they weren't forwarded to the
frontend). Also update the documentation to not mention them.

llvm-svn: 239787

llvm-svn: 239786

Hopefully the last partial revert. Sorry about the noise.

llvm-svn: 239785

expanded in OpenMP pragmas. This patch adds support for that in -E.

llvm-svn: 239784

llvm-svn: 239783

Saves some typing and if someone wants to change them it makes it much easier.

llvm-svn: 239782

rdar://problem/20571359

llvm-svn: 239781

This is a prerequisite for turning on ODR type uniquing for ObjC++.

rdar://problem/21377883

llvm-svn: 239780

There are other characters we could optimize for (any non-letter pretty much), but keyword.iskeyword() will handle them, whereas quotes do have the potential to confuse us, so they actually need custom handling

Fixes rdar://problem/21022787

llvm-svn: 239779

This commit creates a dummy LLVM IR function with one basic block and an unreachable
instruction for each parsed machine function when the MIR file doesn't have LLVM IR.
This change is required as the machine function analysis pass creates machine
functions only for the functions that are defined in the current LLVM module.

Reviewers: Duncan P. N. Exon Smith

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

llvm-svn: 239778

rdar://21299888

llvm-svn: 239777

This commit reports an error when the MIR parser encounters a machine
function with the name that is the same as the name of a different
machine function.

Reviewers: Duncan P. N. Exon Smith

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

llvm-svn: 239774

llvm-svn: 239773

constants in commented-out part of LLVMAttribute enum. Add tests that verify
that the safestack attribute is only allowed as a function attribute.

llvm-svn: 239772

llvm-svn: 239771

llvm-svn: 239770

[Hexagon] PC-relative offsets are relative to packet start rather than the offset of the relocation.  Set relocation addend and check it's correct in the ELF.

llvm-svn: 239769

This reverts commit r239764 and the TestCases/Windows part of r239754.

llvm-svn: 239768

llvm-svn: 239767

Fix a bug where passing a value of the type "A B" to settings set target.env-vars would cause LLDB to crash

Fixes rdar://problem/21241817

llvm-svn: 239766

llvm-svn: 239765

llvm-svn: 239764

Protection against stack-based memory corruption errors using SafeStack: compiler-rt runtime support library

This patch adds runtime support for the Safe Stack protection to compiler-rt
(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 compiler-rt. The
patch adds basic runtime support for the safe stack to compiler-rt that
manages unsafe stack allocation/deallocation for each thread.

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/D6096

llvm-svn: 239763

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

llvm-svn: 239762

This patch adds the safe stack instrumentation pass to LLVM, which separates
the program stack into a safe stack, which stores return addresses, register
spills, and local variables that are statically verified to be accessed
in a safe way, and the unsafe stack, which stores everything else. Such
separation makes it much harder for an attacker to corrupt objects on the
safe stack, including function pointers stored in spilled registers and
return addresses. You can find more information about the safe stack, as
well as other parts of or control-flow hijack protection technique in our
OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf)
and our project website (http://levee.epfl.ch).

The overhead of our implementation of the safe stack is very close to zero
(0.01% on the Phoronix benchmarks). This is lower than the overhead of
stack cookies, which are supported by LLVM and are commonly used today,
yet the security guarantees of the safe stack are strictly stronger than
stack cookies. In some cases, the safe stack improves performance due to
better cache locality.

Our current implementation of the safe stack is stable and robust, we
used it to recompile multiple projects on Linux including Chromium, and
we also recompiled the entire FreeBSD user-space system and more than 100
packages. We ran unit tests on the FreeBSD system and many of the packages
and observed no errors caused by the safe stack. The safe stack is also fully
binary compatible with non-instrumented code and can be applied to parts of
a program selectively.

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

- Add the safestack function attribute, similar to the ssp, sspstrong and
  sspreq attributes.

- Add the SafeStack instrumentation pass that applies the safe stack to all
  functions that have the safestack attribute. This pass moves all unsafe local
  variables to the unsafe stack with a separate stack pointer, whereas all
  safe variables remain on the regular stack that is managed by LLVM as usual.

- Invoke the pass as the last stage before code generation (at the same time
  the existing cookie-based stack protector pass is invoked).

- Add unit tests for the safe stack.

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/D6094

llvm-svn: 239761

llvm-svn: 239760

llvm-svn: 239759

Switch to using BalancedDelimiterTracker to get better diagnostics for
unbalanced delimiters.  This still does not handle any of the attributes, simply
improves the parsing.

llvm-svn: 239758

llvm-svn: 239757

llvm-svn: 239756

LLVM does not and has not ever supported a soft-float ABI mode on
Sparc, so don't pretend that it does.

Also switch the default from "soft-float" -- which was actually
hard-float because soft-float is unimplemented -- to hard-float.

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

llvm-svn: 239755

Summary:
This commit adds symbolize_vs_style=false to every instance of
ASAN_OPTIONS in the asan tests and sets
ASAN_OPTIONS=symbolize_vs_style=false in lit, for tests which don't set
it.

This way we don't need to make the tests be able to deal with both
symbolize styles.

This is the first patch in the series. I will eventually submit for the
other sanitizers too.

We need this change (or another way to deal with the different outputs) in
order to be able to default to symbolize_vs_style=true on some platforms.

Adding to this change, I'm also adding "env " before any command line
which sets environment variables. That way the test works on other host
shells, like we have if the host is running Windows.

Reviewers: samsonov, kcc, rnk

Subscribers: tberghammer, llvm-commits

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

llvm-svn: 239754