git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216834 91177308-0d34-0410-b5e6-96231b3b80d8

clang/test/CodeGenCXX/debug-info-access.cpp: Use %itanium_abi_triple to appease msvc. "[def] [free]" can be seen in different order.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216829 91177308-0d34-0410-b5e6-96231b3b80d8

Fix some cases where StringRef was being passed by const reference. Remove const from some other StringRefs since its implicitly const already.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216825 91177308-0d34-0410-b5e6-96231b3b80d8

Use llvm::makeArrayRef instead of explicitly calling ArrayRef constructor and mentioning the type. This works now that we have a conversion from ArrayRef<T*> to ArrayRef<const T*>.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216824 91177308-0d34-0410-b5e6-96231b3b80d8

This should make it easier to add more tests to this file.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216807 91177308-0d34-0410-b5e6-96231b3b80d8

[modules] Fix deserialization cycle when loading a tag declaration with a typedef name for linkage purposes. When loading the type, delay loading its typedef until we've finished loading and merging the type. In its place, save out the name of the typedef, which we need for merging purposes.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216806 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216802 91177308-0d34-0410-b5e6-96231b3b80d8

from the default for the containing type.

rdar://problem/18154959

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216800 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216796 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216791 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216786 91177308-0d34-0410-b5e6-96231b3b80d8

A couple of these arguments were passed by void* as a rather extreme
example of pimpling. Adjusting this to a more classic form of the idiom
(involving forward declarations) makes this more legible and allows
explicit passing of ownership via std::unique_ptr.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216785 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216783 91177308-0d34-0410-b5e6-96231b3b80d8

This avoids encoding information about the function prototype into the
thunk at the cost of some function prototype bitcast gymnastics.

Fixes PR20653.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216782 91177308-0d34-0410-b5e6-96231b3b80d8

Fix for PR20660, where unexpanded parameter pack in function parameter clause causes clang to crash.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216778 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216777 91177308-0d34-0410-b5e6-96231b3b80d8

in the super class, do not issue the warning about property
in current class's protocol will not be auto synthesized.
// rdar://18179833


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216769 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216767 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216765 91177308-0d34-0410-b5e6-96231b3b80d8

FoldingSet, another intrusive data structure that could use some
unique_ptr love on its interfaces. Eventually.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216764 91177308-0d34-0410-b5e6-96231b3b80d8

People have been incorrectly using "-analyzer-disable-checker" to
silence analyzer warnings on a file, when analyzing a project. Add
the "-analyzer-disable-all-checks" option, which would allow the
suppression and suggest it as part of the error message for
"-analyzer-disable-checker". The idea here is to compose this with
"--analyze" so that users can selectively opt out specific files from
static analysis.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216763 91177308-0d34-0410-b5e6-96231b3b80d8

I suspect llvm::ilist should take elements by unique_ptr, since it does
take ownership of the element (by stitching it into the linked list) -
one day.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216761 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216758 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216756 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216755 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216754 91177308-0d34-0410-b5e6-96231b3b80d8

Do not warn when property declared in class's protocol will be auto-synthesized
by its uper class implementation because super class has also declared this
property while this class has not. Continue to warn if current class
has declared the property also (because this declaration will not result
in a 2nd synthesis).
rdar://18152478


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216753 91177308-0d34-0410-b5e6-96231b3b80d8

Again, if shared ownership is the right model here (I assume it is,
given graph algorithms & such) this could be tidied up (the 'release'
call removed in favor of something safer) by having
IntrunsiveRefCntPointer constructible from a unique_ptr.

(& honestly I'd probably favor taking a page out of shared_ptr's book,
allowing implicit construction from a unique_ptr rvalue, and only allow
explicit from a raw pointer - currently IntrusiveRefCntPointer can
implicitly own from a raw pointer, which seems unsafe)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216752 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216751 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216749 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216743 91177308-0d34-0410-b5e6-96231b3b80d8

In theory, it'd be nice if we could move to a case where all buried
pointers were buried via unique_ptr to demonstrate that the program had
finished with the value (that we could really have cleanly deallocated
it) but instead chose to bury it.

I think the main reason that's not possible right now is the various
IntrusiveRefCntPtrs in the Frontend, sharing ownership for a variety of
compiler bits (see the various similar
"CompilerInstance::releaseAndLeak*" functions). I have yet to figure out
their correct ownership semantics - but perhaps, even if the
intrusiveness can be removed, the shared ownership may yet remain and
that would lead to a non-unique burying as is there today. (though we
could model that a little better - by passing in a shared_ptr, etc -
rather than needing the two step that's currently used in those other
releaseAndLeak* functions)

This might be a bit more robust if BuryPointer took the boolean:

BuryPointer(bool, unique_ptr<T>)

and the choice to bury was made internally - that way, even when
DisableFree was not set, the unique_ptr would still be null in the
caller and there'd be no chance of accidentally having a different
codepath where the value is used after burial in !DisableFree, but it
becomes null only in DisableFree, etc...

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216742 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216740 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  decltype(* ::std::declval<const T &>()) void F();

After:
  decltype(*::std::declval<const T &>()) void F();

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216724 91177308-0d34-0410-b5e6-96231b3b80d8

But don't move if all we do is clearing the thing. The move method is too large
to be inlined and performs a ton of unnecessary checking when the RHS is empty.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216723 91177308-0d34-0410-b5e6-96231b3b80d8

Previously, EnterStructPointerForCoercedAccess used Alloc size when determining how to convert. This was problematic, because there were situations were the alloc size was larger than the store size. For example, if the first element of a structure were i24 and the destination type were i32, the old code would generate a GEP and a load i24. The code should compare store sizes to ensure the whole object is loaded. I have attached a test case.

This patch modifies the output of arm64-be-bitfield.c test case, but the new IR seems to be equivalent, and after -O3, the compiler generates identical ARM assembly. (asr x0, x0, #54)

Patch by Thomas Jablin!



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216722 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216715 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
We did a great job getting this wrong:
- We messed up which LLVM IR types to use for arguments and return values.
  The optimized libcalls use integer types for values.

  Clang attempted to use the IR type which corresponds to the value
  passed in instead of using an appropriately sized integer type.  This
  would result in violations of the ABI for, as an example, floating
  point types.
- We didn't bother recording the result of the atomic libcall in the
  destination memory.

Instead, call the functions with arguments matching the type of the
libcall prototype's parameters.

This fixes PR20780.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216714 91177308-0d34-0410-b5e6-96231b3b80d8

It hits a limit when we reach ActionList, which is used for dynamic
conditional ownership, so we lose type safety there.

This did expose at least one caller "lying" about ownership (passing
ownership to an Action, then updating the Action to specify that it
doesn't actually own the thing that was passed) - changing this to
unique_ptr just makes that oddity more obvious.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216713 91177308-0d34-0410-b5e6-96231b3b80d8

Rather than having a pair of pairs and a reference out parameter, build
a structure with everything together and named. A raw pointer and a
unique_ptr, rather than a raw pointer and a boolean, are used to
communicate ownership transfer.

It's possible one day we'll end up with a conditional pointer (probably
represented by a raw pointer and a boolean) abstraction to use in places
like this. Conditional ownership seems to be coming up more often than
I'd hoped...

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216712 91177308-0d34-0410-b5e6-96231b3b80d8