Displaying 1 50 of 265,554 commits (0.023s)

LLVM — llvm/trunk/lib/Analysis ModuleSummaryAnalysis.cpp, llvm/trunk/test/ThinLTO/X86 personality.ll personality-local.ll

[lib/Analysis] - Mark personality functions as live.

This is PR33245.

Case I am fixing is next:
Imagine we have 2 BC files, one defines and uses personality routine,
second has only declaration and also uses it.

Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did
not know about personality routines and leaved them dead even if function that
has routine was live.

As a result thinLTOInternalizeAndPromoteGUID() method changed binding for
such symbol to local. Later when LLD tried to link these objects it failed
because one object had undefined global symbol for routine and second
object contained local definition instead of global.

Patch set the live root flag on the corresponding FunctionSummary
for personality routines when we build the per-module summaries
during the compile step.

Differential revision: https://reviews.llvm.org/D36834

LLVM — lld/trunk/ELF LTO.cpp, lld/trunk/test/ELF/lto relocatable.ll

[ELF] - Make IR symbols be visible when doing relocatable link.

This is PR33097.
Previously when doing relocatable link, all IR symbols were absent
in result object file. Patch makes external symbols to be exported.

Differential revision: https://reviews.llvm.org/D36957

LLVM — lld/trunk/COFF DriverUtils.cpp

Fix a -Wpessimizing-move warning from Clang on this code --
a std::move() isn't needed here as the object is a temporary.
Delta File
+1 -1 lld/trunk/COFF/DriverUtils.cpp
+1 -1 1 file

LLVM — llvm/trunk/include/llvm/CodeGen SelectionDAGNodes.h, llvm/trunk/lib/CodeGen/SelectionDAG SelectionDAG.cpp

[X86] Prevent several calls to ISD::isConstantSplatVector from returning a narrower APInt 
than the original scalar type

ISD::isConstantSplatVector can shrink to the smallest splat width. But we don't check the 
size of the resulting APInt at all. This can cause us to misinterpret the results.

This patch just adds a flag to prevent the APInt from changing width.

Fixes PR34271.

Differential Revision: https://reviews.llvm.org/D36996

LLVM — cfe/trunk/cmake/modules ProtobufMutator.cmake

Update libprotobuf-mutator revision

LLVM — lld/trunk/COFF DriverUtils.cpp CMakeLists.txt, lld/trunk/test lit.cfg lit.site.cfg.in

Integrate manifest merging library into LLD.

Summary: Now that the llvm-mt manifest merging libraries are complete, we may use them to 
merge manifests instead of needing to shell out to mt.exe.

Subscribers: mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D36255

LLVM — cfe/trunk/lib/Driver/ToolChains Darwin.cpp

Test fix: only add shared libraries to rpath.

LLVM — llvm/trunk/test/tools/dsymutil/Inputs modules-empty, llvm/trunk/test/tools/dsymutil/Inputs/modules-empty 1.o Empty.pcm

dsymutil: don't copy compile units without children from PCM files

rdar://problem/33830532

LLVM — cfe/trunk/test/Driver fuzzer.c

Fixed driver tests for -fsanitize=fuzzer.
Delta File
+1 -1 cfe/trunk/test/Driver/fuzzer.c
+1 -1 1 file

LLVM — cfe/branches/release_50/include/clang/AST DeclCXX.h, cfe/branches/release_50/lib/AST DeclCXX.cpp ASTImporter.cpp

Merging r310983:
------------------------------------------------------------------------
r310983 | rsmith | 2017-08-15 18:49:53 -0700 (Tue, 15 Aug 2017) | 31 lines

PR19668, PR23034: Fix handling of move constructors and deleted copy
constructors when deciding whether classes should be passed indirectly.

This fixes ABI differences between Clang and GCC:

 * Previously, Clang ignored the move constructor when making this
   determination. It now takes the move constructor into account, per
   https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
   seem recent, but the ABI change was agreed on the Itanium C++ ABI
   list a long time ago).

 * Previously, Clang's behavior when the copy constructor was deleted
   was unstable -- depending on whether the lazy declaration of the
   copy constructor had been triggered, you might get different behavior.
   We now eagerly declare the copy constructor whenever its deletedness
   is unclear, and ignore deleted copy/move constructors when looking for
   a trivial such constructor.

This also fixes an ABI difference between Clang and MSVC:

 * If the copy constructor would be implicitly deleted (but has not been

    [11 lines not shown]

LLVM — llvm/branches/release_50/lib/CodeGen/SelectionDAG LegalizeVectorTypes.cpp LegalizeTypes.h, llvm/branches/release_50/test/CodeGen/X86 pr34177.ll

Merging r311071:
------------------------------------------------------------------------
r311071 | eladcohen | 2017-08-17 01:06:36 -0700 (Thu, 17 Aug 2017) | 13 lines

[SelectionDAG] Teach the vector-types operand scalarizer about SETCC

When v1i1 is legal (e.g. AVX512) the legalizer can reach
a case where a v1i1 SETCC with an illgeal vector type operand
wasn't scalarized (since v1i1 is legal) but its operands does
have to be scalarized. This used to assert because SETCC was
missing from the vector operand scalarizer.

This patch attemps to teach the legalizer to handle these cases
by scalazring the operands, converting the node into a scalar
SETCC node.

Differential revision: https://reviews.llvm.org/D36651
------------------------------------------------------------------------

LLVM — llvm/branches/release_50/lib/Object COFFModuleDefinition.cpp, llvm/branches/release_50/lib/ToolDrivers/llvm-dlltool DlltoolDriver.cpp Options.td

Merging r310990:
------------------------------------------------------------------------
r310990 | mstorsjo | 2017-08-15 22:18:36 -0700 (Tue, 15 Aug 2017) | 18 lines

[llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386

Hook up the -k option (that in the original GNU dlltool removes the
@n suffix from the symbol that the final executable ends up linked to).

In llvm-dlltool, make sure that functions end up with the undecorate
name type if this option is set and they are decorated. In mingw, when
creating import libraries from def files instead of creating an import
library as a side effect of linking a DLL, the symbol names in the def
contain the stdcall/fastcall decoration (but no leading underscore).

By setting the undecorate name type, a linker linking to the import
library will omit the decoration from the DLL import entry.

With this in place, mingw-w64 for i386 built with llvm-dlltool/clang
produces import libraries that actually work.

Differential Revision: https://reviews.llvm.org/D36548
------------------------------------------------------------------------

LLVM — cfe/trunk/lib/Driver/ToolChains Darwin.cpp CommonArgs.cpp, cfe/trunk/test/Driver fuzzer.c

Moving libFuzzer to compiler-rt: required updates to the Clang driver.

Differential Revision: https://reviews.llvm.org/D36909

LLVM — llvm/trunk/lib CMakeLists.txt, llvm/trunk/lib/Fuzzer CMakeLists.txt README.txt

Moving libFuzzer from LLVM to compiler-rt.

This change only removes libFuzzer tests and CMake machinery,
the source copy temporarily remains at the old location.

Differential Revision: https://reviews.llvm.org/D36980

LLVM — llvm/trunk/include/llvm/FuzzMutate OpDescriptor.h IRMutator.h, llvm/trunk/lib LLVMBuild.txt CMakeLists.txt

Re-apply "Introduce FuzzMutate library"

Same as r311392 with some fixes for library dependencies. Thanks to
Chapuni for helping work those out!

Original commit message:

This introduces the FuzzMutate library, which provides structured
fuzzing for LLVM IR, as described in my EuroLLVM 2017 talk. Most of
the basic mutators to inject and delete IR are provided, with support
for most basic operations.

LLVM — llvm/trunk/lib/CodeGen RegAllocBasic.cpp RegAllocGreedy.cpp

[RegAlloc] Make sure live-ranges reflect the state of the IR when removing them

When removing a live-range we used to not touch them making debug
prints harder to read because the IR was not matching what the
live-ranges information was saying.

This only affects debug printing and allows to put stronger asserts in
the code (see r308906 for instance).

LLVM — llvm/trunk/lib/Analysis ValueTracking.cpp

[ValueTracking] Add assertions that the starting Depth in isKnownToBeAPowerOfTwo and 
ComputeNumSignBitsImpl is not above MaxDepth

The function does an equality check later to terminate the recursion, but that won't work 
if its starts out too high. Similar assert already exists in computeKnownBits.

LLVM — lldb/trunk/tools/argdumper CMakeLists.txt

lldb-argdumper doesn't need lldbCore.

Summary: lldb-argdumper only needs lldbUtility to successfully build and link.

Reviewers: beanz, zturner, labath

Subscribers: mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D36948

LLVM — cfe/trunk/lib/Driver/ToolChains Darwin.cpp, cfe/trunk/test/Driver clang-translation.c

[Driver][Darwin] Do not pass -munwind-table if -fno-excpetions is
supplied.

With this change, -fno-exceptions disables unwind tables unless
-funwind-tables is supplied too or the target is x86-64 (x86-64 requires
emitting unwind tables).

rdar://problem/33934446

LLVM — llvm/trunk/test/Transforms/InstCombine udivrem-change-width.ll

[InstCombine] add udiv/urem tests with constant numerator; NFC

LLVM — llvm/trunk/include/llvm/FuzzMutate OpDescriptor.h IRMutator.h, llvm/trunk/lib CMakeLists.txt

Revert "Re-apply "Introduce FuzzMutate library""

The dependencies for the new library seem to be misconfigured on some
linux configs:

  http://bb.pgr.jp/builders/llvm-i686-linux-RA/builds/5435/steps/build_all/logs/stdio

This reverts r311392.

LLVM — llvm/trunk/include/llvm/FuzzMutate OpDescriptor.h IRMutator.h, llvm/trunk/lib CMakeLists.txt

Re-apply "Introduce FuzzMutate library"

Redo r311356 with a fix to avoid std::uniform_int_distribution<bool>.
The bool specialization is undefined according to the standard, even
though libc++ seems to have it.

Original commit message:

This introduces the FuzzMutate library, which provides structured
fuzzing for LLVM IR, as described in my [EuroLLVM 2017 talk][1]. Most
of the basic mutators to inject and delete IR are provided, with
support for most basic operations.

LLVM — cfe/trunk/lib/Driver/ToolChains MSVC.cpp MSVC.h

[Driver] Recognize DevDiv internal builds of MSVC, with a different directory structure.

This is a reasonably non-intrusive change, which I've verified
works for both x86 and x64 DevDiv-internal builds.

The idea is to change `bool IsVS2017OrNewer` into a 3-state
`ToolsetLayout VSLayout`. Either a build is DevDiv-internal,
released VS 2017 or newer, or released VS 2015 or older. When looking at
the directory structure, if instead of `"VC"` we see `"x86ret"`, `"x86chk"`,
`"amd64ret"`, or `"amd64chk"`, we recognize this as a DevDiv-internal build.

After we get past the directory structure validation, we use this knowledge
to regenerate paths appropriately. `llvmArchToDevDivInternalArch()` knows how
we use `"i386"` subdirectories, and `MSVCToolChain::getSubDirectoryPath()`
uses that. It also knows that DevDiv-internal builds have an `"inc"`
subdirectory instead of `"include"`.

This may still not be the "right" fix in any sense, but I believe that it's
non-intrusive in the sense that if the special directory names aren't found,
no codepaths are affected. (`ToolsetLayout::OlderVS` and
`ToolsetLayout::VS2017OrNewer` correspond to `IsVS2017OrNewer` being `false`
or `true`, respectively.) I searched for all references to `IsVS2017OrNewer`,
which are places where Clang cares about VS's directory structure, and the
only one that isn't being patched is some logic to deal with
cross-compilation. I'm fine with that not working for DevDiv-internal builds

    [3 lines not shown]

LLVM — llvm/trunk/test/Transforms/InstCombine udivrem-change-width.ll

[InstCombine] add more tests for udiv/urem narrowing; NFC

We don't currently limit these folds with hasOneUse() or shouldChangeType().

LLVM — llvm/trunk/test/CodeGen/AArch64 misched-fusion.ll

[AArch64] Restore the test of conditional branch fusion

Restore the functionality of this test that was broken by
https://reviews.llvm.org/rL306144.

Differential revision: https://reviews.llvm.org/D36807

LLVM — llvm/trunk/lib/Target/AArch64 AArch64CallLowering.cpp AArch64ISelLowering.h, llvm/trunk/test/CodeGen/AArch64/GlobalISel call-translator-ios.ll call-translator.ll

GlobalISel (AArch64): fix ABI at border between GPRs and SP.

If a struct would end up half in GPRs and half on SP the ABI says it should
actually go entirely on the stack. We were getting this wrong in GlobalISel
before, causing compatibility issues.

LLVM — llvm/trunk/lib/IR AutoUpgrade.cpp, llvm/trunk/test/Bitcode upgrade-module-flag.ll

[IR] AutoUpgrade ModuleFlagBehavior for PIC and PIE level

Summary:
From r303590, ModuleFlagBehavior for PIC and PIE level is changed from
Error to Max. This will cause bitcode compatibility issue when linking
against a bitcode static archive built with old compiler.
Add an auto-ugprade path to upgrade the the ModuleFlagBehavior in the
old bitcode to match the new one so IRLinker can link them.

Reviewers: tejohnson, mehdi_amini, dexonsmith

Reviewed By: dexonsmith

Subscribers: hans, llvm-commits

Differential Revision: https://reviews.llvm.org/D36556

LLVM — llvm/trunk/lib/Transforms/InstCombine InstCombineAndOrXor.cpp

[InstCombine] Move the checks for pointer types in getMaskedTypeForICmpPair earlier in the 
function

I don't think there's any reason to have them scattered about and on all 4 operands. We 
already have an early check that both compares must be the same type. And within a given 
compare the LHS and RHS must have the same type. Beyond that I don't think there's anyway 
this function returns anything valid for pointer types. So let's just return early and be 
done with it.

Differential Revision: https://reviews.llvm.org/D36561

LLVM — llvm/trunk/lib/Support/Windows Path.inc, llvm/trunk/unittests/Support Path.cpp

[Support, Windows] Handle long paths with unix separators

Summary:
The function widenPath() for Windows also normalizes long path names by
iterating over the path's components and calling append().  The
assumption during the iteration that separators are not returned by the
iterator doesn't hold because the iterators do return a separator when
the path has a drive name.  Handle this case by ignoring separators
during iteration.

Reviewers: rnk

Subscribers: danalbert, srhines

Differential Revision: https://reviews.llvm.org/D36752

LLVM — llvm/trunk/lib/Transforms/Scalar ADCE.cpp, llvm/trunk/test/Transforms/ADCE domtree-DoubleDeletion.ll unreachable.ll

Revert "Reapply: [ADCE][Dominators] Teach ADCE to preserve dominators"

Summary: This partially reverts commit r311057 since it breaks ADCE.  See PR34258.

Reviewers: kuhar

Subscribers: mcrosier, david2050, llvm-commits

Differential Revision: https://reviews.llvm.org/D36979

LLVM — llvm/trunk/include/llvm/Analysis OptimizationDiagnosticInfo.h, llvm/trunk/include/llvm/IR DiagnosticInfo.h

[ORE] Remove Old Optimization Remark API

Summary: https://bugs.llvm.org/show_bug.cgi?id=33789

Reviewers: anemet

Reviewed By: anemet

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D36972

LLVM — cfe/branches/release_50/lib/StaticAnalyzer/Core RegionStore.cpp, cfe/branches/release_50/test/Analysis ctor.mm

Merging r311182:
------------------------------------------------------------------------
r311182 | alexshap | 2017-08-18 11:20:43 -0700 (Fri, 18 Aug 2017) | 22 lines

[analyzer] Fix modeling of constructors

This diff fixes analyzer's crash (triggered assert) on the newly added test case.
The assert being discussed is assert(!B.lookup(R, BindingKey::Direct))
in lib/StaticAnalyzer/Core/RegionStore.cpp, however the root cause is different.
For classes with empty bases the offsets might be tricky.
For example, let's assume we have
 struct S: NonEmptyBase, EmptyBase {
     ...
 };
In this case Clang applies empty base class optimization and 
the offset of EmptyBase will be 0, it can be verified via
clang -cc1 -x c++ -v -fdump-record-layouts main.cpp -emit-llvm -o /dev/null.
When the analyzer tries to perform zero initialization of EmptyBase
it will hit the assert because that region
has already been "written" by the constructor of NonEmptyBase.

Test plan:
make check-all

Differential revision: https://reviews.llvm.org/D36851

    [2 lines not shown]

LLVM — lldb/branches/release_50/source/Core CMakeLists.txt, lldb/branches/release_50/source/Host CMakeLists.txt

Merging r311122, r311354 and r311355:
------------------------------------------------------------------------
r311122 | mgorny | 2017-08-17 13:33:21 -0700 (Thu, 17 Aug 2017) | 20 lines

[cmake] Add explicit linkage from Core to curses

The Core library calls functions provided by the curses library. Add
an appropriate explicit LINK_LIBS to ${CURSES_LIBRARIES} to propagate
the dependency correctly within the build system.

It seems that so far the linkage was handled by some kind of implicit
magic LLDB_SYSTEM_LIBS variable. However, it stopped working for
unittests as the curses libraries are passed before the LLDBCore
library, resulting in `-Wl,--as-needed` stripping the yet-unused library
before it is required by LLDBCore, and effectively breaking the build.
I think it's better to focus on listing all the dependencies explicitly
and let CMake propagate them rather than trying to figure out why this
hack stopped working.

This is also more consistent with LLVM where the curses linkage
in LLVMSupport is expressed directly in the library rather than deferred
to the final programs.

Differential Revision: https://reviews.llvm.org/D36358
------------------------------------------------------------------------

    [39 lines not shown]

LLVM — llvm/branches/release_50/lib/ExecutionEngine CMakeLists.txt

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()'
  

    [16 lines not shown]

LLVM — llvm/trunk/include/llvm/DebugInfo/CodeView SymbolSerializer.h, llvm/trunk/lib/DebugInfo/CodeView SymbolSerializer.cpp

[PDB] Serialize records into a stack-allocated buffer.

We were using a std::vector<> and resizing to MaxRecordLength,
which is ~64KB.  We would then do this repeatedly often many
times in a tight loop, which was causing measurable performance
impact when linking PDBs.

Patch by Alex Telishev
Differential Revision: https://reviews.llvm.org/D36940

LLVM — llvm/trunk/lib/Fuzzer CMakeLists.txt

Always compile libFuzzer with no coverage

Do not compile libFuzzer itself with coverage, regardless of LLVM variables

Differential Revision: https://reviews.llvm.org/D36887

LLVM — llvm/trunk/lib/DebugInfo/PDB/Native GSIStreamBuilder.cpp

[lld/pdb] Speed up construction of publics & globals addr map.

computeAddrMap function calls std::stable_sort with a comparison
function that computes deserialized symbols every time its called.
In the result deserializeAs<PublicSym32> is called 20-30 times per
symbol. It's much faster to calculate it beforehand and pass a
pointer to it to the comparison function.

Patch by Alex Telishev
Differential Revision: https://reviews.llvm.org/D36941

LLVM — llvm/branches/release_50/lib/Transforms/Utils CloneFunction.cpp, llvm/branches/release_50/test/Transforms/Inline recursive.ll

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. =]
------------------------------------------------------------------------

LLVM — llvm/trunk/include/llvm/Analysis InlineCost.h, llvm/trunk/lib/Analysis InlineCost.cpp

[InlineCost] Add cl::opt to allow full inline cost to be computed for debugging purposes.

Currently, the inline cost model will bail once the inline cost exceeds the
inline threshold in order to avoid unnecessary compile-time. However, when
debugging it is useful to compute the full cost, so this command line option
is added to override the default behavior.

I took over this work from Chad Rosier (mcrosier at codeaurora.org).

Differential Revision: https://reviews.llvm.org/D35850

LLVM — llvm/trunk/lib/Analysis InlineCost.cpp

[InlineCost] Add more debug during inline cost computation.

LLVM — llvm/branches/release_50/lib/Target/ARM ARMISelLowering.cpp, llvm/branches/release_50/test/CodeGen/ARM vzip.ll

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
------------------------------------------------------------------------

LLVM — llvm/trunk/include/llvm/Support BinaryStreamRef.h, llvm/trunk/lib/Support BinaryStreamRef.cpp

[BinaryStream] Defaultify copy and move constructors.

The various BinaryStream classes had explicit copy constructors
which resulted in deleted move constructors.  This was causing
the internal std::shared_ptr to get copied rather than moved
very frequently, since these classes are often used as return
values.

Patch by Alex Telishev
Differential Revision: https://reviews.llvm.org/D36942

LLVM — llvm/trunk/lib/Transforms/Utils SimplifyLibCalls.cpp, llvm/trunk/test/Transforms/InstCombine memcmp-constant-fold.ll

[LibCallSimplifier] try harder to fold memcmp with constant arguments (2nd try)

The 1st try was reverted because it could inf-loop by creating a dead instruction.
Fixed that to not happen and added a test case to verify.

Original commit message:

Try to fold:
memcmp(X, C, ConstantLength) == 0 --> load X == *C

Without this change, we're unnecessarily checking the alignment of the constant data,
so we miss the transform in the first 2 tests in the patch.

I noted this shortcoming of LibCallSimpifier in one of the recent CGP memcmp expansion
patches. This doesn't help the example in:
https://bugs.llvm.org/show_bug.cgi?id=34032#c13
...directly, but it's worth short-circuiting more of these simple cases since we're
already trying to do that.

The benefit of transforming to load+cmp is that existing IR analysis/transforms may
further simplify that code. For example, if the load of the variable is common to
multiple memcmp calls, CSE can remove the duplicate instructions.

Differential Revision: https://reviews.llvm.org/D36922

LLVM — cfe/trunk/lib/Driver/ToolChains NetBSD.cpp

Enable libfuzzer on NetBSD/amd64

Summary:
Enable SanitizerKind::Fuzzer and SanitizerKind::FuzzerNoLink on x86_64.

Sponsored by <The NetBSD Foundation>

Reviewers: joerg, kcc, vitalybuka, george.karpenkov

Reviewed By: vitalybuka

Subscribers: cfe-commits, #sanitizers

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D36935

LLVM — llvm/trunk/lib/Transforms/InstCombine InstCombineSelect.cpp, llvm/trunk/test/Transforms/InstCombine select-with-bitwise-ops.ll

[InstCombine] Teach foldSelectICmpAnd to recognize a (icmp slt X, 0) and (icmp sgt X, -1) 
as equivalent to an and with the sign bit of the truncated type

This is similar to what was already done in foldSelectICmpAndOr. Ultimately I'd like to 
see if we can call foldSelectICmpAnd from foldSelectIntoOp if we detect a power of 2 
constant. This would allow us to remove foldSelectICmpAndOr entirely.

Differential Revision: https://reviews.llvm.org/D36498

LLVM — cfe/branches/release_50/docs ReleaseNotes.rst

Update Clang 5.0 release notes for ms_abi and __builtin_ms_va_list for aarch64

Differential Revision: https://reviews.llvm.org/D36931

LLVM — llvm/trunk/include/llvm/FuzzMutate OpDescriptor.h IRMutator.h, llvm/trunk/lib CMakeLists.txt

Revert "Introduce FuzzMutate library"

Looks like this fails to build with libstdc++.

This reverts r311356

LLVM — cfe/branches/release_50/docs ReleaseNotes.rst

Mention some warning-related additions and changes for LLVM 5
release notes

LLVM — llvm/trunk/include/llvm FuzzMutate, llvm/trunk/include/llvm/FuzzMutate OpDescriptor.h IRMutator.h

Introduce FuzzMutate library

This introduces the FuzzMutate library, which provides structured
fuzzing for LLVM IR, as described in my [EuroLLVM 2017 talk][1]. Most
of the basic mutators to inject and delete IR are provided, with
support for most basic operations.

I will follow up with the instruction selection fuzzer, which is
implemented in terms of this library.

[1]: http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#2

LLVM — lldb/trunk/unittests CMakeLists.txt

[unittests] Build LLVMTestingSupport for out-of-source builds

The Process/gdb-remote test now requires the LLVMTestingSupport library
that is not installed by LLVM. As a result, when doing an out-of-source
build it fails being unable to find the library. To solve that, build
a local copy of the library when building LLDB with unittests and LLVM
sources available. This is based on how we deal with bundled gtest
sources.

Differential Revision: https://reviews.llvm.org/D36886