| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 252216
|
|
|
|
| |
llvm-svn: 252215
|
|
|
|
| |
llvm-svn: 252214
|
|
|
|
|
|
|
|
| |
inalloca variables were not treated as static allocas, therefore didn't
participate in regular stack instrumentation. We don't want them to
participate in dynamic alloca instrumentation as well.
llvm-svn: 252213
|
|
|
|
|
|
|
|
|
|
| |
lib/llvm/ExecutionEngine/Orc
Patch by Richard Thomson!
Differential revision: http://reviews.llvm.org/D9973
llvm-svn: 252212
|
|
|
|
|
|
|
|
|
|
|
| |
for the root cause. The 'using llvm::isa;' declaration in Basic/LLVM.h only
pulls the declarations of llvm::isa that were declared prior to it into
namespace clang. In a modules build, this is a hermetic set of just the
declarations from LLVM. In a non-modules build, we happened to also pull the
declaration from lib/CodeGen/Address.h into namespace clang, which made the
code in question accidentally compile.
llvm-svn: 252211
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already had a test for this for 32-bit SEH catchpads, but those don't
actually create funclets. We had a bug that only appeared in funclet
prologues, where we would establish EBP and ESI as our FP and BP, and
then downstream prologue code would overwrite them.
While I was at it, I fixed Win64+funclets+stackrealign. This issue
doesn't come up as often there due to the ABI requring 16 byte stack
alignment, but now we can rest easy that AVX and WinEH will work well
together =P.
llvm-svn: 252210
|
|
|
|
|
|
|
|
| |
Patch by Richard Thomson!
Differential revision: http://reviews.llvm.org/D9967
llvm-svn: 252209
|
|
|
|
|
|
| |
Noticed by dschff in http://reviews.llvm.org/rL252203
llvm-svn: 252208
|
|
|
|
|
|
|
|
|
|
| |
clang-apply-replacements
Differential revision: http://reviews.llvm.org/D10025
Patch by Richard Thomson!
llvm-svn: 252207
|
|
|
|
| |
llvm-svn: 252206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a resubmission of r252179, but correctly ignores the source
files for other platforms.
Reviewers: granata.enrico, tberghammer, zturner, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14389
llvm-svn: 252205
|
|
|
|
|
|
| |
This more closely reflects the naming convention in the spec.
llvm-svn: 252204
|
|
|
|
|
|
|
|
|
| |
Mangling type information into MachineInstr opcode names was a temporary
measure, and it's starting to get hairy. At the same time, the MC instruction
printer wants to use AsmString strings for printing. This patch takes the
first step, starting the process of adding AsmStrings for instructions.
llvm-svn: 252203
|
|
|
|
|
|
|
| |
The page_size operator has been removed from the spec, and the resize_memory
operator has been changed to grow_memory.
llvm-svn: 252202
|
|
|
|
|
|
|
| |
The page_size operator has been removed from the spec, and the resize_memory
operator has been changed to grow_memory.
llvm-svn: 252201
|
|
|
|
|
|
|
|
| |
Before this commit memory reference identifiers have only been unique per
basic block, but not per (non-affine) ScopStmt. This commit now uses the
MemoryAccess base pointer to uniquely identify each Memory access.
llvm-svn: 252200
|
|
|
|
| |
llvm-svn: 252199
|
|
|
|
|
|
|
|
|
|
| |
LLDB could otherwise get confused if it is (for example) in a
root that is meant to install into an Xcode.app but hasn't
been installed yet. That way Xcode can fall back to the real
Xcode.app rather than trying to look for resources inside the
root.
llvm-svn: 252198
|
|
|
|
|
|
|
| |
This fixes a memory corruption issue, where we accessed more memory than
actually allocated.
llvm-svn: 252197
|
|
|
|
|
|
|
|
| |
Also, remove an enum hack where enum values were used as indexes into an array.
We may want to make this a real class to allow pattern-based queries/customization (D13417).
llvm-svn: 252196
|
|
|
|
| |
llvm-svn: 252195
|
|
|
|
|
|
|
| |
This isn't used yet; it's just a start towards eventually using MC to
do instruction printing, and eventually binary encoding.
llvm-svn: 252194
|
|
|
|
|
|
|
| |
in r252192 that changed the Archive and Child interfaces in libObject. These include
Rafael Espindola’s many suggested updates.
llvm-svn: 252193
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The needed lld matching changes to be submitted immediately next,
but this revision will cause lld failures with this alone which is expected.
This removes the eating of the error in Archive::Child::getSize() when the characters
in the size field in the archive header for the member is not a number. To do this we
have all of the needed methods return ErrorOr to push them up until we get out of lib.
Then the tools and can handle the error in whatever way is appropriate for that tool.
So the solution is to plumb all the ErrorOr stuff through everything that touches archives.
This include its iterators as one can create an Archive object but the first or any other
Child object may fail to be created due to a bad size field in its header.
Thanks to Lang Hames on the changes making child_iterator contain an
ErrorOr<Child> instead of a Child and the needed changes to ErrorOr.h to add
operator overloading for * and -> .
We don’t want to use llvm_unreachable() as it calls abort() and is produces a “crash”
and using report_fatal_error() to move the error checking will cause the program to
stop, neither of which are really correct in library code. There are still some uses of
these that should be cleaned up in this library code for other than the size field.
The test cases use archives with text files so one can see the non-digit character,
in this case a ‘%’, in the size field.
These changes will require corresponding changes to the lld project. That will be
committed immediately after this change. But this revision will cause lld failures
with this alone which is expected.
llvm-svn: 252192
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Absolute imports were introduced in Python 2.5 as a feature
(e.g. from __future__ import absolute_import), and made default
in Python 3.
When absolute imports are enabled, the import system changes in
a couple of ways:
1) The `import foo` syntax will *only* search sys.path. If `foo`
isn't in sys.path, it won't be found. Period. Without absolute
imports, the import system will also search the same directory
that the importing file resides in, so that you can easily
import from the same folder.
2) From inside a package, you can use a dot syntax to refer to higher
levels of the current package. For example, if you are in the
package lldbsuite.test.utility, then ..foo refers to
lldbsuite.test.foo. You can use this notation with the
`from X import Y` syntax to write intra-package references. For
example, using the previous locationa s a starting point, writing
`from ..support import seven` would import lldbsuite.support.seven
Since this is now the default behavior in Python 3, this means that
importing from the same directory with `import foo` *no longer works*.
As a result, the only way to have portable code is to force absolute
imports for all versions of Python.
See PEP 0328 [https://www.python.org/dev/peps/pep-0328/] for more
information about absolute and relative imports.
Differential Revision: http://reviews.llvm.org/D14342
Reviewed By: Todd Fiala
llvm-svn: 252191
|
|
|
|
| |
llvm-svn: 252190
|
|
|
|
| |
llvm-svn: 252189
|
|
|
|
| |
llvm-svn: 252188
|
|
|
|
|
|
| |
rdar://problem/23415863
llvm-svn: 252187
|
|
|
|
| |
llvm-svn: 252186
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update RegionStoreManager::getBinding() to return UnknownVal when trying to get
the binding for a BlockDataRegion. Previously, getBinding() would try to cast the
BlockDataRegion to a TypedValueRegion and crash. This happened when a block
was passed as a parameter to an inlined function for which
StackHintGeneratorForSymbol::getMessage() tried to generate a stack hint message.
rdar://problem/21291971
llvm-svn: 252185
|
|
|
|
| |
llvm-svn: 252184
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14388
llvm-svn: 252183
|
|
|
|
|
|
|
|
|
|
| |
This breaks the cmake build on all non-darwin platforms.
This reverts commit ff6cc332dd6654620e3408d06f8f49a0c9b3cd41.
rL252179
llvm-svn: 252182
|
|
|
|
| |
llvm-svn: 252181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of tests and __fixuint
Summary:
The following tests for 128-bit floating-point type behaved in a strange way, thought it were bugs, but seem to be mistakes in tests:
* `fixtfsi` test checked for `0x80000001` as a value returned for number less than can be represented, while `LONG_MIN` should be returned on saturation;
* `fixunstfdi` wasn't enabled for AArch64, only for PPC, but there is nothing PPC specific in that test;
* `multf3` tried to underflow multiplication by producing result with 16383 exponent, while there are still 112 bits of fraction plus implicit bit, so resultant exponent should be 16497.
Tests for some other builtins didn't exist:
* `fixtfdi`
* `fixtfti`
* `fixunstfti`
They were made by copying similar files and adjusting for wider types and adding/removing some reasonable/extra checks.
Also `__fixuint` seems to have off by one error, updated tests to catch this case.
Reviewers: rengolin, zatrazz, howard.hinnant, t.p.northover, jmolloy, enefaim
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14187
llvm-svn: 252180
|
|
|
|
| |
llvm-svn: 252179
|
|
|
|
| |
llvm-svn: 252178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This review is related to another review request http://reviews.llvm.org/D11268, does the same and merely fixes a couple of issues with it.
D11268 is quite old and has merge conflicts against the current trunk.
This request
- rebases D11268 onto the new trunk;
- resolves the merge conflicts;
- fixes the prologue_end tests, which do not pass due to the subprogram definitions not marked as distinct.
Reviewers: echristo, rengolin, kubabrecka
Subscribers: aemerson, rengolin, jyknight, dsanders, llvm-commits, asl
Differential Revision: http://reviews.llvm.org/D14338
llvm-svn: 252177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the issue of wrong CFA calculation in the following case:
0x08048400 <+0>: push %ebx
0x08048401 <+1>: sub $0x8,%esp
0x08048404 <+4>: **call 0x8048409 <test+9>**
0x08048409 <+9>: **pop %eax**
0x0804840a <+10>: add $0x1bf7,%eax
0x08048410 <+16>: mov %eax,%ebx
0x08048412 <+18>: call 0x80483f0 <bar>
0x08048417 <+23>: add $0x8,%esp
0x0804841a <+26>: pop %ebx
0x0804841b <+27>: ret
The highlighted instructions are a product of movpc instruction. The call
instruction changes the stack pointer, and pop instruction restores its
value. However, the rule for computing CFA is not updated and is wrong on
the pop instruction. So, e.g. backtrace in gdb does not work when on the pop
instruction. This adds cfi instructions for both call and pop instructions.
cfi_adjust_cfa_offset** instruction is used with the appropriate offset for
setting the rules to calculate CFA correctly.
Patch by Violeta Vukobrat.
Differential Revision: http://reviews.llvm.org/D14021
llvm-svn: 252176
|
|
|
|
|
|
|
|
|
| |
$ clang --target=armv7m-none-eabi -mthumb -march=armv7-m -c test.c
clang-3.8: warning: argument unused during compilation: '-mthumb'
Differential Revision: http://reviews.llvm.org/D14384
llvm-svn: 252175
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The spec uses "or" for inclusive-or and "xor" for exclusive-or
Reviewers: sunfish
Subscribers: jfb, llvm-commits, dschuff
Differential Revision: http://reviews.llvm.org/D14362
llvm-svn: 252174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use of #ifdef OMPT_DEBUG was causing messages to be generated under normal
operation when the OpenMP library was compiled with KMP_DEBUG enabled.
Elsewhere, KMP_DEBUG evaluates assertions, but never produces messages during
normal operation. To avoid this inconsistency, set OMPT_DEBUG using a cmake
variable LIBOMP_OMPT_DEBUG.
While I was editing the associated ompt-specific.h and ompt-general.c files,
make the spacing and comments consistent.
Patch by John Mellor-Crummey
Differential Revision: http://reviews.llvm.org/D14355
llvm-svn: 252173
|
|
|
|
|
|
|
|
|
|
|
| |
For generating scalar writes of non-affine subregions, all except phi
writes are generated in the exit block. The phi writes are generated in
the incoming block for which we errornously used the same BBMap. This
can conflict if a value for one block is synthesized, and then reused
for another block which is not dominated by the first block. This is
fixed by using block-specific BBMaps for phi writes.
llvm-svn: 252172
|
|
|
|
| |
llvm-svn: 252171
|
|
|
|
| |
llvm-svn: 252170
|
|
|
|
| |
llvm-svn: 252169
|
|
|
|
|
|
|
|
|
|
| |
We can conservatively know that CMOV's known bits are the intersection of known bits for each of its operands. This helps PerformCMOVToBFICombine find more opportunities.
I tried hard to create a testcase for this and failed - we have to sufficiently confuse DAG.computeKnownBits which can see through all the cheap tricks I tried to narrow my larger testcase down :(
This code is actually exercised in CodeGen/ARM/bfi.ll, there's just no functional difference because DAG.computeKnownBits gets the right answer in that case.
llvm-svn: 252168
|
|
|
|
| |
llvm-svn: 252167
|