| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 249365
|
| |
|
|
|
|
|
|
|
|
|
| |
This new syntax is built around putting each instruction on its own line
in a "mnemonic op, op, op" like syntax. It also uses conventional data
section directives like ".byte" and so on rather than requiring everything
to be in hierarchical S-expression format. This is a more natural syntax
for a ".s" file format from the perspective of LLVM MC and related tools,
while remaining easy to translate into other forms as needed.
llvm-svn: 249364
|
| |
|
|
| |
llvm-svn: 249363
|
| |
|
|
|
|
|
|
| |
if there exists not definition for the type.
For this to work, we need to clone the imported modules before building
the decl context chains of the DIEs in the non-skeleton CUs.
llvm-svn: 249362
|
| |
|
|
|
|
|
|
|
|
| |
February and this affected Xcode's abililty to cancel an attach to process by name.
Added the ability to specify if an attach by name should be synchronous or not in SBAttachInfo and ProcessAttachInfo.
<rdar://problem/22821480>
llvm-svn: 249361
|
| |
|
|
|
|
| |
We were mixing up the relocated and target sections.
llvm-svn: 249360
|
| |
|
|
|
|
|
|
|
|
|
| |
This was clearly wrong (thanks Rui for spotting), and I honestly would
like to get this tested so such mistakes won't repeat. Unfortunately, I
wasn't (easily) able to craft a test that exposes the bad behavior.
Ideally, we would like to get tests of this kind for all relocations, but
at the time of writing, this is not true. So, for now just fix this bug
and try to re-evaluate a way to test this in the future.
llvm-svn: 249359
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang_darwin.mk
Summary: This is the Makefile analog of r247833, except that the test also had to be changed such that clang actually attempts to link the program as opposed to just building it. Because of that change, I also switched the order to checking for ld/clang architecture support, because now lack of ld support would make the clang check fail. This fixes PR24776.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13425
llvm-svn: 249358
|
| |
|
|
| |
llvm-svn: 249357
|
| |
|
|
| |
llvm-svn: 249356
|
| |
|
|
| |
llvm-svn: 249355
|
| |
|
|
| |
llvm-svn: 249354
|
| |
|
|
| |
llvm-svn: 249353
|
| |
|
|
| |
llvm-svn: 249352
|
| |
|
|
|
|
|
|
| |
Given the work we are doing on ThinLTO, we will never need to support
module groups and working sets in GCC's implementation of LIPO. These
are currently dead code, and will continue to be so.
llvm-svn: 249351
|
| |
|
|
|
|
| |
Before the ADDR variables could match the empty string.
llvm-svn: 249350
|
| |
|
|
| |
llvm-svn: 249349
|
| |
|
|
| |
llvm-svn: 249348
|
| |
|
|
| |
llvm-svn: 249347
|
| |
|
|
|
|
| |
No idea what asymmetry MSVC is findind.
llvm-svn: 249346
|
| |
|
|
| |
llvm-svn: 249345
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The CATCHRET operand did not match the MachineFunction's CFG. This
mismatch happened because FrameLowering created a new MachineBasicBlock
and updated the CFG but forgot to update the CATCHRET operand.
Let's make sure this doesn't happen again by strengthing the funclet
membership analysis: it can now reason about the membership of all basic
blocks, not just those inside of funclets.
llvm-svn: 249344
|
| |
|
|
|
|
| |
variadic function in C++ code. Corresponds to the CERT C++ secure coding rule: https://www.securecoding.cert.org/confluence/display/cplusplus/DCL50-CPP.+Do+not+define+a+C-style+variadic+function
llvm-svn: 249343
|
| |
|
|
|
|
|
|
|
| |
that change turns out to not be reasonable: mutating the AST of a parsed
template during instantiation is not a sound thing to do, does not work across
chained PCH / modules builds, and is in any case a special-case workaround to a
more general problem that should be solved centrally.
llvm-svn: 249342
|
| |
|
|
| |
llvm-svn: 249341
|
| |
|
|
|
|
|
| |
The dynamic relocation code needs refactoring, but it is probably better
to do it with this test passing.
llvm-svn: 249340
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On OS X libc++ needs to reexport libc++abi's symbols in order for them to be provided. We explicitly list the symbols to reexport it libcxx/lib/libc++abi2.exp. This patch adds the symbols required by std::bad_array_length which have been missing for some time.
However there is a problem. std::bad_array_length was add to libc++abi in September of 2013 by commit r190479, about a year after everything else. Therefore I think older OS X version have libc++abi versions without std::bad_array_length. On those systems
libc++ won't build with this change because we will try and export undefined symbols.
The workaround I would write to support older systems depends on the amount of people who would need it. If only a small number of developers are affected it might be sufficient to provide a CMake switch like `LIBCPP_LIBCPPABI_HAS_BAD_ARRAY_LENGTH` which is
ON by default and can be disabled by those who need it. Otherwise I think we should try to automatically detect if the symbols are present in `/usr/lib/libc++abi.dylib` and configure accordingly. I would prefer the first solution because writing CMake sucks.
Reviewers: mclow.lists, aprantl
Subscribers: aprantl, cfe-commits
Differential Revision: http://reviews.llvm.org/D13445
llvm-svn: 249339
|
| |
|
|
| |
llvm-svn: 249338
|
| |
|
|
|
|
|
|
| |
This patch add support for leak sanitizer for aarch64. Similar to
MIPS it uses a SizeClassAllocator32 due VMA constraints (aarch64
currently supports 39 and 42-bit VMA).
llvm-svn: 249337
|
| |
|
|
|
|
|
|
| |
~CodeGenABITypes out-of-line, which should have the same effect.
Thanks to David Blaikie for pointing this out!
llvm-svn: 249336
|
| |
|
|
| |
llvm-svn: 249335
|
| |
|
|
| |
llvm-svn: 249334
|
| |
|
|
|
|
| |
Kona meeting. Not to be linked to from other pages.
llvm-svn: 249333
|
| |
|
|
| |
llvm-svn: 249332
|
| |
|
|
|
|
| |
Patch by Jon Eyolfson.
llvm-svn: 249331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We are currently only using these aliases for VOPC instructions,
but this helper will make it easier to use them everywhere.
These aliases allow for the automatic matching of instructions
with forced 32-bit encoding. Eventually, we should be able to remove
the custom C++ logic we have for this in the assembler.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D13396
llvm-svn: 249330
|
| |
|
|
|
|
|
|
|
|
| |
include/clang/CodeGenABITypes.h is in meant to be included by external
users, but using a unique_ptr on the private CodeGenModule introduces a
dependency on the type definition that prevents such a use.
NFC
llvm-svn: 249328
|
| |
|
|
|
|
|
|
|
|
|
| |
Otherwise, the map will observe changes as long as MergeFunctions is alive. This
is bad because follow-up passes could replace-all-uses-with on the key of an
entry in the map. The value handle callback of ValueMap however asserts that the
key type matches.
rdar://22971893
llvm-svn: 249327
|
| |
|
|
|
|
| |
This matches the behavior of gold and bfd ld.
llvm-svn: 249326
|
| |
|
|
|
|
| |
generated pages
llvm-svn: 249325
|
| |
|
|
| |
llvm-svn: 249324
|
| |
|
|
|
|
|
| |
This matches the behavior of bfd ld and gold. It is also convenient for
testing other changes.
llvm-svn: 249323
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were previously codegen'ing memcpy as regular load/store operations and
hoping that the register allocator would allocate registers in ascending order
so that we could apply an LDM/STM combine after register allocation. According
to the commit that first introduced this code (r37179), we planned to teach the
register allocator to allocate the registers in ascending order. This never got
implemented, and up to now we've been stuck with very poor codegen.
A much simpler approach for achieving better codegen is to create MEMCPY pseudo
instructions, attach scratch virtual registers to them and then, post register
allocation, expand the MEMCPYs into LDM/STM pairs using the scratch registers.
The register allocator will have picked arbitrary registers which we sort when
expanding the MEMCPY. This approach also avoids the need to repeatedly calculate
offsets which ultimately ought to be eliminated pre-RA in order to decrease
register pressure.
Fixes PR9199 and PR23768.
[This is based on Peter Collingbourne's r238473 which was reverted.]
Differential Revision: http://reviews.llvm.org/D13239
Change-Id: I727543c2e94136e0f80b8e22d5642d7b9ee5b458
Author: Peter Collingbourne <peter@pcc.me.uk>
llvm-svn: 249322
|
| |
|
|
|
|
| |
and documentation.
llvm-svn: 249321
|
| |
|
|
| |
llvm-svn: 249320
|
| |
|
|
| |
llvm-svn: 249319
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 249318
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11219
llvm-svn: 249317
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For RealFileSystem this is getcwd()/chdir(), the synthetic file systems can
make up one for themselves. OverlayFileSystem now synchronizes the working
directories when a new FS is added to the overlay or the overlay working
directory is set. This allows purely artificial file systems that have zero
ties to the underlying disks.
Differential Revision: http://reviews.llvm.org/D13430
llvm-svn: 249316
|
| |
|
|
|
|
|
|
|
|
| |
This is a simple file system tree of memory buffers that can be filled by a
client. In conjunction with an OverlayFS it can be used to make virtual
files accessible right next to physical files. This can be used as a
replacement for the virtual file handling in FileManager and which I intend
to remove eventually.
llvm-svn: 249315
|