Summary:
A simple genetic in-process coverage-guided fuzz testing library.
I've used this fuzzer to test clang-format
(it found 12+ bugs, thanks djasper@ for the fixes!)
and it may also help us test other parts of LLVM.
So why not keep it in the LLVM repository?
I plan to add the cmake build rules later (in a separate patch, if that's ok)
and also add a clang-format-fuzzer target.
See README.txt for details.
Test Plan: Tests will follow separately.
Reviewers: djasper, chandlerc, rnk
Reviewed By: rnk
Subscribers: majnemer, ygribov, dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D7184
llvm-svn: 227252
Under certain circumstances, the identifier mentioned in the diagnostic
won't match the intended correction even though the replacement
expression and the note pointing to the decl are both correct.
Basically, the TreeTransform assumes the TypoExpr's Consumer points to
the correct TypoCorrection, but the handling of typos that appear to be
ambiguous from the point of view of TransformTypoExpr would cause that
assumption to be violated by altering the Consumer's correction stream.
This fix allows the Consumer's correction stream to be reset to the
right TypoCorrection after successfully resolving the percieved ambiguity.
Included is a fix to suppress correcting the RHS of an assignment to the
LHS of that assignment for non-C++ code, to prevent a regression in
test/SemaObjC/provisional-ivar-lookup.m.
This fixes PR22297.
llvm-svn: 227251
This was introduced in a faulty refactoring (r225640, mea culpa):
the tests weren't testing the return values, so, for both
__strcpy_chk and __stpcpy_chk, we would return the end of the
buffer (matching stpcpy) instead of the beginning (for strcpy).
The root cause was the prefix "__" being ignored when comparing,
which made us always pick LibFunc::stpcpy_chk.
Pass the LibFunc::Func directly to avoid this kind of error.
Also, make the testcases as explicit as possible to prevent this.
The now-useful testcases expose another, entangled, stpcpy problem,
with the further simplification. This was introduced in a
refactoring (r225640) to match the original behavior.
However, this leads to problems when successive simplifications
generate several similar instructions, none of which are removed
by the custom replaceAllUsesWith.
For instance, InstCombine (the main user) doesn't erase the
instruction in its custom RAUW. When trying to simplify say
__stpcpy_chk:
- first, an stpcpy is created (fortified simplifier),
- second, a memcpy is created (normal simplifier), but the
stpcpy call isn't removed.
- third, InstCombine later revisits the instructions,
and simplifies the first stpcpy to a memcpy. We now have
two memcpys.
llvm-svn: 227250
Splitting a loop to make range checks redundant is profitable only if
the range check "never" fails. Make this fact a part of recognizing a
range check -- a branch is a range check only if it is expected to
pass (via branch_weights metadata).
Differential Revision: http://reviews.llvm.org/D7192
llvm-svn: 227249
This patch resolves part of PR21711 ( http://llvm.org/bugs/show_bug.cgi?id=21711 ).
The 'f3' test case in that report presents a situation where we have two 128-bit
stores extracted from a 256-bit source vector.
Instead of producing this:
vmovaps %xmm0, (%rdi)
vextractf128 $1, %ymm0, 16(%rdi)
This patch merges the 128-bit stores into a single 256-bit store:
vmovups %ymm0, (%rdi)
Differential Revision: http://reviews.llvm.org/D7208
llvm-svn: 227242
llvm-pdbdump is a tool which can be used to dump the contents
of Microsoft-generated PDB files. It makes use of the Microsoft
DIA SDK, which is a COM based library designed specifically for
this purpose.
The initial commit of this tool dumps the raw bytes from PDB data
streams. Future commits will dump more semantic information such
as types, symbols, source files, etc similar to the types of
information accessible via llvm-dwarfdump.
Reviewed by: Aaron Ballman, Reid Kleckner, Chandler Carruth
Differential Revision: http://reviews.llvm.org/D7153
llvm-svn: 227241
If a memory access is unaligned, emit __tsan_unaligned_read/write
callbacks instead of __tsan_read/write.
Required to change semantics of __tsan_unaligned_read/write to not do the user memory.
But since they were unused (other than through __sanitizer_unaligned_load/store) this is fine.
Fixes long standing issue 17:
https://code.google.com/p/thread-sanitizer/issues/detail?id=17
llvm-svn: 227231
If a memory access is unaligned, emit __tsan_unaligned_read/write
callbacks instead of __tsan_read/write.
Required to change semantics of __tsan_unaligned_read/write to not do the user memory.
But since they were unused (other than through __sanitizer_unaligned_load/store) this is fine.
Fixes long standing issue 17:
https://code.google.com/p/thread-sanitizer/issues/detail?id=17
llvm-svn: 227230
No other test I know shows how struct names are mangled in overloaded
intrinsic functions.
Differential Revision: http://reviews.llvm.org/D7037
llvm-svn: 227229
Support weak symbols by first looking up if there is an externally visible symbol we can find,
and only if that fails using the one in the object file we're loading.
Reviewed By: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6950
llvm-svn: 227228
Summary:
Basically all other methods that look up functions by name skip them if they are mere declarations.
Do the same in FindFunctionNamed.
Reviewers: lhames
Reviewed By: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7068
llvm-svn: 227227
he following snippet doesn't build when using gcc and libc++:
#include <string>
void f(const std::string& s) { s.begin(); }
#include <vector>
void AppendTo(const std::vector<char>& v) { v.begin(); }
The problem is that __wrap_iter has a private constructor. It lists vector<>
and basic_string<> as friends, but gcc seems to ignore this for vector<> for
some reason. Declaring vector before the friend declaration in __wrap_iter is
enough to work around this problem, so do that. With this patch, I'm able to
build chromium/android with libc++. Without it, two translation units fail to
build. (iosfwd already provides a forward declaration of basic_string.)
As far as I can tell, this is due to a gcc bug, which I filed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816.
Fixes PR22355.
http://reviews.llvm.org/D7201
llvm-svn: 227226
In particular, remove the OpaqueExpr transformation from r225389 and
move the correction of the conditional from CheckConditionalOperands to
ActOnConditionalOp before the OpaqueExpr is created. This fixes the
typo correction behavior in C code that uses the GNU extension for a
binary ?: (without an expression between the "?" and the ":").
llvm-svn: 227220
This patch adds lldbmi_testcase.MiTestCaseBase class and removes
a lot of repitition in the lldb-mi test cases. Also cleans import
list and code-style.
Presented for review in http://reviews.llvm.org/D7162.
Patch from Ilia K <ki.stfu@gmail.com>.
llvm-svn: 227218
it does call, and implementing it so that we once again look up external symbols in the JIT.
Also juked the error reporting from the JIT a little bit.
This resolves:
http://llvm.org/bugs/show_bug.cgi?id=22314
llvm-svn: 227217
Summary:
When LLVM_USE_SANITIZE_COVERAGE=YES
and one of the sanitizers is used -fsanitize-coverage=3 will be added
to build flag. This will be used to run a coverage-guided fuzzer on various
llvm libraries.
Test Plan: n/a
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7116
llvm-svn: 227216
Only pseudos have patterns on them.
Also don't set the asm string for VINTRP_Pseudo. All pseudos should have empty
asm.
This matches what all other multiclasses do.
llvm-svn: 227212
This defines the SI versions only, so it shouldn't change anything.
There are no changes other than using the new multiclasses, adding missing
mayLoad/mayStore, and formatting fixes.
llvm-svn: 227208
These functions are already present in the cc_kext for arm32 and for x86 and
x86_64. It was an oversight that they were not included for arm64.
Based on a patch by Lawrence D'Anna. Thanks!
llvm-svn: 227206
Kostya Serebryany