| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
@llvm.umul.with.overflow
Even if we formed @llvm.umul.with.overflow, we are still stuck
with that guard against div-by-zero, which is no longer needed,
because we didn't flatten the CFG.
llvm-svn: 366749
|
| |
|
|
|
|
| |
check
llvm-svn: 366748
|
| |
|
|
|
|
|
|
|
|
| |
overflow check
While we can form the @llvm.mul.with.overflow easily,
we are still left with that check that was guarding against div-by-0.
And in the second case we won't even flatten the CFG.
llvm-svn: 366747
|
| |
|
|
|
|
| |
Being affected by upcoming patch.
llvm-svn: 366746
|
| |
|
|
| |
llvm-svn: 366745
|
| |
|
|
|
|
|
|
| |
rdar://53267670
Differential Revision: https://reviews.llvm.org/D65116
llvm-svn: 366744
|
| |
|
|
|
|
|
|
|
|
|
| |
The xform has no real valuewhen it's using out of a complex pattern
output. The complex pattern was already creating TargetConstants with
i16, so this was just unnecessary machinery.
This allows global isel to import the simple cases once the complex
pattern is implemented.
llvm-svn: 366743
|
| |
|
|
|
|
|
| |
Its contents are stale and much better documentation can be found either
online or in the docs directory.
llvm-svn: 366742
|
| |
|
|
|
|
|
| |
This removes a stale piece of documentation about building LLDB with the
Xcode project.
llvm-svn: 366741
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Finally, after a lot of hard work from a bunch of people, we're in a
state where we can unify LLDB's build system.
This patch removes the hand-maintained Xcode project in favor of using
CMake in combination with the Xcode generator. Going forward, we want to
focus our efforts on improving the generated Xcode project.
Differential revision: https://reviews.llvm.org/D65109
llvm-svn: 366739
|
| |
|
|
|
|
|
|
|
| |
These tests *do not* work on device, but they *do* work in the
simulator.
rdar://53403778
llvm-svn: 366738
|
| |
|
|
|
|
| |
This reverts commit 9285295f75a231dc446fa7cbc10a0a391b3434a5.
llvm-svn: 366737
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Liveness analysis abstract attribute used to indicate which BasicBlocks are dead and can therefore be ignored.
Right now we are only looking at noreturn calls.
Reviewers: jdoerfert, uenoku
Subscribers: hiraditya, llvm-commits
Differential revision: https://reviews.llvm.org/D64162
llvm-svn: 366736
|
| |
|
|
|
|
|
| |
The constructors for std::pair and std::tuple have been made conditionally
explicit, however the synopsis in the headers do not reflect that.
llvm-svn: 366735
|
| |
|
|
|
|
|
|
|
|
| |
r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Android build.
Differential Revision: https://reviews.llvm.org/D65098
llvm-svn: 366734
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When trying to ascertain what language a variable belongs to, just
checking the compilation unit is often not enough. In r364845 I added a way to
check for a variable's language type, but didn't put it in Variable itself.
Let's go ahead and put it in Variable.
Reviewers: jingham, clayborg
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D64042
llvm-svn: 366733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directly in v16i8 with the correct 0x00 or 0xFF elements rather than using another VT and bitcasting it.
The build_vector will become a constant pool load. By using the
desired type initially, it ensures we don't generate a bitcast
of the constant pool load which will need to be folded with
the load.
While experimenting with another patch, I noticed that when the
load type and the constant pool type don't match, then
SimplifyDemandedBits can't handle it. While we should probably
fix that, this was a simple way to fix the issue I saw.
llvm-svn: 366732
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
convention
Summary:
Since we are planning to add ADDIStocHA for 32bit in later patch, we decided
to change 64bit one first to follow naming convention with 8 behind opcode.
Patch by: Xiangling_L
Differential Revision: https://reviews.llvm.org/D64814
llvm-svn: 366731
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue was detected by ASan in one of our tests. This test manually
invokes basic_filebuf::cloe(). fclose(__h.release() returned a non-zero
exit status, so __file_ wasn't set to 0. Later when basic_filebuf
destructor ran, we would enter the if (__file_) block again leading to
heap-use-after-free error.
The POSIX specification for fclose says that independently of the return
value, fclose closes the underlying file descriptor and any further
access (including another call to fclose()) to the stream results in
undefined behavior. This is exactly what happened in our test case.
To avoid this issue, we have to always set __file_ to 0 independently of
the fclose return value.
Differential Revision: https://reviews.llvm.org/D64979
llvm-svn: 366730
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Porting function return value attribute noalias to attributor.
This will be followed with a patch for callsite and function argumets.
Reviewers: jdoerfert
Subscribers: lebedev.ri, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D63067
llvm-svn: 366728
|
| |
|
|
|
|
|
|
|
| |
Stubs out a TargetLoweringObjectFileXCOFF class, implementing only
SelectSectionForGlobal for common symbols. Also adds an override of
EmitGlobalVariable in PPCAIXAsmPrinter which adds a number of defensive errors
and adds support for emitting common globals.
llvm-svn: 366727
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While debugging code that uses SafeStack, we've noticed that LLVM
produces an invalid DWARF. Concretely, in the following example:
int main(int argc, char* argv[]) {
std::string value = "";
printf("%s\n", value.c_str());
return 0;
}
DWARF would describe the value variable as being located at:
DW_OP_breg14 R14+0, DW_OP_deref, DW_OP_constu 0x20, DW_OP_minus
The assembly to get this variable is:
leaq -32(%r14), %rbx
The order of operations in the DWARF symbols is incorrect in this case.
Specifically, the deref is incorrect; this appears to be incorrectly
re-inserted in repalceOneDbgValueForAlloca.
With this change which inserts the deref after the offset instead of
before it, LLVM produces correct DWARF:
DW_OP_breg14 R14-32
Differential Revision: https://reviews.llvm.org/D64971
llvm-svn: 366726
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bytes inserted before an overaligned global need to be padded according
to the alignment set on the original global in order for the initializer
to meet the global's alignment requirements. The previous implementation
that padded to the pointer width happened to be correct for vtables on most
platforms but may do the wrong thing if the vtable has a larger alignment.
This issue is visible with a prototype implementation of HWASAN for globals,
which will overalign all globals including vtables to 16 bytes.
There is also no padding requirement for the bytes inserted after the global
because they are never read from nor are they significant for alignment
purposes, so stop inserting padding there.
Differential Revision: https://reviews.llvm.org/D65031
llvm-svn: 366725
|
| |
|
|
|
|
| |
Patch by Xiangling Liao.
llvm-svn: 366724
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D60885
llvm-svn: 366723
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were previously ignoring alignment entirely when combining globals
together in this pass. There are two main things that we need to do here:
add additional padding before each global to meet the alignment requirements,
and set the combined global's alignment to the maximum of all of the original
globals' alignments.
Since we now need to calculate layout as we go anyway, use the calculated
layout to produce GlobalLayout instead of using StructLayout.
Differential Revision: https://reviews.llvm.org/D65033
llvm-svn: 366722
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done at call-site and does not need to be handled in
__kmp_invoke_microtask. It was already absent from the x86
and x86_64 assembly, this patch removes it from the generic
implementation in z_Linux_util.cpp and adds documentation for
AArch64 and PPC64 that it's actually not needed. I can't test
on these architectures, so I don't want to change the code just
because it looks right :)
While at it, rename some variables for consistency and add a
check in test/ompt/parallel/normal.c that the pointer was reset
before entering the barrier.
Differential Revision: https://reviews.llvm.org/D64442
llvm-svn: 366721
|
| |
|
|
|
|
| |
MCStreamer directives
llvm-svn: 366720
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NS_ENUM and CF_ENUM.
Summary:
Addresses the formatting of NS_CLOSED_ENUM and CF_CLOSED_ENUM, introduced in Swift 5.
Before:
```
typedef NS_CLOSED_ENUM(NSInteger, Foo){FooValueOne = 1, FooValueTwo,
FooValueThree};
```
After:
```
typedef NS_CLOSED_ENUM(NSInteger, Foo) {
FooValueOne = 1,
FooValueTwo,
FooValueThree
};
```
Contributed by heijink.
Reviewers: benhamilton, krasimir
Reviewed By: benhamilton
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65012
llvm-svn: 366719
|
| |
|
|
|
|
| |
This is a left-over from r356288 which was reviewed in D58989.
llvm-svn: 366716
|
| |
|
|
| |
llvm-svn: 366715
|
| |
|
|
| |
llvm-svn: 366712
|
| |
|
|
|
|
|
| |
This reverts commit r366686 as it appears to be causing buildbot
failures on sanitizer-x86_64-linux-android and sanitizer-x86_64-linux.
llvm-svn: 366708
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Martin Andersson (martin.andersson@evoma.se)
If the process is resumed before the state is changed to "running"
there is a possibility (when single stepping) that the debugger stops
and changes the state to "stopped" before it is first changed to
"running". This causes the process to ignore the stop event (since
the state did not change) which in turn leads the DebuggerThread to
wait indefinitely for the exception predicate in HandleExceptionEvent.
Differential Revision: https://reviews.llvm.org/D62183
llvm-svn: 366703
|
| |
|
|
|
|
|
| |
Mapped /openmp[:experimental] to -fopenmp option and /openmp- option to
-fno-openmp
llvm-svn: 366702
|
| |
|
|
|
|
|
|
|
| |
This is a small fix for https://reviews.llvm.org/D64996. The types of
w0 and w1 in _Unwind_VRS_Get must be uint64_t, not uint32_t.
Committing as obvious.
llvm-svn: 366701
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libc++'s lit configuration infers the C++ language dialect when it is
not provided by checking which -std= flags that a compiler supports.
GCC 5 and GCC 6 have a -std=c++17 flag, however, they do not have full
C++17 support. The lit configuration has hardcoded logic that removes
-std=c++1z as an option to test for GCC < 7, but not -std=c++17.
This leads to a bunch of failures when running libc++ tests with GCC 5
or GCC 6. This patch adds -std=c++17 to the list of flags that are
discarded for GCC < 7 by lit's language dialect inference.
Thanks to Bryce Adelstein Lelbach for the patch.
Differential Revision: https://reviews.llvm.org/D62874
llvm-svn: 366700
|
| |
|
|
| |
llvm-svn: 366699
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
SelectionTree is a RecursiveASTVisitor which processes getSourceRange() for
every node. This is a lot of surface area with the AST, as getSourceRange()
is specialized for *many* node types.
And the resulting SelectionTree depends on the source ranges of many
visited nodes, and the order of traversal.
Put together, this means we really need a traversal log to debug when we
get an unexpected SelectionTree. I've built this ad-hoc a few times, now
it's time to check it in.
Example output:
```
D[14:07:44.184] Computing selection for </usr/local/google/home/sammccall/test.cc:1:7, col:8>
D[14:07:44.184] push: VarDecl const auto x = 42
D[14:07:44.184] claimRange: </usr/local/google/home/sammccall/test.cc:1:12, col:13>
D[14:07:44.184] push: NestedNameSpecifierLoc (empty NestedNameSpecifierLoc)
D[14:07:44.184] pop: NestedNameSpecifierLoc (empty NestedNameSpecifierLoc)
D[14:07:44.184] push: QualifiedTypeLoc const auto
D[14:07:44.184] pop: QualifiedTypeLoc const auto
D[14:07:44.184] claimRange: </usr/local/google/home/sammccall/test.cc:1:7, col:11>
D[14:07:44.184] hit selection: </usr/local/google/home/sammccall/test.cc:1:7, col:8>
D[14:07:44.184] skip: IntegerLiteral 42
D[14:07:44.184] skipped range = </usr/local/google/home/sammccall/test.cc:1:16>
D[14:07:44.184] pop: VarDecl const auto x = 42
D[14:07:44.184] claimRange: </usr/local/google/home/sammccall/test.cc:1:1, col:18>
D[14:07:44.184] skip: VarDecl int y = 43
D[14:07:44.184] skipped range = </usr/local/google/home/sammccall/test.cc:2:1, col:9>
D[14:07:44.184] Built selection tree
TranslationUnitDecl
VarDecl const auto x = 42
.QualifiedTypeLoc const auto
```
Reviewers: hokein
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65073
llvm-svn: 366698
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Feel free to reassign if needed.
Reviewers: mhalk, bollu, jdoerfert
Reviewed By: jdoerfert
Subscribers: jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64786
llvm-svn: 366697
|
| |
|
|
| |
llvm-svn: 366696
|
| |
|
|
|
|
|
| |
This was truncating register value that didn't fit in unsigned char.
Switch AMDGPU sendmsg intrinsics to using a tablegen pattern.
llvm-svn: 366695
|
| |
|
|
|
|
|
|
| |
Following up on the buildbot failures, this commits relaxes some tests:
instead of checking for specific IR output, it now ensures that the
underlying issue (the crash), and only that, doesn't happen.
llvm-svn: 366694
|
| |
|
|
|
|
|
|
| |
Just delete the memset as the ELFHeader constructor already
zero-initializes the object. Also clean up the ObjectFileELF
constructors/desctructors while I'm in there.
llvm-svn: 366692
|
| |
|
|
|
|
|
|
|
|
|
| |
ARMLowOverheadLoops would assert a failure if it did not find all the
pseudo instructions that comprise the hardware loop. Instead of doing
this, iterate through all the instructions of the function and revert
any remaining pseudo instructions that haven't been converted.
Differential Revision: https://reviews.llvm.org/D65080
llvm-svn: 366691
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Firstprivate variables are the variables, for which the private copies
must be created in the OpenMP regions and must be initialized with the
original values. Thus, we must report if the uninitialized variable is
used as firstprivate.
Reviewers: NoQ
Subscribers: guansong, jdoerfert, caomhin, kkwli0, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64765
llvm-svn: 366689
|
| |
|
|
| |
llvm-svn: 366688
|
| |
|
|
|
|
| |
CERT removed their C++ secure coding recommendations from public view and so the links within that documentation are stale. This updates various pieces of documentation to make this more clear, and to help add substance where our docs deferred to CERT's wiki.
llvm-svn: 366687
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch was not the reason of the buildbot failure.
Deleted code was introduced as a work around for a bug in the gold linker
(http://sourceware.org/PR16794). Test case that was given as a reason for
this part of code, the one on previous link, now works for the gold.
This condition is too strict and when a code is compiled with debug info
it forces generation of numerous relocations with symbol for architectures
that do not have relocation addend.
Reviewers: arsenm, espindola
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D64327
llvm-svn: 366686
|
| |
|
|
|
|
|
| |
The minnum/maxnum case are dead, and the cvt is handled by the
default.
llvm-svn: 366685
|