| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Try to be more clever about selecting the default format. When an existing
archive is used, use the type of the archive to determine the format. When
existing members are present, use the first member's format to determine the
format to use. If we are creating an empty archive (MRI mode) or are adding
non-object members, default to the current behaviour of using the host type due
to the lack of a better alternative. This aids in cross-compilation on Darwin
to non-Darwin platforms which rely on GNU format archives.
llvm-svn: 273373
|
|
|
|
|
|
| |
fail. Investigation needed.
llvm-svn: 273372
|
|
|
|
| |
llvm-svn: 273371
|
|
|
|
|
|
|
|
| |
Patch by Xinyu Zhuang.
Differential Revision: http://reviews.llvm.org/D19309
llvm-svn: 273370
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21532
llvm-svn: 273369
|
|
|
|
| |
llvm-svn: 273368
|
|
|
|
| |
llvm-svn: 273367
|
|
|
|
| |
llvm-svn: 273366
|
|
|
|
| |
llvm-svn: 273365
|
|
|
|
|
|
| |
test/libcxx/language.support.
llvm-svn: 273364
|
|
|
|
|
|
|
| |
Mostly removing dead code. Apparently gcc's warning
for unused functions is better
llvm-svn: 273363
|
|
|
|
| |
llvm-svn: 273362
|
|
|
|
| |
llvm-svn: 273361
|
|
|
|
| |
llvm-svn: 273360
|
|
|
|
| |
llvm-svn: 273359
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now include namespace scope info in LF_FUNC_ID records and we emit
LF_MFUNC_ID records for member functions as we should.
Class names are now fully qualified, which is what MSVC does.
Add a little bit of scaffolding to handle ThisAdjustment when it arrives
in DISubprogram.
llvm-svn: 273358
|
|
|
|
| |
llvm-svn: 273357
|
|
|
|
| |
llvm-svn: 273356
|
|
|
|
| |
llvm-svn: 273355
|
|
|
|
| |
llvm-svn: 273354
|
|
|
|
| |
llvm-svn: 273353
|
|
|
|
|
|
| |
STL@microsoft.com
llvm-svn: 273352
|
|
|
|
| |
llvm-svn: 273351
|
|
|
|
| |
llvm-svn: 273350
|
|
|
|
| |
llvm-svn: 273349
|
|
|
|
| |
llvm-svn: 273348
|
|
|
|
|
|
|
|
|
|
|
| |
This new test tests that functions are capable of being imported, rather than
that the import pass is run. This new test is compatible with the approach
being developed in D20268 which runs the importer on its own rather than in
a pass.
Differential Revision: http://reviews.llvm.org/D21542
llvm-svn: 273347
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, relocations for MIPS were scanned twice; once in regular
scanRelocs() and the other is in scanRelocsForThunks. In the former
function, we computed types of relocations and skipped R_THUNK relocations.
In the latter function, we computed the same value again and skipped
all but R_THUNK relocations. It was wasteful. This patch fixes that.
Now R_THUNK relocations are handled in the regular manner.
llvm-svn: 273346
|
|
|
|
|
|
| |
STL@microsoft.com
llvm-svn: 273345
|
|
|
|
| |
llvm-svn: 273344
|
|
|
|
| |
llvm-svn: 273343
|
|
|
|
|
|
| |
standard.
llvm-svn: 273342
|
|
|
|
| |
llvm-svn: 273341
|
|
|
|
|
|
|
|
|
|
| |
Teach trackNullOrUndefValue() how to properly look through PseudoObjectExprs
to find the underlying semantic method call for property getters. This fixes a
crash when looking through class property getters that I introduced in r265839.
rdar://problem/26796666
llvm-svn: 273340
|
|
|
|
|
|
|
|
|
| |
Do not instrument pointers with address space attributes since we cannot track
them anyway. Instrumenting them results in false positives in ASan and a
compiler crash in TSan. (The compiler should not crash in any case, but that's
a different problem.)
llvm-svn: 273339
|
|
|
|
|
|
|
|
| |
The content of this directory was removed in r259041, but the directory itself
was forgotten (probably because of using git-svn).
Reported-by: Eugene Zelenko <eugene.zelenko@gmail.com>
llvm-svn: 273338
|
|
|
|
|
|
| |
Previously, `Buf + 4` was written twice.
llvm-svn: 273337
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
issue with globals.
This change is motivated by an upcoming change to the metadata representation
used for CFI. The indirect function call checker needs type information for
external function declarations in order to correctly generate jump table
entries for such declarations. We currently associate such type information
with declarations using a global metadata node, but I plan [1] to move all
such metadata to global object attachments.
In bitcode, metadata attachments for function declarations appear in the
global metadata block. This seems reasonable to me because I expect metadata
attachments on declarations to be uncommon. In the long term I'd also expect
this to be the case for CFI, because we'd want to use some specialized bitcode
format for this metadata that could be read as part of the ThinLTO thin-link
phase, which would mean that it would not appear in the global metadata block.
To solve the lazy loaded metadata issue I was seeing with D20147, I use the
same bitcode representation for metadata attachments for global variables as I
do for function declarations. Since there's a use case for metadata attachments
in the global metadata block, we might as well use that representation for
global variables as well, at least until we have a mechanism for lazy loading
global variables.
In the assembly format, the metadata attachments appear after the "declare"
keyword in order to avoid a parsing ambiguity.
[1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21052
llvm-svn: 273336
|
|
|
|
| |
llvm-svn: 273335
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
some cases.
Libc++ has to deduce the 'allocator_arg_t' parameter as 'AllocArgT' for the
following constructor:
template <class Alloc> tuple(allocator_arg_t, Alloc const&)
Previously libc++ has tried to support tags derived from 'allocator_arg_t' by
using 'is_base_of<AllocArgT, allocator_arg_t>'. However this breaks whenever a
2-tuple contains a reference to an incomplete type as its first parameter.
See https://llvm.org/bugs/show_bug.cgi?id=27684
llvm-svn: 273334
|
|
|
|
|
|
|
| |
After r273302 LLVM_SYSTEM_LIBS may have entries that already have
-l prefix and we need to deal with that.
llvm-svn: 273333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds a new Xcode variable, LLDB_ENABLE_COVERAGE.
If set to 1, then the Xcode build will produce a clang
coverage-style build of LLDB. This can be done with a commandline
invocation such as:
xcodebuild -scheme desktop -configuration Debug build LLDB_ENABLE_COVERAGE=1
Alternatively, the variable can be locally modified from within Xcode
and built with the Xcode IDE.
llvm-svn: 273332
|
|
|
|
| |
llvm-svn: 273330
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21535
llvm-svn: 273329
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
perms::symlink_nofollow.
This changes how filesystem::permissions(p, perms) handles symlinks. Previously
symlinks were not resolved by default instead only getting resolved when
"perms::resolve_symlinks" was used. After this change symlinks are resolved
by default and perms::symlink_nofollow must be given to change this.
This issue has not yet been moved to Ready status, and I will revert if it
doesn't get moved at the current meeting. However I feel confident that it
will and it's nice to have implementations when moving issues.
llvm-svn: 273328
|
|
|
|
|
|
| |
Found by gcc 6.
llvm-svn: 273327
|
|
|
|
|
|
|
|
| |
Pass a `MemoryBuffer &` to BinaryCoverageReader::create() instead of a
`std::unique_ptr<MemoryBuffer> &`. This makes it easier to reason about
the ownership of the buffer at a glance.
llvm-svn: 273326
|
|
|
|
| |
llvm-svn: 273325
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
files
with the -macho and -universal-headers flags.
Just a follow on to r273207, I missed updating the printing of the fat magic
number when the universal file is a 64-bit universal file.
rdar://26899493
llvm-svn: 273324
|
|
|
|
|
|
|
|
| |
The filesystem tests were expecting the paths to the build/source directories
did not contain any symlinks. This patch resolves those symlinks before running
the test suite.
llvm-svn: 273323
|