[PATCH] D36635: Add a Dockerfile for clang-proto-fuzzer

morehouse added inline comments. Comment at: tools/clang-fuzzer/Dockerfile:22 +# Get LLVM +RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm +RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk clang -r $(cd ../ && svn info | grep Revision | awk

[PATCH] D28953: [analyzer] Eliminate analyzer limitations on symbolic constraint generation

morehouse added a comment. r307833 is causing the sanitizer-x86_64-linux-fast buildbot to fail during clang regression tests with the following error: clang:

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse added inline comments. Comment at: clang/cmake/modules/ProtobufMutator.cmake:13 +-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER} +-DCMAKE_BUILD_TYPE=Debug + BUILD_COMMAND ${CMAKE_MAKE_PROGRAM} vitalybuka wrote: > Why this is debug? > I was just

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/ClangFuzzer.cpp:20 extern "C" int LLVMFuzzerTestOneInput(uint8_t *data, size_t size) { std::string s((const char *)data, size); morehouse wrote: > vitalybuka wrote: > > Do we want

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse updated this revision to Diff 110222. morehouse added a comment. - Define GOOGLE_PROTOBUF_NO_RTTI to remove RTTI requirement. https://reviews.llvm.org/D36324 Files: clang/CMakeLists.txt clang/cmake/modules/ProtobufMutator.cmake clang/tools/clang-fuzzer/CMakeLists.txt

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse updated this revision to Diff 110265. morehouse added a comment. - README tweaks. https://reviews.llvm.org/D36324 Files: clang/CMakeLists.txt clang/cmake/modules/ProtobufMutator.cmake clang/tools/clang-fuzzer/CMakeLists.txt clang/tools/clang-fuzzer/ClangFuzzer.cpp

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

This revision was automatically updated to reflect the committed changes. Closed by commit rL310408: Integrate Kostya's clang-proto-fuzzer with LLVM. (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D36324?vs=110265=110269#toc Repository: rL LLVM

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse updated this revision to Diff 110262. morehouse added a comment. - Add README.txt. https://reviews.llvm.org/D36324 Files: clang/CMakeLists.txt clang/cmake/modules/ProtobufMutator.cmake clang/tools/clang-fuzzer/CMakeLists.txt clang/tools/clang-fuzzer/ClangFuzzer.cpp

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse updated this revision to Diff 110264. morehouse added a comment. - Add run instructions to README. https://reviews.llvm.org/D36324 Files: clang/CMakeLists.txt clang/cmake/modules/ProtobufMutator.cmake clang/tools/clang-fuzzer/CMakeLists.txt

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse updated this revision to Diff 110111. morehouse added a comment. - Build protobuf-mutator with same build type as current build. - Remove unnecessary options from clang-proto-fuzzer. - Expand macro. https://reviews.llvm.org/D36324 Files: clang/CMakeLists.txt

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse added a comment. In https://reviews.llvm.org/D36324#834660, @kcc wrote: > Why do we need LLVM_ENABLE_RTTI=ON here? Attempting to build without it yields all kinds of protobuf errors. For example: F4944099: image.png

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse updated this revision to Diff 110215. morehouse added a comment. - Formatting and code cleanup. https://reviews.llvm.org/D36324 Files: clang/CMakeLists.txt clang/cmake/modules/ProtobufMutator.cmake clang/tools/clang-fuzzer/CMakeLists.txt

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

morehouse created this revision. Herald added a subscriber: mgorny. The clang-proto-fuzzer models a subset of C++ as a protobuf and uses libprotobuf-mutator to generate interesting mutations of C++ programs. Clang-proto-fuzzer has already found several bugs in Clang (e.g.,

[PATCH] D36882: [clang-proto-fuzzer] Allow user-specified compiler arguments.

morehouse created this revision. Herald added subscribers: kristof.beyls, aemerson. Arguments can be specified after -ignore_remaining_args=1 to modify the compiler invocation. For example, the following command-line will fuzz LLVM with a custom optimization level and target triple:

[PATCH] D36882: [clang-proto-fuzzer] Allow user-specified compiler arguments.

This revision was automatically updated to reflect the committed changes. Closed by commit rL311185: [clang-proto-fuzzer] Allow user-specified compiler arguments. (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D36882?vs=111713=111715#toc Repository: rL LLVM

[PATCH] D36839: [SanitizerCoverage] Add stack depth tracing instrumentation.

This revision was automatically updated to reflect the committed changes. Closed by commit rL311186: [SanitizerCoverage] Add stack depth tracing instrumentation. (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D36839?vs=111570=111718#toc Repository: rL LLVM

[PATCH] D36882: [clang-proto-fuzzer] Allow user-specified compiler arguments.

morehouse updated this revision to Diff 111713. morehouse added a comment. - Refactor and use strcmp. https://reviews.llvm.org/D36882 Files: clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp Index: clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp

[PATCH] D36839: [SanitizerCoverage] Add stack depth tracing instrumentation.

morehouse added inline comments. Comment at: llvm/lib/Fuzzer/FuzzerTracePC.cpp:31 ATTRIBUTE_INTERFACE uintptr_t __sancov_trace_pc_pcs[fuzzer::TracePC::kNumPCs]; vitalybuka wrote: > Why this does not need ATTRIBUTE_INTERFACE? Not sure why it works without it.

[PATCH] D36839: [SanitizerCoverage] Add stack depth tracing instrumentation.

morehouse updated this revision to Diff 111570. morehouse added a comment. - Extract shared condition. - Add ATTRIBUTE_INTERFACE. - Rename variable to __sancov_lowest_stack. - Add driver test for -fsanitize-coverage=stack-depth. https://reviews.llvm.org/D36839 Files:

[PATCH] D38063: [MSan] Disable sanitization for __sanitizer_dtor_callback.

morehouse created this revision. Herald added a subscriber: hiraditya. Eliminate unnecessary instrumentation at __sanitizer_dtor_callback call sites. Fixes https://github.com/google/sanitizers/issues/861. https://reviews.llvm.org/D38063 Files: clang/lib/CodeGen/CGClass.cpp

[PATCH] D38063: [MSan] Disable sanitization for __sanitizer_dtor_callback.

morehouse updated this revision to Diff 116072. morehouse added a comment. - Add test case. - Use SanitizerScope. https://reviews.llvm.org/D38063 Files: clang/lib/CodeGen/CGClass.cpp clang/test/CodeGenCXX/sanitize-dtor-callback.cpp llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp

[PATCH] D38063: [MSan] Disable sanitization for __sanitizer_dtor_callback.

morehouse updated this revision to Diff 116100. morehouse added a comment. - Add LLVM test. https://reviews.llvm.org/D38063 Files: clang/lib/CodeGen/CGClass.cpp clang/test/CodeGenCXX/sanitize-dtor-callback.cpp llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp

[PATCH] D38063: [MSan] Disable sanitization for __sanitizer_dtor_callback.

This revision was automatically updated to reflect the committed changes. Closed by commit rL313831: [MSan] Disable sanitization for __sanitizer_dtor_callback. (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D38063?vs=116100=116103#toc Repository: rL LLVM

[PATCH] D37860: [MSan] Enable use-after-dtor instrumentation by default.

morehouse added inline comments. Comment at: clang/include/clang/Driver/Options.td:854 HelpText<"Enable use-after-destroy detection in MemorySanitizer">; +def fno_sanitize_memory_use_after_dtor : Flag<["-"],

[PATCH] D37860: [MSan] Enable use-after-dtor instrumentation by default.

morehouse created this revision. Enable the compile-time flag -fsanitize-memory-use-after-dtor by default. Note that the run-time option MSAN_OPTIONS=poison_in_dtor=1 still needs to be enabled for destructors to be poisoned. https://reviews.llvm.org/D37860 Files:

[PATCH] D37867: [MSan] Add flag to disable use-after-dtor.

morehouse created this revision. Flag is -fno-sanitize-use-after-dtor. https://reviews.llvm.org/D37867 Files: clang/include/clang/Driver/Options.td clang/lib/Driver/SanitizerArgs.cpp clang/lib/Frontend/CompilerInvocation.cpp clang/test/Driver/fsanitize.c Index:

[PATCH] D37867: [MSan] Add flag to disable use-after-dtor.

morehouse updated this revision to Diff 115295. morehouse added a comment. - Use hasFlag() in CompilerInvocation.cpp as well. https://reviews.llvm.org/D37867 Files: clang/include/clang/Driver/Options.td clang/lib/Driver/SanitizerArgs.cpp clang/lib/Frontend/CompilerInvocation.cpp

[PATCH] D37860: [MSan] Enable use-after-dtor instrumentation by default.

morehouse updated this revision to Diff 115312. morehouse edited the summary of this revision. morehouse added a comment. - Move the new flag to https://reviews.llvm.org/D37867 - Address Vitaly's comments. https://reviews.llvm.org/D37860 Files: clang/lib/Driver/SanitizerArgs.cpp

[PATCH] D37860: [MSan] Enable use-after-dtor instrumentation by default.

morehouse added a comment. In https://reviews.llvm.org/D37860#871368, @eugenis wrote: > Looking at __sanitizer_dtor_callback implementation, this change will add a > (fast) stack unwind in every destructor. In extreme cases (like a tight loop > doing string operations) it could be bad for

[PATCH] D37867: [MSan] Add flag to disable use-after-dtor.

This revision was automatically updated to reflect the committed changes. Closed by commit rL313314: [MSan] Add flag to disable use-after-dtor. (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D37867?vs=115295=115317#toc Repository: rL LLVM

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

morehouse created this revision. Herald added a subscriber: mgorny. Build with DummyClangFuzzer.cpp as entry point when coverage instrumentation isn't present. https://reviews.llvm.org/D38642 Files: clang/tools/clang-fuzzer/CMakeLists.txt clang/tools/clang-fuzzer/ClangFuzzer.cpp

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

morehouse added a comment. In https://reviews.llvm.org/D38642#891074, @kcc wrote: > If you can *easily* share main() with the one in LLVM -- do it, otherwise > don't bother. Does the fuzzer main come from LLVM or compiler-rt now? There's still FuzzerMain.cpp, but I'm not sure if we should

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

morehouse added a comment. In https://reviews.llvm.org/D38642#890969, @kcc wrote: > I'd like to know more. > At least simple cases work fine: You're right. I was trying to add `-fsanitize=fuzzer` to `CMAKE_CXX_FLAGS` right before the link command, which was causing a later compilation to

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

morehouse updated this revision to Diff 118087. morehouse added a comment. - Remove dummy main and link with -fsantize=fuzzer. https://reviews.llvm.org/D38642 Files: clang/tools/clang-fuzzer/CMakeLists.txt clang/tools/clang-fuzzer/proto-to-cxx/CMakeLists.txt Index:

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

morehouse added a comment. In https://reviews.llvm.org/D38642#890963, @kcc wrote: > It's not about coverage instrumentation (not) being present, but about > libFuzzer's main() being present, right? Yes. > Will we be able to reuse some of Justin's code instead of creating one more > main()

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

morehouse updated this revision to Diff 118097. morehouse added a comment. - Revert "Remove dummy main and link with -fsantize=fuzzer." https://reviews.llvm.org/D38642 Files: clang/tools/clang-fuzzer/CMakeLists.txt clang/tools/clang-fuzzer/ClangFuzzer.cpp

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

This revision was automatically updated to reflect the committed changes. Closed by commit rL315336: [clang-fuzzer] Allow building without coverage instrumentation. (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D38642?vs=118097=118420#toc Repository: rL LLVM

[PATCH] D38853: [clang-format] Allow building fuzzer with OSS-Fuzz flags.

morehouse created this revision. Herald added a subscriber: mgorny. https://reviews.llvm.org/D38853 Files: clang/tools/clang-format/CMakeLists.txt clang/tools/clang-format/fuzzer/CMakeLists.txt Index: clang/tools/clang-format/fuzzer/CMakeLists.txt

[PATCH] D38853: [clang-format] Allow building fuzzer with OSS-Fuzz flags.

This revision was automatically updated to reflect the committed changes. Closed by commit rL315603: [clang-format] Allow building fuzzer with OSS-Fuzz flags. (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D38853?vs=118805=118819#toc Repository: rL LLVM

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse updated this revision to Diff 113133. morehouse added a comment. - Eliminate "#if". - Replace uintptr_t with uptr. https://reviews.llvm.org/D37156 Files: clang/lib/Driver/SanitizerArgs.cpp compiler-rt/lib/sanitizer_common/sanitizer_coverage_libcdep_new.cc

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse updated this revision to Diff 113129. morehouse added a comment. - Disable stack depth tracking on Mac. https://reviews.llvm.org/D37156 Files: clang/lib/Driver/SanitizerArgs.cpp compiler-rt/lib/sanitizer_common/sanitizer_coverage_libcdep_new.cc

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

This revision was automatically updated to reflect the committed changes. Closed by commit rL312026: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D37156?vs=113133=113136#toc Repository: rL

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

This revision was automatically updated to reflect the committed changes. Closed by commit rL312185: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D37156?vs=113177=113329#toc Repository: rL

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

This revision was automatically updated to reflect the committed changes. Closed by commit rL311801: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D37156?vs=112739=112746#toc Repository: rL

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse updated this revision to Diff 112759. morehouse added a comment. Full diff. https://reviews.llvm.org/D37156 Files: clang/lib/Driver/SanitizerArgs.cpp compiler-rt/test/fuzzer/deep-recursion.test llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse updated this revision to Diff 112739. morehouse added a comment. - Use existing linear scan, and check for InvokeInst. https://reviews.llvm.org/D37156 Files: clang/lib/Driver/SanitizerArgs.cpp compiler-rt/test/fuzzer/deep-recursion.test

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse added a comment. In https://reviews.llvm.org/D37156#852780, @kcc wrote: > Did you check this on something other than the unit tests? > E.g. a couple of benchmarks from fuzzer-test-suite? Just tested on the proj4 and lcms benchmarks and no issues came up.

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse reopened this revision. morehouse added a comment. This revision is now accepted and ready to land. Turns out I should have been testing the benchmarks with `FUZZING_ENGINE=fsanitize_fuzzer`. My mistake. After adding the weak reference to SanitizerCoverage.cpp, both lcms and proj4

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse updated this revision to Diff 112756. morehouse added a comment. - Add weak reference in SanitizerCoverage.cpp https://reviews.llvm.org/D37156 Files: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse updated this revision to Diff 112923. morehouse added a comment. Herald added a subscriber: kubamracek. - Add weak definition of __sancov_lowest_stack to runtime. https://reviews.llvm.org/D37156 Files: clang/lib/Driver/SanitizerArgs.cpp

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse created this revision. Herald added a subscriber: hiraditya. - Don't sanitize __sancov_lowest_stack. - Don't instrument leaf functions. - Add CoverageStackDepth to Fuzzer and FuzzerNoLink. https://reviews.llvm.org/D37156 Files: clang/lib/Driver/SanitizerArgs.cpp

[PATCH] D36839: [SanitizerCoverage] Add stack depth tracing instrumentation.

morehouse created this revision. Herald added subscribers: hiraditya, kubamracek. Augment SanitizerCoverage to insert maximum stack depth tracing for use by libFuzzer. The new instrumentation is enabled by the flag -fsanitize-coverage=stack-depth and is compatible with the existing

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

morehouse updated this revision to Diff 113177. morehouse added a comment. - Only enable stack depth tracking on Linux. - Ignore __sancov_lowest_stack in interface symbols tests. https://reviews.llvm.org/D37156 Files: clang/lib/Driver/SanitizerArgs.cpp

[PATCH] D38812: [clang-fuzzer] Allow linking with any fuzzing engine.

morehouse created this revision. Herald added a subscriber: mgorny. Makes clang-[proto-]fuzzer compatible with flags specified by OSS-Fuzz. https://llvm.org/pr34314 https://reviews.llvm.org/D38812 Files: clang/tools/clang-fuzzer/CMakeLists.txt Index:

[PATCH] D38812: [clang-fuzzer] Allow linking with any fuzzing engine.

This revision was automatically updated to reflect the committed changes. Closed by commit rL315486: [clang-fuzzer] Allow linking with any fuzzing engine. (authored by morehouse). Changed prior to commit: https://reviews.llvm.org/D38812?vs=118651=118655#toc Repository: rL LLVM

[PATCH] D37860: [MSan] Enable use-after-dtor instrumentation by default.

morehouse added a comment. Patch is out-of-date. But the flag has been enabled internally for over a month with no issues. I'll update this patch soon, so we can flip the default here. https://reviews.llvm.org/D37860 ___ cfe-commits mailing

[PATCH] D39445: [clang-fuzzer] Fix incremental builds of the fuzzer

morehouse accepted this revision. morehouse added a comment. This revision is now accepted and ready to land. LGTM. https://reviews.llvm.org/D39445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D48106: implemented proto to llvm

morehouse requested changes to this revision. morehouse added inline comments. This revision now requires changes to proceed. Comment at: tools/clang-fuzzer/CMakeLists.txt:72 + # Build the lllvm protobuf fuzzer + add_clang_executable(clang-llvm-proto-fuzzer

[PATCH] D48106: implemented proto to llvm

morehouse added a comment. Where is the fuzz target? Comment at: tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp:33 +int ptr_ctr = 0; +int val_ctr = 0; + I'd suggest wrapper functions that return unused variable names, so your code below won't need to

[PATCH] D48106: implemented proto to llvm

morehouse added a comment. In https://reviews.llvm.org/D48106#1131625, @emmettneyman wrote: > I wanted to implement the proto_to_llvm converter before the fuzz target. The fuzz target should make testing your converter way easier. I'd recommend adding it to this patch so that you're less

[PATCH] D47964: Modified protobuf and converter to add new signature, remove conditionals.

This revision was automatically updated to reflect the committed changes. Closed by commit rL334421: [clang-fuzzer] Modified protobuf and converter to add new signature, remove… (authored by morehouse, committed by ). Repository: rL LLVM https://reviews.llvm.org/D47964 Files:

[PATCH] D47964: Modified protobuf and converter to add new signature, remove conditionals.

morehouse added inline comments. Comment at: tools/clang-fuzzer/cxx_loop_proto.proto:67 -AssignmentStatement assignment = 1; -IfElse ifelse = 2; - } Do you really want to get rid of if-else? Comment at:

[PATCH] D47920: Made loop_proto more "vectorizable"

morehouse accepted this revision. morehouse added a comment. This revision is now accepted and ready to land. Looks like a good start. Repository: rC Clang https://reviews.llvm.org/D47920 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D47920: Made loop_proto more "vectorizable"

This revision was automatically updated to reflect the committed changes. Closed by commit rC334252: [clang-fuzzer] Made loop_proto more vectorizable. (authored by morehouse, committed by ). Changed prior to commit: https://reviews.llvm.org/D47920?vs=150435=150436#toc Repository: rC Clang

[PATCH] D48106: implemented proto to llvm

morehouse added inline comments. Comment at: tools/clang-fuzzer/handle-llvm/CMakeLists.txt:5 + handle_llvm.cpp + ) emmettneyman wrote: > morehouse wrote: > > There's fewer libraries linked here than in `handle-cxx/` (not saying this > > is wrong, but it could

[PATCH] D48106: implemented proto to llvm

morehouse added a comment. If you haven't already, please apply for commit access: https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access. That way you can land this after it's accepted. Comment at: tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:23 +#include

[PATCH] D48106: implemented proto to llvm

morehouse accepted this revision. morehouse added inline comments. This revision is now accepted and ready to land. Comment at: tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:50 + errs() << "error: opt level must be between 0 and 3.\n"; + std::exit(0); + }

[PATCH] D48106: implemented proto to llvm

morehouse added a comment. Looks like `exit(0)` is still there. Repository: rC Clang https://reviews.llvm.org/D48106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

morehouse added inline comments. Comment at: tools/clang-fuzzer/CMakeLists.txt:48 ExampleClangProtoFuzzer.cpp +FuzzerInitialize.cpp ) Rather than compiling `FuzzerInitialize.cpp` into the binary, can we make it a library like `handle-cxx` or

[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

morehouse added inline comments. Comment at: tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp:23 #include I think `cstring` is no longer used after this change. So we can probably remove this include. Comment at:

[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

morehouse accepted this revision. morehouse added a comment. LGTM. Repository: rC Clang https://reviews.llvm.org/D47666 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

This revision was automatically updated to reflect the committed changes. Closed by commit rL333969: [clang-proto-fuzzer] Refactored LLVMFuzzerInitialize into its own file. (authored by morehouse, committed by ). Changed prior to commit: https://reviews.llvm.org/D47666?vs=149872=149876#toc

[PATCH] D47843: Introducing single for loop into clang_proto_fuzzer

morehouse added a comment. This contains changes from previous patch. Please rebase. Repository: rC Clang https://reviews.llvm.org/D47843 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D47843: Introducing single for loop into clang_proto_fuzzer

morehouse added inline comments. Comment at: tools/clang-fuzzer/cxx_loop_proto.proto:93 + +message Function { + required StatementSeq statements = 1; Maybe call this `LoopFunction` to distinguish from the other protobuf. Comment at:

[PATCH] D47843: Introducing single for loop into clang_proto_fuzzer

morehouse added inline comments. Comment at: tools/clang-fuzzer/CMakeLists.txt:28 protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS cxx_proto.proto) + protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS cxx_loop_proto.proto) set(LLVM_OPTIONAL_SOURCES ${LLVM_OPTIONAL_SOURCES}

[PATCH] D37860: [MSan] Enable use-after-dtor instrumentation by default.

This revision was automatically updated to reflect the committed changes. Closed by commit rCRT31: [MSan] Enable use-after-dtor instrumentation by default. (authored by morehouse, committed by ). Herald added a subscriber: Sanitizers. Changed prior to commit:

[PATCH] D37860: [MSan] Enable use-after-dtor instrumentation by default.

morehouse added a comment. PTAL. Patch has been updated. https://reviews.llvm.org/D37860 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37860: [MSan] Enable use-after-dtor instrumentation by default.

morehouse updated this revision to Diff 129318. morehouse added a comment. - Enable use-after-dtor instrumentation by default. - Make sanitize-no-dtor-callback.cpp test fail with UAD instrumentation. - Update test cases to reflect new default. https://reviews.llvm.org/D37860 Files:

[PATCH] D43423: [SimplifyCFG] Create flag to disable simplifyCFG.

morehouse created this revision. morehouse added a reviewer: kcc. Herald added a subscriber: hiraditya. When building with libFuzzer, simplifyCFG reduces the coverage signal available to libFuzzer when trying to find new inputs. This patch provides a way to disable simplifyCFG when building with

[PATCH] D43423: [SimplifyCFG] Create flag to disable simplifyCFG.

morehouse added a comment. In https://reviews.llvm.org/D43423#1011170, @davide wrote: > Some high level comments: > > 1. This is something that GCC does relatively frequently (adding frontend > options to control optimization passes), but LLVM tends to not expose these > details. FWIW, I'd

[PATCH] D50194: LLVM Proto Fuzzer - Run Functions on Suite of Inputs

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:173 + int s = getSize((char *) func_ptr); + memcpy(mem, func_ptr, s); +} emmettneyman wrote: > morehouse wrote: > > Why do we need to copy the function somewhere

[PATCH] D50194: LLVM Proto Fuzzer - Run Functions on Suite of Inputs

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:173 + int s = getSize((char *) func_ptr); + memcpy(mem, func_ptr, s); +} Why do we need to copy the function somewhere else? Looks very error-prone and

[PATCH] D49526: Updated llvm-proto-fuzzer to execute the compiled code

morehouse added a comment. Do we need to parse the arguments for opt-level, or can we just hardcode `-O2` and remove the argument parsing code? Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:144 + Context); + Module

[PATCH] D49526: Updated llvm-proto-fuzzer to execute the compiled code

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:115 + make_unique(M.get()); + FPasses->add(createTargetTransformInfoWrapperPass(TargetIRAnalysis())); + emmettneyman wrote: > morehouse wrote: > > morehouse

[PATCH] D49526: Updated llvm-proto-fuzzer to execute the compiled code

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:125 + Context); + Module *M = Owner.get(); + if (!M) We should be able to get rid of this line now, and rename Owner

[PATCH] D49526: Updated llvm-proto-fuzzer to execute the compiled code

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:152 + typedef void (*func)(int*, int*, int*, int); + func f = (func) EE->getPointerToFunction(EntryFunc); + Can we use `reinterpret_cast` here? Repository:

[PATCH] D50194: LLVM Proto Fuzzer - Run Functions on Suite of Inputs

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:75 +// Helper function to print error message and stop the fuzzer void ErrorAndExit(std::string message) { Unnecessary comment. The naming and implementation

[PATCH] D50194: LLVM Proto Fuzzer - Run Functions on Suite of Inputs

morehouse added a comment. In https://reviews.llvm.org/D50194#1187756, @emmettneyman wrote: > An unrelated question: > Right now I have a mix of `static` and non-`static` functions in > `handle_llvm.cpp`. Should they all be `static`? Any functions that are only used in the same file can and

[PATCH] D50482: Added another optimization pass to make vectorizing possible

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:90 +getCodeModel(), OLvl); +} + If you have to pass that many parameters to a 3 line function, just inline instead.

[PATCH] D50482: Added another optimization pass to make vectorizing possible

morehouse accepted this revision. morehouse added inline comments. This revision is now accepted and ready to land. Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:103 + Triple ModuleTriple(M->getTargetTriple()); + const TargetOptions Options =

[PATCH] D50342: Changed how LLVM IR was generated to increase vectorization

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp:129 +<< "br i1 %5, label %6, label %8\n" +<< "; :6:\n" +<< "br label %9\n" emmettneyman wrote: > morehouse wrote: > >

[PATCH] D50342: Changed how LLVM IR was generated to increase vectorization

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp:127 +<< "define void @foo(i32* %a, i32* %b, i32* %c, i64 %s) {\n" +<< "%1 = icmp sgt i64 %s, 0\n" +<< "br i1 %1, label %start, label

[PATCH] D50194: LLVM Proto Fuzzer - Run Functions on Suite of Inputs

morehouse accepted this revision. morehouse added inline comments. This revision is now accepted and ready to land. Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:132 +// Takes a string of IR and compiles it using LLVM's JIT Engine +static void

[PATCH] D50670: Implementation of nested loops in cxx_loop_proto

morehouse added a comment. Does this hit new coverage in the vectorizer? Comment at: clang/tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp:46 std::string VarRefToString(std::ostream , const VarRef ) { + std::string var = inner_loop ? "inner" : "outer"; std::string

[PATCH] D50670: Implementation of nested loops in cxx_loop_proto

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/proto-to-cxx/loop_proto_to_cxx.cpp:124 +void SingleLoopToString(std::ostream , const LoopFunction ) { + inner_loop = false; + os << "void foo(int *a, int *b, int *__restrict__ c, size_t s) {\n"

[PATCH] D50670: Implementation of nested loops in cxx_loop_proto

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp:127 } + inner_loop = true; return os; emmettneyman wrote: > morehouse wrote: > > Maybe this fixes the bug, but modifying `inner_loop` from different

[PATCH] D50670: Implementation of nested loops in cxx_loop_proto

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/proto-to-llvm/loop_proto_to_llvm.cpp:127 } + inner_loop = true; return os; Maybe this fixes the bug, but modifying `inner_loop` from different functions is still error-prone. Please

[PATCH] D50829: Update README and Dockerfile to include llvm-proto-fuzzer

morehouse added inline comments. Comment at: clang/tools/clang-fuzzer/README.txt:104 +To translate a cxx_loop_proto file into LLVM IR do: + bin/clang-loop-proto-to-llvm +To translate a cxx_loop_proto file into C++ do: `bin/clang-loop-proto-to-llvm

[PATCH] D50670: Implementation of multiple loops in cxx_loop_proto

morehouse added a comment. Does having multiple loops one after another change any coverage in the vectorizer? Repository: rC Clang https://reviews.llvm.org/D50670 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D50670: Implementation of multiple loops in cxx_loop_proto

morehouse added a comment. In https://reviews.llvm.org/D50670#1199556, @emmettneyman wrote: > Should I switch my focus to nested loops instead? I think nested loops will > increase coverage. Yes, I'd recommend doing that. Repository: rC Clang https://reviews.llvm.org/D50670

  1   2   3   >