llvm-svn: 190676

Summary:
Functions named "main", "wmain", "WinMain", "wWinMain", and "DllMain"
are never mangled regardless of linkage, even when compiling for kernel
mode.
Depends on D1655

Reviewers: timurrrr, pcc, rnk, whunt

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1670

llvm-svn: 190675

Before:
  enum {
    Bar = Foo < int,
    int > ::value
  };

After:
  enum {
    Bar = Foo<int, int>::value
  };

llvm-svn: 190674

Just a clean-up, no behavioral change intended.

llvm-svn: 190673

E.g. "SRL %r2, 2; TMLL %r2, 1" => "TMLL %r2, 4".

llvm-svn: 190672

Summary:
This is a first step to getting extern "C" working properly inside
clang.  There are a number of quirks but mangling declarations inside
such a function are a good first step.

Reviewers: timurrrr, pcc, cdavis5x

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1655

llvm-svn: 190671

llvm-svn: 190670

llvm-svn: 190669

disabled.

llvm-svn: 190668

[ASan] Temporary disable UAR unit test on Android due to https://code.google.com/p/address-sanitizer/issues/detail?id=222

llvm-svn: 190667

llvm-svn: 190666

Previously we modelled VPR128 and VPR64 as essentially identical
register-classes containing V0-V31 (which had Q0-Q31 as "sub_alias"
sub-registers). This model is starting to cause significant problems
for code generation, particularly writing EXTRACT/INSERT_SUBREG
patterns for converting between the two.

The change here switches to classifying VPR64 & VPR128 as
RegisterOperands, which are essentially aliases for RegisterClasses
with different parsing and printing behaviour. This fits almost
exactly with their real status (VPR128 == FPR128 printed strangely,
VPR64 == FPR64 printed strangely).

llvm-svn: 190665

[asan] more performance to FakeStack: a) don't used atomic exchange, instead rely on regular load and store and other signal-safe logic; b) remove allocated_from_size_class_mask_ which is not helping much anyway; Another 10% speedup

llvm-svn: 190664

llvm-svn: 190663

llvm-svn: 190662

llvm-svn: 190661

llvm-svn: 190660

llvm-svn: 190659

This handles multiple weak symbols which appear back to back. This fix is needed
which otherwise will lead to symbols getting initialized to arbitrary values.

There was a constructor/destructor test that really triggered this to be fixed
on X86_64.

Adds a test.

llvm-svn: 190658

later in the code so that the expressions will have addition processing first.
This catches a few additional cases of uninitialized uses of class fields.

llvm-svn: 190657

llvm-svn: 190656

that duplicated the name of the entity being documented at the start of its
comment, and other minor tidyups.

llvm-svn: 190655

single-quote and double-quotemarks from around file paths specified to
settings like target.expr-prefix or target.process.python-os-plugin-path.
<rdar://problem/14970457> 

llvm-svn: 190654

llvm-svn: 190653

Patch by Jared Grubb!

llvm-svn: 190652

Patch by Jared Grubb!

llvm-svn: 190651

No tests because no in-tree checkers use this, but that shouldn't stop
out-of-tree checkers.

Found by Aemon Cannon!

llvm-svn: 190650

versions of gold. This support is designed to allow gold to produce
gdb_index sections similar to the accelerator tables and consumable
by gdb.

llvm-svn: 190649

llvm-svn: 190648

llvm-svn: 190647

This restores the sqrt -> llvm.sqrt mapping, but only in fast-math mode
(specifically, when the UnsafeFPMath or NoNaNsFPMath CodeGen options are
enabled). The @llvm.sqrt* intrinsics have slightly different semantics from the
libm call, specifically, they are undefined when given a non-zero negative
number (the libm calls will always return NaN for any negative number).

This mapping was removed in r100613, and replaced with a TODO, but at that time
the fast-math flags were not yet implemented. Now that we have these, restoring
this mapping is important because it will enable autovectorization of sqrt
calls in loops (at least in fast-math mode).

llvm-svn: 190646

llvm-svn: 190645

llvm-svn: 190644

This move makes possible to correctly handle multiples instructions
from a single pattern.

llvm-svn: 190643

This would prevent system calls on Linux from being able to backtrace correctly.

llvm-svn: 190642

llvm-svn: 190641

llvm-svn: 190640

When a comma occurs in a default argument or default initializer within a
class, disambiguate whether it is part of the initializer or whether it ends
the initializer.

The way this works (which I will be proposing for standardization) is to treat
the comma as ending the default argument or default initializer if the
following token sequence matches the syntactic constraints of a
parameter-declaration-clause or init-declarator-list (respectively).

This is both consistent with the disambiguation rules elsewhere (where entities
are treated as declarations if they can be), and should have no regressions
over our old behavior. I think it might also disambiguate all cases correctly,
but I don't have a proof of that.

There is an annoyance here: because we're performing a tentative parse in a
situation where we may not have seen declarations of all relevant entities (if
the comma is part of the initializer, lookup may find entites declared later in
the class), we need to turn off typo-correction and diagnostics during the
tentative parse, and in the rare case that we decide the comma is part of the
initializer, we need to revert all token annotations we performed while
disambiguating.

Any diagnostics that occur outside of the immediate context of the tentative
parse (for instance, if we trigger the implicit instantiation of a class
template) are *not* suppressed, mirroring the usual rules for a SFINAE context.

llvm-svn: 190639

with prefer_file_cache == false.  This is what we want to do when
the user is doing a disassemble command -- show the actual memory
contents in case the memory has been corrupted or something -- but
when we're profiling functions for stepping or unwinding
(ThreadPlanStepRange::GetInstructionsForAddress,
UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read
__TEXT instructions directly out of the file, if it exists.
<rdar://problem/14397491> 

llvm-svn: 190638

llvm-svn: 190637