llvm-svn: 198689

encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.

llvm-svn: 198686

I have no idea why Clang's warning doesn't fire here, looks like a Clang
bug. I'll investigate that separately.

llvm-svn: 198677

llvm-svn: 198672

llvm-svn: 198670

It controls everything that -flimit-debug-info used to, plus the
vtable type optimization. The old -fno-limit-debug-info option is now an
alias to -fstandalone-debug and vice versa.

Standalone is the default on Darwin until dtrace is updated to work with
non-standalone debug info (rdar://problem/15758808).

Note: I kept the LimitedDebugInfo name in CodeGenOptions::DebugInfoKind
because NoStandaloneDebugInfo sounded even more confusing.

llvm-svn: 198655

llvm-svn: 198649

llvm-svn: 198645

llvm-svn: 198640

Summary:
This makes us more compatible with MSVC 2012+ and fixes PR17748 where we
would give two tables the same name.

Rather than doing a fresh depth-first traversal of the inheritance graph
for every record's vbtables, now we memoize vbtable paths for each
record.  By doing memoization, we end up considering virtual bases of
subobjects that come later in the depth-first traversal.  Where
previously we would have ignored a virtual base that we'd already seen,
we now consider it for name mangling purposes without emitting a
duplicate vbtable for it.

Reviewers: majnemer

CC: cfe-commits

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

llvm-svn: 198462

the lexical block formed by the compound statement that is the function
body.

rdar://problem/15010825

llvm-svn: 198461

llvm-svn: 198382

Summary:
No functionality change.

This code should live here long-term because we should be able to use it
to compute correct vftable names.

It turns out that the most natural way to implement the naming algorithm
is to use a caching layer similar to what we already have for virtual
table info in VTableContext.  Subsequent changes will take advantage of
this to fix PR17748, where we have a vbtable name collision.

Reviewers: majnemer

CC: cfe-commits

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

llvm-svn: 198380

The backend string is only verified when available as it's possible to run
clang IRGen for targets that haven't been built or don't exist in LLVM.

llvm-svn: 198309

Remove UnaryTypeTraitExpr and switch all remaining type trait related handling
over to TypeTraitExpr.

The UTT/BTT/TT enum prefix and evaluation code is retained pending further
cleanup.

This is part of the ongoing work to unify type traits following the removal of
BinaryTypeTraitExpr in r197273.

llvm-svn: 198271

This better describes what the function does.

Cleanup only.

llvm-svn: 198127

'create' functions conventionally return a pointer, not a reference.

Also use an OwningPtr to get replace the delete of a reference member.

No functional change.

llvm-svn: 198126

Summary:
This is an alternative to http://llvm-reviews.chandlerc.com/D2475
suggested by Chandler.

Reviewers: chandlerc, rnk, dblaikie

CC: cfe-commits, earthdok

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

llvm-svn: 198073

llvm-svn: 197916

[AArch64]The compare to zero intrinsics should be implemented by 'icmp/fcmp' and 'sext' not 'zext'. Modify the implementation by replacing zext with sext.

llvm-svn: 197898

DiagIDs are a cached resource generally only constructed from compile-time
constant or stable format strings.

Escaping arbitrary messages and constructing DiagIDs from them didn't make
sense.

llvm-svn: 197856

Now CodeGenVTables has only one VTableContext object, which is either
Itanium or Microsoft.

Fixes a FIXME with no functionality change intended.

Ideally we could avoid the downcasts by pushing the things that
reference the Itanium vtable context into ItaniumCXXABI.cpp, but we're
not there yet.

llvm-svn: 197845

DebugInfo: Do not include implicit members (implicit special members, template instantiations, etc) in the list of members of a structure.

These members will still be lazily added to the relevant DWARF DIEs in
LLVM but when enumerating the members they will not appear. This allows
DWARF type units to be more consistent - the type unit will never
contain these special members (so all instances of the type should have
the same DIEs without some having some special members and others having
others) and the special members will be added to the skeletal
declaration that appears in the relevant compile_unit.

llvm-svn: 197844

This matches llc's behavior.

Before this patch clang would create a TargetInfo base on -triple but a llvm
CodeGen based on the triple in the module.

llvm-svn: 197837

Cleanup in preparation for enhanced DataLayout checking.

llvm-svn: 197832

Hosting a call to getAttr so that we don't call it multiple times for the same attribute. Also removes a hasAttr that's not required. No functional changes intended.

llvm-svn: 197675

Switched code from using hasAttr followed by getAttr to simply call getAttr directly and check the resulting value.

No functional changes intended.

llvm-svn: 197652

Switched code from using hasAttr followed by getAttr to simply call getAttr directly and check the resulting value.

No functional changes intended.

llvm-svn: 197650

Replacing calls to getAttr with calls to hasAttr for clarity. No functional change intended -- this only replaces Boolean uses of getAttr.

llvm-svn: 197648

rdar://problem/15678916.

llvm-svn: 197641

member functions. Paired commit with LLVM.

rdar://problem/15356637

llvm-svn: 197612

I am about to send a patch for review touching these and clang-formating first
makes the patch much easier to read.

llvm-svn: 197585

Implement the MSABI and SysVABI calling conventions for Objective-C method declarations. This appears to be an omission from r189644.

llvm-svn: 197584

llvm-svn: 197544

Unlike Itanium's VTTs, the 'most derived' boolean or bitfield is the
last parameter for non-variadic constructors, rather than the second.
For variadic constructors, the 'most derived' parameter comes after the
'this' parameter.  This affects constructor calls and constructor decls
in a variety of places.

Reviewers: timurrrr

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

llvm-svn: 197518

Tidy up built-in record creation to reduce code duplication.

Continuation of r197336.

llvm-svn: 197452

llvm-svn: 197406

so use the same exception size as GNUEABI does.

llvm-svn: 197404

clang still doesn't emit the right llvm code when initializing multi-D arrays it seems.

For e.g. the following code would still crash for me on Windows 7, 64 bit:

auto f4 = new int[100][200][300]{{{1,2,3}, {4, 5, 6}}, {{10, 20, 30}}};

It seems that the final new loop that iterates through each outermost array and memsets it to zero gets confused with its final ptr arithmetic.

This patch ensures that it converts the pointer to the allocated type (int [200][300]) before incrementing it (instead of using the base type: 'int').

Richard somewhat squeamishly approved the patch (as a quick fix to potentially make it into 3.4) - while exhorting for a more optimized fix in the future. http://llvm-reviews.chandlerc.com/D2398
 
Thanks Richard!

llvm-svn: 197294

There's nothing special about type traits accepting two arguments.

This commit eliminates BinaryTypeTraitExpr and switches all related handling
over to TypeTraitExpr.

Also fixes a CodeGen failure with variadic type traits appearing in a
non-constant expression.

The BTT/TT prefix and evaluation code is retained as-is for now but will soon
be further cleaned up.

This is part of the ongoing work to unify type traits.

llvm-svn: 197273