| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
It is now in the osx.cocoa package and so will be on by default for Apple
toolchains.
llvm-svn: 251966
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit r251926. I believe this is causing an LTO
bootstrapping bot failure
(http://lab.llvm.org:8080/green/job/llvm-stage2-cmake-RgLTO_build/3669/).
Haven't been able to repro it yet, but after looking at the metadata I
am pretty sure I know what is going on.
llvm-svn: 251965
|
| |
|
|
| |
llvm-svn: 251964
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
libraries. Packages themselves shouldn't need to import it,
because by the time it gets into the package, the top-level
script should have already done this. Indeed, it was just
adding the same values to sys.path multiple times, so this
patch is essentially no functional change.
To make sure it doesn't get re-introduced, we also delete the
`use_lldb_suite` module from `lldbsuite/test`, although the
original copy still remains in `lldb/test`
llvm-svn: 251963
|
| |
|
|
|
|
|
|
|
| |
To simplify and correct the preloading of a base pointer origin, e.g.,
the base pointer for the current indirect invariant load, we now just
check if there is an invariant access class that involves the base
pointer of the current class.
llvm-svn: 251962
|
| |
|
|
|
|
| |
size is equal to it's capacity
llvm-svn: 251961
|
| |
|
|
| |
llvm-svn: 251960
|
| |
|
|
|
|
|
|
|
|
| |
The `commands` module was deprecated in 2.7 and removed in 3.x.
As a workaround, we introduce a new module `seven` in
lldbsuite.support, and write helper functions in there that delegate
to the commands module if it is available, and re-implement their
functionality for cases where it is not available.
llvm-svn: 251959
|
| |
|
|
|
|
|
|
| |
We now create them as they are found and use higher level APIs.
This is a step in avoiding creating unnecessary sections.
llvm-svn: 251958
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14258
llvm-svn: 251957
|
| |
|
|
| |
llvm-svn: 251956
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce the notion of a module file extension, which introduces
additional information into a module file at the time it is built that
can then be queried when the module file is read. Module file
extensions are identified by a block name (which must be unique to the
extension) and can write any bitstream records into their own
extension block within the module file. When a module file is loaded,
any extension blocks are matched up with module file extension
readers, that are per-module-file and are given access to the input
bitstream.
Note that module file extensions can only be introduced by
programmatic clients that have access to the CompilerInvocation. There
is only one such extension at the moment, which is used for testing
the module file extension harness. As a future direction, one could
imagine allowing the plugin mechanism to introduce new module file
extensions.
llvm-svn: 251955
|
| |
|
|
|
|
| |
Two threads in the test can hit the watchpoint simultaneously. Fix the test to account for that.
llvm-svn: 251954
|
| |
|
|
|
|
|
|
|
|
| |
The required compiler-rt changes aren't present yet so attempting to
build with compiler-rt breaks. And since we're trying to deprecate
autotools we actually want to fix this in CMake primarily anyway.
This reverts r251712.
llvm-svn: 251953
|
| |
|
|
| |
llvm-svn: 251952
|
| |
|
|
|
|
|
| |
The android compiler can't compile the inferior because of an issue
in the standard library.
llvm-svn: 251951
|
| |
|
|
|
|
| |
there must be (at least) one more race hidden there...
llvm-svn: 251950
|
| |
|
|
|
|
|
|
| |
Now that the properties created within Objective-C class extensions go
into the extension themselves, we don't need any of the extra
complexity here.
llvm-svn: 251949
|
| |
|
|
|
|
|
|
|
|
|
| |
We do not need to model read-only statements in the SCoP as they will
not cause any side effects that are visible to the outside anyway.
Removing them should safe us time and might even simplify the ASTs we
generate.
Differential Revision: http://reviews.llvm.org/D14272
llvm-svn: 251948
|
| |
|
|
|
|
| |
This just makes the debug output nices sometimes.
llvm-svn: 251947
|
| |
|
|
|
|
|
|
| |
If a base pointer of a preloaded value has a base pointer origin, thus it is
an indirect invariant load, we have to make sure the base pointer origin is
preloaded first.
llvm-svn: 251946
|
| |
|
|
|
|
|
|
|
|
| |
ScalarEvolution doesn't allow the operands of an AddRec to be variant in the
loop of the AddRec. When we rewrite parameter SCEVs it might seem like the
new SCEV violates this property and ScalarEvolution will trigger an
assertion. To avoid this we move the start part out of an AddRec when we
rewrite it, thus avoid the operands to be possibly variant completely.
llvm-svn: 251945
|
| |
|
|
|
|
|
|
|
|
| |
and trampolines.""
This reverts commit r251937.
The test was updated to the new API, bring the API back.
llvm-svn: 251944
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I recently found that the variable naming wasn't working as expected with containers that are data members. The new index always received the name "Elem" (or equivalent) regardless of the container's name.
The check was assuming that the container's declaration was a VarDecl, which cannot be converted to a FieldDecl (a data member), and then it could never retrieve its name.
This also fixes some cases where the check failed to find the container at all (so it didn't do any fix) because of the same reason.
Reviewers: klimek
Subscribers: cfe-commits, alexfh
Differential Revision: http://reviews.llvm.org/D14289
llvm-svn: 251943
|
| |
|
|
|
|
| |
r251933 changed the Orc compile callbacks API, which broke this.
llvm-svn: 251942
|
| |
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 251941
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: The previous change was focused in detecting when a non-const object was used in a constant way. Looks like I forgot the most important and trivial case: when the object is already constant. Failing to detect this cases results in compile errors, due to trying to bind a constant object to a non-const reference in the range-for statement. This change should fix that.
Reviewers: klimek
Subscribers: alexfh, cfe-commits
Differential Revision: http://reviews.llvm.org/D14282
llvm-svn: 251940
|
| |
|
|
|
|
| |
This would match SHF_ALLOC or SHF_TLS. We want both.
llvm-svn: 251939
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a PHI to a SCEVConstant
Summary:
Since now Scalar Evolution can create non-add rec expressions for PHI
nodes, it can also create SCEVConstant expressions. This will confuse
replaceCongruentPHIs, which previously relied on the fact that SCEV
could not produce constants in this case.
We will now replace the node with a constant in these cases - or avoid
processing the Phi in case of a type mismatch.
Reviewers: sanjoy
Subscribers: llvm-commits, majnemer
Differential Revision: http://reviews.llvm.org/D14230
llvm-svn: 251938
|
| |
|
|
|
|
|
|
|
|
| |
trampolines."
This reverts commit r251933.
It broke the build of examples/Kaleidoscope/Orc/fully_lazy/toy.cpp.
llvm-svn: 251937
|
| |
|
|
|
|
| |
this project
llvm-svn: 251936
|
| |
|
|
|
|
|
|
| |
On OS X, `memchr` is called on a newly created thread even before `__tsan_thread_start_func` is invoked, which means that the ThreadState object for that thread will not yet be initialized. Let's add `COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED` into the interceptor to simply call `internal_memchr` in these cases.
Differential Revision: http://reviews.llvm.org/D14283
llvm-svn: 251935
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bypassing LLVM for this has a number of benefits:
1) Laziness support becomes asm-syntax agnostic (previously lazy jitting didn't
work on Windows as the resolver block was in Darwin asm).
2) For cross-process JITs, it allows resolver blocks and trampolines to be
emitted directly in the target process, reducing cross process traffic.
3) It should be marginally faster.
llvm-svn: 251933
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The code which was preventing the usage of the OS plugin while detach is in
progress also prevented us to update the thread list correctly. This resulted
in an empty thread list, which confused the detaching logic. Change the
condition do only do what it says (disable the usage of the OS plugin).
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14201
llvm-svn: 251932
|
| |
|
|
| |
llvm-svn: 251931
|
| |
|
|
|
|
|
|
| |
As of gcc 4.7 mingw-w64 no longer emits 128-bit structs as i128
Differential Revision: http://reviews.llvm.org/D14179
llvm-svn: 251930
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add chkstk/alloca for gcc objects.
Replace or instructions with test, the latter should be marginally more
efficent, as it does not write to memory.
Differential Revision: http://reviews.llvm.org/D14044
Patch by vadimcn
llvm-svn: 251928
|
| |
|
|
| |
llvm-svn: 251927
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, named metadata is linked before the LazilyLinkGlobalValues
list is walked and materialized/linked. As a result, references
from DISubprogram and DIGlobalVariable metadata to yet unmaterialized
functions and variables cause them to be added to the lazy linking
list and their definitions are materialized and linked.
This makes the llvm-link -only-needed option not have the intended
effect when debug information is present, as the otherwise unneeded
functions/variables are still linked in.
Additionally, for ThinLTO I have implemented a mechanism to only link
in debug metadata needed by imported functions. Moving named metadata
linking after lazy GV linking will facilitate applying this mechanism
to the LTO and "llvm-link -only-needed" cases as well.
Reviewers: dexonsmith, tra, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14195
llvm-svn: 251926
|
| |
|
|
|
|
|
|
|
| |
A new call I added to linkInModule from llvm-link in r251866
was still passing in a boolean for an argument that was changed to an
enum in r246561. I didn't catch this in my merge since the bool false
matched the flag value it mapped to.
llvm-svn: 251925
|
| |
|
|
| |
llvm-svn: 251924
|
| |
|
|
| |
llvm-svn: 251923
|
| |
|
|
| |
llvm-svn: 251922
|
| |
|
|
| |
llvm-svn: 251921
|
| |
|
|
| |
llvm-svn: 251920
|
| |
|
|
| |
llvm-svn: 251919
|
| |
|
|
|
|
|
|
|
|
| |
This patch moves a few functions from `sanitizer_linux_libcdep.cc` to `sanitizer_posix_libcdep.cc` in order to use them on OS X as well. Plus a few more small build fixes.
This is part of an effort to port TSan to OS X, and it's one the very first steps. Don't expect TSan on OS X to actually work or pass tests at this point.
Differential Revision: http://reviews.llvm.org/D14235
llvm-svn: 251918
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The solution to bug 24074,rL249673 needed
to parse the function information from the Dwarf in order
to set the SymbolContext. For that, GetFunction was called
for the parent in GetTypeForDIE, which parses the
ChildParameters and in the flow, GetTypeForDIE was called
for one of the sibling die and so an infinite
loop was triggered by calling GetFunction repeatedly for the
same function.
The changes in this revision modify the GetTypeForDIE to only
resolve the function context in the Type Lookup flow and so
prevent the infinite loop.
A testcase has also been added to check for regression in the
future and a test vector had been added to the testcase of
24074.
Reviewers: jingham, tberghammer, clayborg
Differential Revision: http://reviews.llvm.org/D14202
llvm-svn: 251917
|
| |
|
|
|
|
|
|
|
|
| |
This patch modifies `tsan_interceptors.cc` to be buildable on OS X. Several of the intercepted methods are not available on OS X, so we need to `#if !SANITIZER_MAC` them. Plus a few other fixes, e.g. `pthread_yield` doesn't exist, let's use `internal_sched_yield` instead.
This is part of an effort to port TSan to OS X, and it's one the very first steps. Don't expect TSan on OS X to actually work or pass tests at this point.
Differential Revision: http://reviews.llvm.org/D14237
llvm-svn: 251916
|
| |
|
|
|
|
|
|
| |
Hi, this patch adds a CMake flag called `COMPILER_RT_ENABLE_TSAN_OSX`, which is off by default. If enabled, the build system will be building the OS X version of the TSan runtime library (called `libclang_rt.tsan_osx_dynamic.dylib`). I'll submit patches that fix OS X build errors shortly.
This is part of an effort to port TSan to OS X, and it's one the very first steps. Don't expect TSan on OS X to actually work or pass tests at this point.
llvm-svn: 251915
|