| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For ObjCXX, we can create a CastExpr with Kind being CK_UserDefinedConversion
and SubExpr being BlockExpr. Specifically one can return BlockExpr from
BuildCXXMemberCallExpr and the result can be used to build a CastExpr.
Fix the assumption in CastExpr::getSubExprAsWritten that SubExpr can only
be CXXMemberCallExpr.
rdar://problem/24364077
llvm-svn: 259591
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we were returning a tuple of (bool, skip_reason) from
the tuple function. This makes for some awkward code, especially
since a value of True for the first argument implies that the
second argument is None, and a value of False implies that the
second argument is not None. So it was basically redundant, and
with this patch we simply return the skip reason or None directly.
llvm-svn: 259590
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r259574 I fixed some of the issues with the mach header symbols
and DSO handles.
This is the next issue whereby the __mh_execute_header has to not
be dead stripped, and (to match ld64) should be dynamically referenced.
The test here should also have been added in r259574 to make sure that
we emit this symbol. But checking that it is not only emitted but also
has the correct reference type is fine.
llvm-svn: 259589
|
| |
|
|
|
|
| |
This is a fixup to r259451.
llvm-svn: 259588
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We support now code such as:
void multiple_types(char *Short, char *Float, char *Double) {
for (long i = 0; i < 100; i++) {
Short[i] = *(short *)&Short[2 * i];
Float[i] = *(float *)&Float[4 * i];
Double[i] = *(double *)&Double[8 * i];
}
}
To support such code we use as element type of the modeled array the smallest
element type of all original array accesses. Accesses with larger types are
modeled as multiple accesses with the smaller type.
For example the second load access is modeled as:
{ Stmt_bb2[i0] -> MemRef_Float[o0] : 4i0 <= o0 <= 3 + 4i0 }
To support jscop-rewritable memory accesses we need each statement instance to
only be assigned a single memory location, which will be the address at which
we load the value. Currently we obtain this address by taking the lexmin of
the access function. We may consider keeping track of the memory location more
explicitly in the future.
llvm-svn: 259587
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15625
llvm-svn: 259586
|
| |
|
|
|
|
| |
I introduced a declaration in 259583 to keep the diff readable. This change just moves the definition up to remove the declaration again.
llvm-svn: 259585
|
| |
|
|
| |
llvm-svn: 259584
|
| |
|
|
|
|
|
|
| |
This patch uses the newly introduced 'intersect' utility (from 259461: [LVI] Introduce an intersect operation on lattice values) to simplify existing code in LVI.
While not introducing any new concepts, this change is probably not NFC. The common 'intersect' function is more powerful that the ad-hoc implementations we'd had in a couple of places. Given that, we may see optimizations triggering a bit more often.
llvm-svn: 259583
|
| |
|
|
|
|
|
| |
The autoconf build system was removed - this doesn't even work and
doesn't need to be here.
llvm-svn: 259582
|
| |
|
|
| |
llvm-svn: 259578
|
| |
|
|
|
|
| |
It fails almost every test on clang-stage1-cmake-RA_check.
llvm-svn: 259577
|
| |
|
|
|
|
|
|
| |
See comments in test/CodeGen/X86/avx-vzeroupper.ll for more explanation.
Original patch by: Sean Silva
llvm-svn: 259576
|
| |
|
|
|
|
|
|
| |
This didn't affect X86_64, which is the only client of this code at the moment,
as stubs and pointers are both 8-bytes there. It will affect other platforms
though.
llvm-svn: 259575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The magic file which contained these symbols inherited from archive
which meant that the resolver didn't add the required atoms as archive
members only get added when referenced. Instead we now inherit from
SimpleFile which always links in the atoms needed.
The second issue was in the handling of these symbols when we emit
the MachO. The mach header symbol needs to be in the atom list as
it gets an offset (0), and being in the atom list makes sure it is
emitted to the symbol table. DSO handles are not emitted to the
symbol table.
rdar://problem/24450654
llvm-svn: 259574
|
| |
|
|
|
|
|
|
| |
If we can't assume the pointer value isn't within the bounds
of the object, it seems risky to try to replace the pointer
calculations.
llvm-svn: 259573
|
| |
|
|
|
|
| |
This reverts r259395 which reverted r259143.
llvm-svn: 259572
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, we used both single quotes and double quotes, and
some single-quoted tokens are concatenated with next tokens because
there were no spaces between them. That may be a cause of test flakiness
on Windows, which is reported as https://llvm.org/bugs/show_bug.cgi?id=26388.
The new test commands are more straightforward than before.
llvm-svn: 259559
|
| |
|
|
|
|
| |
Also add missing tests for the others.
llvm-svn: 259558
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds "Error" field to LinkerScript class. That field
is false by default, and set to true if there is a syntax error
in an input file. The linker script parser is a recursive-descedent
parser. Each function returns if Error is true -- so that
eventually the whole parser returns to a caller.
http://reviews.llvm.org/D16667
llvm-svn: 259557
|
| |
|
|
|
|
|
| |
This reverts commit r259538. Caused 92 test failures on
the OS X testbot.
llvm-svn: 259556
|
| |
|
|
|
|
| |
So that the file is move-safe.
llvm-svn: 259555
|
| |
|
|
|
|
|
|
| |
All MemoryBuffers for archive files are guaranteed to exist as long
as their children are used in the linker. So we don't need to copy
strings here. Thanks to Sean Silva for pointing this out.
llvm-svn: 259554
|
| |
|
|
|
|
|
|
|
| |
When the merging was involving LEAs, we were taking the wrong immediate
from the list of operands.
rdar://problem/24446069
llvm-svn: 259553
|
| |
|
|
| |
llvm-svn: 259552
|
| |
|
|
| |
llvm-svn: 259551
|
| |
|
|
|
|
| |
Mostly convert to use range loops.
llvm-svn: 259550
|
| |
|
|
|
|
|
|
|
| |
GenericIndirectStubsInfo.
This will allow architecture support classes for other architectures to re-use
this code.
llvm-svn: 259549
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeView requires us to accurately describe the extent of the inlined
code. We did this by grabbing the next debug location in source order
and using *that* to denote where we stopped inlining. However, this is
not sufficient or correct in instances where there is no next debug
location or the next debug location belongs to the start of another
function.
To get this correct, use the end symbol of the function to denote the
last possible place the inlining could have stopped at.
llvm-svn: 259548
|
| |
|
|
| |
llvm-svn: 259547
|
| |
|
|
|
|
|
| |
We shouldn't crash on unhandled intrinsics.
Also simplify failure handling in loop.
llvm-svn: 259546
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When promoting allocas to LDS, we know we are indexing
into a specific area just created, and the calculation
will also never overflow.
Also emit some of the muls as nsw nuw, because instcombine
infers this already from the range metadata. I think
putting this on the other adds and muls might be OK too,
but I'm not 100% sure.
llvm-svn: 259545
|
| |
|
|
| |
llvm-svn: 259544
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This should be no functional change, just a refactoring of the
skip decorators to all centralize on a single function,
`skipTestIfFn` that does all the logic. This allows easier
maintenance of the decorators and also centralizes all the
hard-to-understand logic in one place.
Reviewed by: Pavel Labath
Differential Revision: http://reviews.llvm.org/D16741
llvm-svn: 259543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
${TSAN_SUPPORTED_ARCH}.
Summary:
This is a workaround to a problem in the 3.8 release that affects MIPS and
possibly other targets where the default is not supported but a sibling is
supported.
When TSAN_SUPPORTED_ARCH is not empty, cmake currently attempts to build a
tsan'd libcxx as well as test tsan for the default target regardless of whether
the default target is supported or not. This causes problems on MIPS32 since
tsan is supported for MIPS64 but not MIPS32.
This patch causes cmake to only build the libcxx and run the lit test-suite for
archictures in ${TSAN_SUPPORTED_ARCH}
This re-commit fixes an issue where 'check-tsan' continued to look for the
tsan'd libc++ in the directory it used to be built in.
Reviewers: hans, samsonov
Subscribers: tberghammer, llvm-commits, danalbert, srhines, dvyukov
Differential Revision: http://reviews.llvm.org/D16685
llvm-svn: 259542
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since the prototype of mremap is
```
void *mremap(void *old_address, size_t old_size, size_t new_size,
int flags, ... /* void *new_address*/);
```
we need to cast new_address to void * when calling mremap. Otherwise,
the wrong value will be passed to mremap on x32.
Patch by H.J Lu!
Reviewers: kcc, eugenis, samsonov
Subscribers: samsonov, llvm-commits
Differential Revision: http://reviews.llvm.org/D16805
llvm-svn: 259540
|
| |
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D16793
llvm-svn: 259539
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The file contained very similar 4 implementation of the same data
structure with a lot of duplicated code and some minor API differences.
This CL refactor the class to eliminate the duplicated codes and to
unify the APIs.
RangeMap.h also contained a class called AddressDataArray what have very
little added functionality over an std::vector and used only by
ObjectFileMacO The CL moves the class to ObjectFileMachO.cpp as it isn't
belongs into RangeMap.h and shouldn't be used in new places anyway
because of the little added functionality.
Differential revision: http://reviews.llvm.org/D16769
llvm-svn: 259538
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main purpose here is that vfma/vfms should be symmetric, and they are
supported on most v7 cores.
The new ArchGuard is suggested by ACLE but prophylactic for us. Almost all CPUs
with NEON *will* have vfma, and the few exceptions I know of (e.g. Cortex-A8)
are incorrectly modelled by Clang so can't trigger a test.
Fortunately, they're getting rarer. But if we ever do support them properly
arm_neon.h should now do the right thing.
llvm-svn: 259537
|
| |
|
|
|
|
|
|
| |
This directive emits the binary annotations that describe line and code
deltas in inlined call sites. Single-stepping through inlined frames in
windbg now works.
llvm-svn: 259535
|
| |
|
|
|
|
|
|
|
|
|
| |
for-range expression.
Fix the issue discovered by fuzzing (PR23057, comment 18) by handling nullptr in Sema::ActOnCXXForRangeDecl
and correct delayed typos in for-range expression before calling Sema::ActOnCXXForRangeStmt. Also fixes PR26288.
Differential Revision: http://reviews.llvm.org/D16630
llvm-svn: 259532
|
| |
|
|
| |
llvm-svn: 259531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is implemented originally by Alexander Kornienko.
Reviewers: alexfh
Subscribers: cfe-commits
Patch by Haojian Wu!
Differential Revision: http://reviews.llvm.org/D16717
llvm-svn: 259530
|
| |
|
|
| |
llvm-svn: 259529
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Enables eip-based addressing, e.g.,
lea constant(%eip), %rax
lea constant(%eip), %eax
in MC, (used for the x32 ABI). EIP-base addressing is also valid in x86_64,
it is left enabled for that architecture as well.
Patch by João Porto
Differential Revision: http://reviews.llvm.org/D16581
llvm-svn: 259528
|
| |
|
|
| |
llvm-svn: 259527
|
| |
|
|
|
|
|
|
| |
Skipping this test while I investigate. It started failing
with r259379. (It is generating an error due to unicode
decode issues.)
llvm-svn: 259526
|
| |
|
|
|
|
|
|
|
| |
We create separate functions for fixed-size multi-dimensional, parameteric-sized
multi-dimensional, as well as single-dimensional memory accesses to reduce the
complexity of a large monolithic function.
Suggested-by: Michael Kruse <llvm@meinersbur.de>
llvm-svn: 259522
|
| |
|
|
|
|
|
|
| |
There is no need to pass the size of the elements as the last size dimension
to ScopArrayInfo. This information is already available through the ElementType.
Tracking it twice is not only redundant but may result in inconsistencies.
llvm-svn: 259521
|
| |
|
|
|
|
|
|
|
| |
${TSAN_SUPPORTED_ARCH}.
check-tsan does not pick up the correct libc++.so. It succeeded on my machine
by picking up the libc++.so that was built before making this change.
llvm-svn: 259519
|