Some paths through the copy constructors for 'ErrorOr' were calling
'get' when 'HasError' and 'IsValid' were not properly initialized.
Depending on what happened to be in memory for those member variables
the asserts in 'get' might incorrectly fire. Fixed by ensuring that
the member variables in question are always initialized before calling
'get'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174381 91177308-0d34-0410-b5e6-96231b3b80d8
This change lets us bootstrap LLVM/Clang under ASan and MSan. It contains
fixes for 2 issues:
- X86JIT reads return address from stack, which MSan does not know is
initialized.
- bugpoint tests run binaries with RLIMIT_AS. This does not work with certain
Sanitizers.
We are no longer including config.h in Compiler.h with this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174306 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for AArch64 (ARM's 64-bit architecture) to
LLVM in the "experimental" category. Currently, it won't be built
unless requested explicitly.
This initial commit should have support for:
+ Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions
(except the late addition CRC instructions).
+ CodeGen features required for C++03 and C99.
+ Compilation for the "small" memory model: code+static data <
4GB.
+ Absolute and position-independent code.
+ GNU-style (i.e. "__thread") TLS.
+ Debugging information.
The principal omission, currently, is performance tuning.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174054 91177308-0d34-0410-b5e6-96231b3b80d8
ErrorOr<void> represents an operation that returns nothing, but can still fail.
It should be used in cases where you need the aditional user data that ErrorOr
provides over error_code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173209 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to r171845, which fixes the same issue in the Support code.
Only targets with >256 relocations (principally AArch64) should be affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173151 91177308-0d34-0410-b5e6-96231b3b80d8
but I cannot reproduce the problem and have scrubed my sources and
even tested with llvm-lit -v --vg.
Support for Mips register information sections.
Mips ELF object files have a section that is dedicated
to register use info. Some of this information such as
the assumed Global Pointer value is used by the linker
in relocation resolution.
The register info file is .reginfo in o32 and .MIPS.options
in 64 and n32 abi files.
This patch contains the changes needed to create the sections,
but leaves the actual register accounting for a future patch.
Contributer: Jack Carter
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172847 91177308-0d34-0410-b5e6-96231b3b80d8
In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
as part of work to allow the user to supply a different default
target triple at configure time. This change also affected the JIT.
However, it is inappropriate to use the default target triple in the
JIT in most circumstances because this will not necessarily match
the current architecture used by the process, leading to illegal
instruction and other such errors at run time.
Introduce the getProcessTriple() function for use in the JIT and
its clients, and cause the JIT to use it. On architectures with a
single bitness, the host and process triples are identical. On other
architectures, the host triple represents the architecture of the
host CPU, while the process triple represents the architecture used
by the host CPU to interpret machine code within the current process.
For example, when executing 32-bit code on a 64-bit Linux machine,
the host triple may be 'x86_64-unknown-linux-gnu', while the process
triple may be 'i386-unknown-linux-gnu'.
This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
platforms.
Differential Revision: http://llvm-reviews.chandlerc.com/D254
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172627 91177308-0d34-0410-b5e6-96231b3b80d8
Like Clang's FixItHint, SMFixIt represents an insertion, replacement, or
removal of source text. One or more fix-its can be emitted as part of
a diagnostic, and will be printed below the source range line to show the
user how they can fix their code.
Currently, the only client of SMFixIt is clang-tblgen; thus, the tests for
this behavior live in clang/test/TableGen/tg-fixits.td. If/when SMFixIt is
adopted within LLVM itself, those tests should be moved to the LLVM suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172086 91177308-0d34-0410-b5e6-96231b3b80d8
into a new function llvm::sys::PrintStackTrace, so that it's available to clients for logging purposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171989 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adjust the r171506 to make all DWARF enconding pc-relative
for PPC64. It also adds the R_PPC64_REL32 relocation handling in MCJIT
(since the eh_frame will not generate PIC-relative relocation) and also
adds the emission of stubs created by the TTypeEncoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171979 91177308-0d34-0410-b5e6-96231b3b80d8
Stop using BumpPtrAllocator for HNodes because
they have fields (vector, map) which require HNode
destructors to be run.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171896 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary not only for representing empty ranges, but for handling
multibyte characters in the input. (If the end pointer in a range refers to
a multibyte character, should it point to the beginning or the end of the
character in a char array?) Some of the code in the asm parsers was already
assuming this anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171765 91177308-0d34-0410-b5e6-96231b3b80d8
turning a code like this:
if (foo)
free(foo)
into that:
free(foo)
Move a call to free from basic block FB into FB's predecessor, P,
when the path from P to FB is taken only if the argument of free is
not equal to NULL.
Some restrictions apply on P and FB to be sure that this code motion
is profitable. Namely:
1. FB must have only one predecessor P.
2. FB must contain only the call to free plus an unconditional
branch to S.
3. P's successors are FB and S.
Because of 1., we will not increase the code size when moving the call
to free from FB to P.
Because of 2., FB will be empty after the move.
Because of 2. and 3., P's branch instruction becomes useless, so as FB
(simplifycfg will do the job).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171762 91177308-0d34-0410-b5e6-96231b3b80d8