llvm-svn: 260258

llvm-svn: 260257

llvm-svn: 260256

llvm-svn: 260255

It isn't much benefit and doesn't worth the complexity to try to handle them after the container is encountered.

llvm-svn: 260254

[libclang] indexing: for a synthesized property reference have the parent be the ObjC implementation decl.

llvm-svn: 260253

llvm-svn: 260252

[ASTUnit] Change the parameter of ASTUnit::LoadFromCompilerInvocationAction to accept a more general FrontendAction.

llvm-svn: 260251

[libclang] indexing: Have the semantic container of synthesized ObjC getter/setter methods be the implementation decl.

Matches the behavior of other ObjC methods.

llvm-svn: 260250

llvm-svn: 260249

ld64 aligns most of the stub's to 2 byte alignment, expect for
the stub helper common atoms which are 4 byte aligned.

This adds a new field to StubInfo which tracks this alignment
and ensures that this is the alignment we get in the final image.

rdar://problem/24570220

llvm-svn: 260248

llvm-svn: 260247

While this won't help fix things like the bug that r260219 addressed, it
seems like good tidy up to have anyway.

(it might be nice if "makeArrayRef" always produced a MutableArrayRef &
let it decay to an ArrayRef when needed - then I'd use that for the
MutableArrayRefs in this patch)

If we had std::dynarray I'd use that instead of unique_ptr+size_t,
ideally (but then it'd have to be threaded down through the Preprocessor
all the way - no idea how painful that would be)

llvm-svn: 260246

[llvm-readobj][ELF] Show MIPS GOT content when there is another zero-sized section at the same address

It is possible to have .got section and one or more zero-sized section
at the same address. This patch first checks that GOT (or GOT PLT)
section should have non-zero size using corresponding dynamic tags. Then
it looks up not empty section at the specified address.

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

llvm-svn: 260245

FunctionAttrs does an "optimistic" analysis of SCCs as a unit, which
means normally it is able to disregard calls from an SCC into itself.
However, calls and invokes with operand bundles are allowed to have
memory effects not fully described by the memory effects on the call
target, so we can't be optimistic around operand-bundled calls from an
SCC into itself.

llvm-svn: 260244

It was using format() with a string for 64-bit types but was
passed a 32-bit type in places when printing values for
32-bit Mach-O files.

rdar://24542509

llvm-svn: 260243

The logic to pair instructions and merge narrow instructions has become cloogy
and error prone.  This patch beings to unravel these two similar, but distinct
optimizations.

llvm-svn: 260242

This reverts commit r260194.

It caused PR26549. There's probably a better way to do this also.

llvm-svn: 260241

As mentioned in http://reviews.llvm.org/D16828 , the related masked load transform
will need this logic, so I'm moving it out to make that patch smaller.

llvm-svn: 260240

Summary: This also fixes an infinite recursion between lldb_private::operator>> () and Scalar::operator>>= ().

Reviewers: sagar, tberghammer, labath

Subscribers: lldb-commits

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

Patch by Marianne Mailhot-Sarrasin

llvm-svn: 260239

Use the VFTable components to determine whether or not we should emit
RTTI data instead of duplicating the VFTableBuilder's logic.

llvm-svn: 260238

Summary:
This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
8-byte atomic operations call into the libatomic library.

Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg

Subscribers: cfe-commits

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

llvm-svn: 260235

Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.

For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when lsan tests fail since their
name no longer implies that they are trying to test the default target.

Reviewers: samsonov

Subscribers: tberghammer, danalbert, llvm-commits, srhines

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

llvm-svn: 260232

Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.

For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.

Reviewers: samsonov

Subscribers: tberghammer, danalbert, llvm-commits, srhines

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

llvm-svn: 260231

Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.

For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.

Reviewers: samsonov

Subscribers: tberghammer, danalbert, srhines, llvm-commits

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

llvm-svn: 260230

llvm-svn: 260229

llvm-svn: 260228

Summary:
This fixes duplicate test names in the test results, so:
  PASS: SanitizerCommon-asan :: fopen_nullptr.c (304 of 431)
  PASS: SanitizerCommon-asan :: fopen_nullptr.c (305 of 431)
is now:
  PASS: SanitizerCommon-asan-i386-Linux :: fopen_nullptr.c (282 of 431)             
  PASS: SanitizerCommon-asan-x86_64-Linux :: fopen_nullptr.c (316 of 431)

Reviewers: samsonov

Subscribers: llvm-commits

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

llvm-svn: 260227

llvm-svn: 260226

llvm-svn: 260225

This is the function equivalent of a copy relocation.

Since functions are expected to change sizes, we cannot use copy
relocations. In situations where one would be needed, what is done
instead is:
* Create a plt entry
* Output an undefined symbol whose addr is the plt entry.

The dynamic linker makes sure any shared library uses the plt entry as
the function address.

llvm-svn: 260224

Reviewers: alexfh

Subscribers: cfe-commits

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

llvm-svn: 260223

Registering the gnuNullExpr AST matcher as a dynamic matcher so that it is available from clang-query.

llvm-svn: 260222

llvm-svn: 260221

llvm-svn: 260220

llvm-svn: 260219

llvm-svn: 260218

llvm-svn: 260217

llvm-svn: 260216

directive.

llvm-svn: 260215