llvm-svn: 185292

This allows clang to use the backend parameter attribute 'returned' when generating 'this'-returning constructors and destructors in ARM and MSVC C++ ABIs.

llvm-svn: 185291

DeadArgumentElimination: keep return value on functions that have a live argument with the 'returned' attribute (rather than generate invalid IR); however, if both can be eliminated, both will be

llvm-svn: 185290

Fix bind by making _is_valid_bind_return more robust.  It should return false instead of give a compile time error, always.  The problem was down in ____mu_return, the version that handles nested bind objects.  This fixes http://llvm.org/bugs/show_bug.cgi?id=16343

llvm-svn: 185289

typo or two.

llvm-svn: 185288

Always set -m32/-m64 flags for targeting i386/x86_64 respectively. Apparently, there are platforms where the clang defaults are different from gcc

llvm-svn: 185287

llvm-svn: 185286

llvm-svn: 185285

ConstantFold: Check that truncating the other side is safe under a sext when trying to remove a sext from a compare.

Fixes PR16462.

llvm-svn: 185284

llvm-svn: 185283

before the value computation of the result. In C, this is implied by there being
a sequence point after their evaluation, and in C++, it's implied by the
side-effects being sequenced before the expressions and statements in the
function body.

llvm-svn: 185282

standard's rule that an extern "C" declaration conflicts with any entity in the
global scope with the same name. Now we only care if the global scope entity is
a variable declaration (and so might have the same mangled name as the extern
"C" declaration). This has been reported as a standard defect.

Original commit message:

PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.

When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.

When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).

llvm-svn: 185281

llvm-svn: 185280

WalkUpFromLambdaExpr, so that the Visit* functions are called
on that AST node.

llvm-svn: 185277

explicitly specify use of C++98 or C++11. Lang_CXX is preserved as
an alias for Lang_CXX98.

This does not add Lang_CXX1Y or Lang_C11, on the assumption that it's
better to add them if/when they are needed.

(This is a prerequisite for a test in a later patch for RecursiveASTVisitor.)

Reviewed by Richard Smith.

llvm-svn: 185276

code to specify what version of POSIX the system should provide.  If
you want to check what version of POSIX is actually available, you're
supposed to test _POSIX_VERSION.

However, since sysconf() has been in POSIX since 1995, it's probably
safe to assume it's available on any system with a C++11 compiler,
especially if _SC_NPROCESSORS_ONLN is defined too.  So no point in a
complicated preprocessor rule if just we unconditionally include
<unistd.h> (on non-Windows systems).

Also, I've added a #warning for to help porters detect when a suitable
implementation isn't detected at compile-time.

Howard:  Matthew, can you patch CREDITS.TXT?  Thanks.
llvm-svn: 185275

Matthew Dempsky: Same as stdexcept.cpp in libc++abi: we've already computed 'len strlen(msg)', so we can use memcpy() instead of strcpy().

llvm-svn: 185274

Prevent '\b' from backing up into invalid memory.  Fixes http://llvm.org/bugs/show_bug.cgi?id=16240.  Sorry, I can not think of a good test case for this one, except by running valgrind as reported in the bug.

llvm-svn: 185273

This allows us to simplify urem instructions involving the add+xor to
turn into simpler math.

llvm-svn: 185272

Avoids unused variable warnings in release builds.

llvm-svn: 185271

Inserting a zext or trunc is sufficient. This pattern is somewhat common in
LLVM's pointer mangling code.

llvm-svn: 185270

operator++ on an enum is not legal. clang happens to accept it anyways, I think
that's a known bug.

llvm-svn: 185269

llvm-svn: 185268

llvm-svn: 185267

llvm-svn: 185266

Add operators to make launch a bitmask type.  Searched all of the standard, and libc++ to see if this error occurred elsewhere and didn't see any other place.  This fixes http://llvm.org/bugs/show_bug.cgi?id=16207

llvm-svn: 185265

llvm-svn: 185264

llvm-svn: 185263

llvm-svn: 185262

No functionality change.

llvm-svn: 185261

Orignally, we first test if a ValueMap contains a Value, and than use the
index operator to get the corresponding new value. This requires the ValueMap
to lookup the key (i.e. the old value) twice.

Now, we directly use the "lookup" function provided by DenseMap to implement
the same functionality.

llvm-svn: 185260

Changing the sign when comparing the base pointer would introduce all
sorts of unexpected things like:
  %gep.i = getelementptr inbounds [1 x i8]* %a, i32 0, i32 0
  %gep2.i = getelementptr inbounds [1 x i8]* %b, i32 0, i32 0
  %cmp.i = icmp ult i8* %gep.i, %gep2.i
  %cmp.i1 = icmp ult [1 x i8]* %a, %b
  %cmp = icmp ne i1 %cmp.i, %cmp.i1
  ret i1 %cmp

into:
  %cmp.i = icmp slt [1 x i8]* %a, %b
  %cmp.i1 = icmp ult [1 x i8]* %a, %b
  %cmp = xor i1 %cmp.i, %cmp.i1
  ret i1 %cmp

By preserving the original sign, we now get:
  ret i1 false

This fixes PR16483.

llvm-svn: 185259

llvm-svn: 185258

Real world code sometimes has the denominator of a 'udiv' be a
'select'.  LLVM can handle such cases but only when the 'select'
operands are symmetric in structure (both select operands are a constant
power of two or a left shift, etc.).  This falls apart if we are dealt a
'udiv' where the code is not symetric or if the select operands lead us
to more select instructions.

Instead, we should treat the LHS and each select operand as a distinct
divide operation and try to optimize them independently.  If we can
to simplify each operation, then we can replace the 'udiv' with, say, a
'lshr' that has a new select with a bunch of new operands for the
select.

llvm-svn: 185257

llvm-svn: 185256

The attribute in the file allows git to perform End-of-Line
normalization (CRLF to LF).

llvm-svn: 185255

llvm-svn: 185254

1. Do not allow creating new memory access record in the InstructionToAccess map
   on the fly in function getAccessFor.
2. Do not allow user to modify the memory accesses returned by getAccessFor
   during the code generation process.

llvm-svn: 185253

llvm-svn: 185252

llvm-svn: 185251