AbortedChanges

Summary

  1. Merging r310712: ------------------------------------------------------------------------ r310712 | mgorny | 2017-08-11 06:25:20 -0700 (Fri, 11 Aug 2017) | 26 lines [cmake] Expose the dependencies of ExecutionEngine as PUBLIC Expose the dependencies of LLVMExecutionEngine library as PUBLIC rather than PRIVATE when building a shared library. This is necessary because the library is not contained but exposes API of other LLVM libraries via its headers. This causes other libraries to fail to link if the linker verifies for correctness of -l flags (i.e. fails on indirect dependencies). This e.g. happens when building LLDB against shared LLVM: lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTIN4llvm18MCJITMemoryManagerE[_ZTIN4llvm18MCJITMemoryManagerE]+0x10): undefined reference to `typeinfo for llvm::RuntimeDyld::MemoryManager' lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN4llvm18MCJITMemoryManagerE[_ZTVN4llvm18MCJITMemoryManagerE]+0x60): undefined reference to `llvm::RuntimeDyld::MemoryManager::anchor()' lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE[_ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE]+0x48): undefined reference to `llvm::RTDyldMemoryManager::deregisterEHFrames()' lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE[_ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE]+0x60): undefined reference to `llvm::RuntimeDyld::MemoryManager::anchor()' lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE[_ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE]+0xd0): undefined reference to `llvm::JITSymbolResolver::anchor()' collect2: error: ld returned 1 exit status Declaring the dependencies as PUBLIC guarantees that any package using the ExecutionEngine library will also get explicit -l flags for the dependent libraries guaranteeing that the symbols exposed in headers could be resolved. Patch originally written by NAKAMURA Takumi. Differential Revision: https://reviews.llvm.org/D36211 ------------------------------------------------------------------------
  2. Merging r311229: ------------------------------------------------------------------------ r311229 | chandlerc | 2017-08-18 23:56:11 -0700 (Fri, 18 Aug 2017) | 19 lines [Inliner] Fix a nasty bug when inlining a non-recursive trace of a function into itself. We tried to fix this before in r306495 but that got reverted as the assert was actually hit. This fixes the original bug (which we seem to have lost track of with the revert) by blocking a second remapping when the function being inlined is also the caller and the remapping could succeed but erroneously. The included test case would actually load from an inlined copy of the alloca before this change, failing to load the stored value and miscompiling. Many thanks to Richard Smith for diagnosing a user miscompile to this bug, and to Kyle for the first attempt and initial analysis and David Li for remembering the issue and how to fix it and suggesting the patch. I'm just stitching it together and landing it. =] ------------------------------------------------------------------------
  3. Merging r311258: ------------------------------------------------------------------------ r311258 | mstorsjo | 2017-08-19 12:47:48 -0700 (Sat, 19 Aug 2017) | 9 lines [ARM] Check the right order for halves of VZIP/VUZP if both parts are used This is the exact same fix as in SVN r247254. In that commit, the fix was applied only for isVTRNMask and isVTRN_v_undef_Mask, but the same issue is present for VZIP/VUZP as well. This fixes PR33921. Differential Revision: https://reviews.llvm.org/D36899 ------------------------------------------------------------------------
  4. [libFuzzer] add one more test to the bot (in WARNINGS mode for now)
Revision 311376 by hans:
Merging r310712:
------------------------------------------------------------------------
r310712 | mgorny | 2017-08-11 06:25:20 -0700 (Fri, 11 Aug 2017) | 26 lines

[cmake] Expose the dependencies of ExecutionEngine as PUBLIC

Expose the dependencies of LLVMExecutionEngine library as PUBLIC rather
than PRIVATE when building a shared library. This is necessary because
the library is not contained but exposes API of other LLVM libraries via
its headers.

This causes other libraries to fail to link if the linker verifies for
correctness of -l flags (i.e. fails on indirect dependencies). This e.g.
happens when building LLDB against shared LLVM:

  lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTIN4llvm18MCJITMemoryManagerE[_ZTIN4llvm18MCJITMemoryManagerE]+0x10): undefined reference to `typeinfo for llvm::RuntimeDyld::MemoryManager'
  lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN4llvm18MCJITMemoryManagerE[_ZTVN4llvm18MCJITMemoryManagerE]+0x60): undefined reference to `llvm::RuntimeDyld::MemoryManager::anchor()'
  lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE[_ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE]+0x48): undefined reference to `llvm::RTDyldMemoryManager::deregisterEHFrames()'
  lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE[_ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE]+0x60): undefined reference to `llvm::RuntimeDyld::MemoryManager::anchor()'
  lib64/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE[_ZTVN12lldb_private15IRExecutionUnit13MemoryManagerE]+0xd0): undefined reference to `llvm::JITSymbolResolver::anchor()'
  collect2: error: ld returned 1 exit status

Declaring the dependencies as PUBLIC guarantees that any package using
the ExecutionEngine library will also get explicit -l flags for
the dependent libraries guaranteeing that the symbols exposed in headers
could be resolved.

Patch originally written by NAKAMURA Takumi.

Differential Revision: https://reviews.llvm.org/D36211
------------------------------------------------------------------------
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/branches/release_50llvm.src
The file was modified/llvm/branches/release_50/lib/ExecutionEngine/CMakeLists.txtllvm.src/lib/ExecutionEngine/CMakeLists.txt
Revision 311372 by hans:
Merging r311229:
------------------------------------------------------------------------
r311229 | chandlerc | 2017-08-18 23:56:11 -0700 (Fri, 18 Aug 2017) | 19 lines

[Inliner] Fix a nasty bug when inlining a non-recursive trace of
a function into itself.

We tried to fix this before in r306495 but that got reverted as the
assert was actually hit.

This fixes the original bug (which we seem to have lost track of with
the revert) by blocking a second remapping when the function being
inlined is also the caller and the remapping could succeed but
erroneously.

The included test case would actually load from an inlined copy of the
alloca before this change, failing to load the stored value and
miscompiling.

Many thanks to Richard Smith for diagnosing a user miscompile to this
bug, and to Kyle for the first attempt and initial analysis and David Li
for remembering the issue and how to fix it and suggesting the patch.
I'm just stitching it together and landing it. =]
------------------------------------------------------------------------
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/branches/release_50llvm.src
The file was modified/llvm/branches/release_50/lib/Transforms/Utils/CloneFunction.cppllvm.src/lib/Transforms/Utils/CloneFunction.cpp
The file was modified/llvm/branches/release_50/test/Transforms/Inline/recursive.llllvm.src/test/Transforms/Inline/recursive.ll
Revision 311369 by hans:
Merging r311258:
------------------------------------------------------------------------
r311258 | mstorsjo | 2017-08-19 12:47:48 -0700 (Sat, 19 Aug 2017) | 9 lines

[ARM] Check the right order for halves of VZIP/VUZP if both parts are used

This is the exact same fix as in SVN r247254. In that commit, the fix was
applied only for isVTRNMask and isVTRN_v_undef_Mask, but the same issue
is present for VZIP/VUZP as well.

This fixes PR33921.

Differential Revision: https://reviews.llvm.org/D36899
------------------------------------------------------------------------
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/branches/release_50llvm.src
The file was modified/llvm/branches/release_50/lib/Target/ARM/ARMISelLowering.cppllvm.src/lib/Target/ARM/ARMISelLowering.cpp
The file was modified/llvm/branches/release_50/test/CodeGen/ARM/vzip.llllvm.src/test/CodeGen/ARM/vzip.ll
Revision 311367 by kcc:
[libFuzzer] add one more test to the bot (in WARNINGS mode for now)
Change TypePath in RepositoryPath in Workspace
The file was modified/zorg/trunk/zorg/buildbot/builders/sanitizers/buildbot_fuzzer.shzorg/zorg/buildbot/builders/sanitizers/buildbot_fuzzer.sh