Also shuffle the atoms so that it can verify the layout pass
actually changed the layout.

llvm-svn: 181573

But ShuffleVectorExpr should be tail-allocating the storage for expressions.

llvm-svn: 181572

llvm-svn: 181571

Now tests should pass.  The previous error was caused by a misplaced backing
array for MutableArrayRef that I introduced.

llvm-svn: 181570

llvm-svn: 181569

llvm-svn: 181568

starting a kdp communication session, instead of assuming darwin
kernel for any "non-EFI" kdp session.
<rdar://problem/13854098>

llvm-svn: 181566

llvm-svn: 181565

rdar://13854369 and PR15944

llvm-svn: 181564

llvm-svn: 181563

llvm-svn: 181562

for C++ constructors.

If the DIType for a class was generated by
CGDebugInfo::createContextChain(), the cache contains only a
limited DIType wihtout any declarations. Since EmitFunctionStart()
needs to find the canonical declaration for each method, we
construct the complete type before emitting any method.

rdar://problem/13116508

llvm-svn: 181561

into a CXXRecordDecl on the ground; rather, put
them into the translation unit as functions.

<rdar://problem/13834404>

llvm-svn: 181560

llvm-svn: 181559

llvm-svn: 181558

This fixes several (7 out of 16) cases of PR14492 in the GDB 7.5 test
suite. It seems GDB was bailing out whenever it had even the slightest
problem with the template argument list (& I assume it didn't like
seeing template value parameters that were just simple names - perhaps
assuming that lone names must be types, not values)

llvm-svn: 181556

Teach SelectionDAG to constant fold all-constant FMA nodes the same way that it constant folds FADD, FMUL, etc.

llvm-svn: 181555

llvm-svn: 181554

llvm-svn: 181553

Both these tests were ultimately fixed by the check for
"isIncompleteType" & neither test case was really reduced to a minimal
form. On doing so it becomes apparent that the problem wasn't specific
to templates at all, so I've moved the test case to a more appropriate
test file and added FileCheck verification to it (to show the forward
declaration of the array element type as well as the array alignment and
size being 0 since it cannot be computed). That's about as far down this
rabbithole as I'm willing to go today, so the rest of the un-FileChecked
tests in test/CodeGenCXX/debug-info.cpp will have to go another day
without actually testing anything other than the fact that they don't
crash.

& improve the actually interesting test case in
test/CodeGenCXX/debug-info-templates.cpp which was my original goal (in
preparation for expanding it/fixing some related bugs in non-type
template parameters)

llvm-svn: 181552

llvm-svn: 181551

llvm-svn: 181550

llvm-svn: 181549

llvm-svn: 181548

llvm-svn: 181547

llvm-svn: 181546

BitstreamWriter asserts that when blob data is written from the record
element vector, each element fits in a byte. However, if the record
elements are specified as a SmallVector of 'char', this causes a warning
from -Wtautological-constant-out-of-range-compare. Fix this by using
llvm::isUInt<8> instead of a plain comparison against 256.

llvm-svn: 181545

Patch by Robert Wilhelm.

llvm-svn: 181544

Summary:
This only supports converting along non-virtual inheritance paths by
changing the field offset or the non-virtual base adjustment.

This implements three kinds of conversions:
- codegen for Value conversions
- Constant emission for APValue
- Constant folding for CastExprs

In almost all constant initialization settings
EmitMemberPointer(APValue) is called, except when the expression
contains a reinterpret cast.

reinterpret casts end up being a big corner case because the null value
changes between different kinds of member pointers.

Reviewers: rsmith

CC: cfe-commits

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

llvm-svn: 181543

This was added, untested (though the relevant crash was tested), in
r128725/PR9600. Removing it doesn't cause failures & nothing I can
imagine could cause this check to ever return 'true' (we should never be
dealing with dependent types here). The subsequent change to check
"isIncompleteType" (r128855/PR9608) makes a lot more sense.

llvm-svn: 181542

The return type of the destructor may vary between platforms, so stop
inadvertently testing it.

llvm-svn: 181541

We generate a `push' of a random register (%rax) if the stack needs to be
aligned by the size of that register. However, this could mess up compact unwind
generation. In particular, we want to still generate compact unwind in the
presence of this monstrosity.

Check if the push of of the %rax/%eax register. If it is and it's marked with
the `FrameSetup' flag, then we can generate a compact unwind encoding for the
function only if the push is the last FrameSetup instruction.

llvm-svn: 181540

For loops using pseudo-arrays, classes that can be used like arrays from
the Loop Convert Transform's point of view, should only get transformed
if the pseudo-array class has begin()/end() members for the
range-based for-loop to call.

Free versions of begin()/end() should also be allowed but this is an
enhancement for another revision.

llvm-svn: 181539

- Eliminated the use of static for methods that read m_register_infos, so that these routines can be implemented in the base class.
- Eliminated m_register_infos in the base class because this is not used when derived classes call UpdateRegisterInfo.
- Also moved the namespace using declarations from headers to source files.

Thanks to Daniel and Samuel for their review feedback.

llvm-svn: 181538

Recursive commands invocations are not currently supported by our CommandInterpreter
CommandScriptImport can actually be made to invoke itself recursively, so we need to work around that by clearing the m_exe_ctx
This is a short-term workaround, a more interesting solution would be to actually make sure recursive command invocations work properly

llvm-svn: 181537

EmitCapturedStmt creates a captured struct containing all of the captured
variables, and then emits a call to the outlined function.  This is similar in
principle to EmitBlockLiteral.

GenerateCapturedFunction actually produces the outlined function.  It is based
on GenerateBlockFunction, but is much simpler.  The function type is determined
by the parameters that are in the CapturedDecl.

Some changes have been added to this patch that were reviewed as part of the
serialization patch and moving the parameters to the captured decl.

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

llvm-svn: 181536

No functionality change.

llvm-svn: 181535

llvm-svn: 181534

Switch C++1y paper links back to the canonical location at open-std.org now that the post-Bristol mailing has shipped.

llvm-svn: 181533

  iteration.
  
  This on step toward non-iterative GVN. My local hack suggests that getting rid
of iteration will speedup GVN by 30%+ on a medium sized input (2k LOC, C++).
I cannot explain why not 2x or more at this moment.

llvm-svn: 181532