| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
'const' from some other ArrayRef uses since its implicitly const already.
llvm-svn: 216524
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We supported transforming:
(gep i8* X, -(ptrtoint Y))
to:
(inttoptr (sub (ptrtoint X), (ptrtoint Y)))
However, this only fired if 'X' had type i8*. Generalize this to
support various types of different sizes. This results in much better
CodeGen, especially for pointers to packed structs.
llvm-svn: 216523
|
| |
|
|
|
|
|
|
|
|
| |
Several options were moved to the clang_ignored_gcc_optimization group
in r213365, but -fkeep-inline-functions was accidentally dropped. This
restores the flag.
Patch by Steven Wu. Thanks!
llvm-svn: 216522
|
| |
|
|
|
|
| |
space.
llvm-svn: 216521
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the no-arguments case. Don't expand this to an __attribute__((nonnull(A, B,
C))) attribute, since that does the wrong thing for function templates and
varargs functions.
In passing, fix a grammar error in the diagnostic, a crash if
__attribute__((nonnull(N))) is applied to a varargs function,
a bug where the same null argument could be diagnosed multiple
times if there were multiple nonnull attributes referring to it,
and a bug where nonnull attributes would not be accumulated correctly
across redeclarations.
llvm-svn: 216520
|
| |
|
|
| |
llvm-svn: 216519
|
| |
|
|
|
|
| |
contains an unmatched closing bracket token.
llvm-svn: 216518
|
| |
|
|
| |
llvm-svn: 216517
|
| |
|
|
| |
llvm-svn: 216516
|
| |
|
|
| |
llvm-svn: 216515
|
| |
|
|
| |
llvm-svn: 216514
|
| |
|
|
|
|
| |
know to generate synthetic children
llvm-svn: 216513
|
| |
|
|
|
|
|
|
| |
IMAGE_REL_AMD64_ADDR64 relocation should set 64-bit *VA* (virtual
address) instead of *RVA* (relative virtual address), so we have
to add the iamge base to the target's RVA.
llvm-svn: 216512
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When a shift with extension or an add with shift and extension cannot be folded
into the memory operation, then the address calculation has to be materialized
separately. While doing so the code forgot to consider a possible sign-/zero-
extension. This fix folds now also the sign-/zero-extension into the add or
shift instruction which is used to materialize the address.
This fixes rdar://problem/18141718.
llvm-svn: 216511
|
| |
|
|
| |
llvm-svn: 216510
|
| |
|
|
|
|
| |
AST, Basic, Frontend, and Lex.
llvm-svn: 216509
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After discussing implementing more tests for this with @danalbert & @mclow, I
realized this change is not correct.
The C++ standard requires do_is() to behave as if it were a loop that checked
is(). Furthermore, it requires is() to check "The first form returns the result
of the expression (M & m) != 0; i.e., true if the character has the
characteristics specified"... which the reverted patch definitely does not
conform to. Even further, furthermore, this requires that ctype's mask be an
actual bitmask, unlike what android and newlib provide for _ctype_.
Fixing the original bug that instigated this patch remains TBD.
llvm-svn: 216508
|
| |
|
|
|
|
|
|
|
| |
This time though, preserve the extension for bool types since that's compatible
with what MSVC expects.
See http://reviews.llvm.org/D4380
llvm-svn: 216507
|
| |
|
|
| |
llvm-svn: 216506
|
| |
|
|
|
|
|
|
| |
r216239
Found these while testing something else.
llvm-svn: 216505
|
| |
|
|
|
|
|
| |
Patch by Sean Callanan.
<rdar://problem/18140875>
llvm-svn: 216504
|
| |
|
|
|
|
|
| |
functions. Also don't needlessly pull in non-canonical declarations of the
overridden virtual functions.
llvm-svn: 216503
|
| |
|
|
|
|
| |
time it runs.. probably leftover from when I was debugging it
llvm-svn: 216502
|
| |
|
|
|
|
|
|
| |
Instead completely cop out of formatting them for now.
This fixes llvm.org/PR20618.
llvm-svn: 216501
|
| |
|
|
|
|
|
|
|
| |
CMake gets confused by the fact that both LLVM and Clang now have
a CodeGen unittest. Rename the target to avoid that. The new test
was also missing ProfileData (thanks to Julien Lerouge for
pointing that out)
llvm-svn: 216499
|
| |
|
|
|
|
|
|
|
|
| |
creating the ModuleSpec to load the core file - we won't have a fat
core file and we can end up with cpu subtype mismatches if the core
file header isn't written out completely accurately. We need to
be a little loose in this particular case.
<rdar://problem/17843388>
llvm-svn: 216498
|
| |
|
|
|
|
|
| |
This patch: http://reviews.llvm.org/D5081
Original patch: http://reviews.llvm.org/D5071 (from @danalbert)
llvm-svn: 216497
|
| |
|
|
| |
llvm-svn: 216496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When the main file is created from a membuffer, there is no file entry that can be retrieved. This uses "__GLOBAL_I_a" in that case which is what was always used before r208128.
Reviewers: majnemer, thakis
Reviewed By: thakis
Subscribers: yaron.keren, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D5043
llvm-svn: 216495
|
| |
|
|
| |
llvm-svn: 216494
|
| |
|
|
| |
llvm-svn: 216493
|
| |
|
|
|
|
|
| |
By taking a reference we can do the ownership transfer in one place instead of
expecting every caller to do it.
llvm-svn: 216492
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MSVC doesn't extend integer types smaller than 64bit, so to preserve
binary compatibility, clang shouldn't either.
For example, the following C code built with MSVC:
unsigned test(unsigned v);
unsigned foobar(unsigned short);
int main() { return test(0xffffffff) + foobar(28); }
Produces the following:
0000000000000004: B9 FF FF FF FF mov ecx,0FFFFFFFFh
0000000000000009: E8 00 00 00 00 call test
000000000000000E: 89 44 24 20 mov dword ptr [rsp+20h],eax
0000000000000012: 66 B9 1C 00 mov cx,1Ch
0000000000000016: E8 00 00 00 00 call foobar
And as you can see, when setting up the call to foobar, only cx is overwritten.
If foobar is compiled with clang, then the zero extension added by clang means
the rest of the register, which contains garbage, could be used.
For example if foobar is:
unsigned foobar(unsigned short v) {
return v;
}
Compiled with clang -fomit-frame-pointer -O3 gives the following assembly:
foobar:
0000000000000000: 89 C8 mov eax,ecx
0000000000000002: C3 ret
And that function would return garbage because the 16 most significant bits of
ecx still contain garbage from the first call.
With this change, the code for that function is now:
foobar:
0000000000000000: 0F B7 C1 movzx eax,cx
0000000000000003: C3 ret
Reviewers: chapuni, rnk
Reviewed By: rnk
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D4380
llvm-svn: 216491
|
| |
|
|
| |
llvm-svn: 216490
|
| |
|
|
| |
llvm-svn: 216489
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.
For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.
Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.
llvm-svn: 216488
|
| |
|
|
|
|
| |
always for C++, and this API claims to be general enough that it should not drop C++ usability on the floor for no good reason. Fix it with an explicit offset argument
llvm-svn: 216487
|
| |
|
|
|
|
|
| |
This updates the DWARF language identifiers to include recent additions to
the DWARF 5 specification (draft).
llvm-svn: 216486
|
| |
|
|
| |
llvm-svn: 216485
|
| |
|
|
|
|
|
| |
Long term the idea if for the engine to not own the buffers, but for now
this is consistent with the rest of the API.
llvm-svn: 216484
|
| |
|
|
|
|
| |
type. Note that in this commit, the term synthetic child is not meant to refer to data formatters, but to the programmatically-generated children stored inside a ValueObject itself
llvm-svn: 216483
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depending on llvm-config allows for a few nice things (auto-detecting
LLVM source tree, version numbers, etc), but it's makes bootstrapping a
pain. Keep the llvm-config features around, but also fall back to being
able to configure based on -DLLVM_PATH=path/to/llvm.
Reviewers: jroelofs, loladiro
Reviewed By: loladiro
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5016
llvm-svn: 216482
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing matcher has lots of AT&T assembly dialect assumptions baked
into it. In particular, the hack for resolving the size of a memory
operand by appending the four most common suffixes doesn't work at all.
The Intel assembly dialect mnemonic table has ambiguous entries, so we
need to try matching multiple times with different operand sizes, since
that's the only way to choose different instruction variants.
This makes us more compatible with gas's implementation of Intel
assembly syntax. MSVC assumes you want byte-sized operations for the
instructions that we reject as ambiguous.
Reviewed By: grosbach
Differential Revision: http://reviews.llvm.org/D4747
llvm-svn: 216481
|
| |
|
|
|
|
|
|
| |
overloads, and conversion functions.
Patch by Craig Tenenbaum!
llvm-svn: 216480
|
| |
|
|
| |
llvm-svn: 216479
|
| |
|
|
| |
llvm-svn: 216478
|
| |
|
|
| |
llvm-svn: 216477
|
| |
|
|
| |
llvm-svn: 216476
|
| |
|
|
|
|
| |
PR 20642.
llvm-svn: 216475
|
| |
|
|
|
|
|
|
|
| |
lowering of the intrinsics.
Prior to this commit, most of the copy-related intrinsics could be optimized
away. The situation is still not ideal as there are several possibilities to
lower a given intrinsic. Currently, we match LLVM behavior.
llvm-svn: 216474
|