summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r319069 - [cmake] Pass -Wl,-z,nodelete on Linux to prevent unloadingMichal Gorny2017-11-271-8/+0
| | | | | | This breaks one of the unit tests. Need to find a good solution. llvm-svn: 319076
* [cmake] Pass -Wl,-z,nodelete on Linux to prevent unloadingMichal Gorny2017-11-271-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Prevent unloading shared libraries on Linux when dlclose() is called. This is necessary since command-line option parsing API relies on registering the global option instances in the option parser instance which can be loaded in a different shared library. Given that we can't reliably remove those options when a library is unloaded, the parser ends up containing dangling references. Since glibc has relatively complex library unloading rules, some of the LLVM libraries can be unloaded while others (including the Support library) stay loaded causing quite a mayhem. To reliably prevent that, just forbid unloading all libraries -- it's a very bad idea anyway. While the issue arguably happens only with BUILD_SHARED_LIBS, it may affect any library reusing llvm::cl interface. Based on patch provided Ross Hayward on https://bugs.gentoo.org/617154. Previously hit by Fedora back in Feb 2016: https://lists.freedesktop.org/archives/mesa-dev/2016-February/107242.html Differential Revision: https://reviews.llvm.org/D40459 llvm-svn: 319069
* [CMake] Allow for Solaris ld -V output on stdoutMichal Gorny2017-11-171-1/+2
| | | | | | | | | | | | | | | | | | In recent versions of Solaris 11.4 (previously 12), ld -V output went to stdout instead of stderr. Since AddLLVM.cmake only expects it on stderr, Solaris ld wasn't properly detected and options not understood by it are passed during the build. The following patch fixes this, allowing for both variants. Tested on i386-pc-solaris2.11.4 (on top of D35755 which is needed for proper Solaris support). Patch by Rainer Orth. Differential Revision: https://reviews.llvm.org/D39601 llvm-svn: 318532
* [globalisel][tablegen] Generate rule coverage and use it to identify ↵Daniel Sanders2017-11-161-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | untested rules Summary: This patch adds a LLVM_ENABLE_GISEL_COV which, like LLVM_ENABLE_DAGISEL_COV, causes TableGen to instrument the generated table to collect rule coverage information. However, LLVM_ENABLE_GISEL_COV goes a bit further than LLVM_ENABLE_DAGISEL_COV. The information is written to files (${CMAKE_BINARY_DIR}/gisel-coverage-* by default). These files can then be concatenated into ${LLVM_GISEL_COV_PREFIX}-all after which TableGen will read this information and use it to emit warnings about untested rules. This technique could also be used by SelectionDAG and can be further extended to detect hot rules and give them priority over colder rules. Usage: * Enable LLVM_ENABLE_GISEL_COV in CMake * Build the compiler and run some tests * cat gisel-coverage-[0-9]* > gisel-coverage-all * Delete lib/Target/*/*GenGlobalISel.inc* * Build the compiler Known issues: * ${LLVM_GISEL_COV_PREFIX}-all must be generated as a manual step due to a lack of a portable 'cat' command. It should be the concatenation of all ${LLVM_GISEL_COV_PREFIX}-[0-9]* files. * There's no mechanism to discard coverage information when the ruleset changes Depends on D39742 Reviewers: ab, qcolombet, t.p.northover, aditya_nandakumar, rovka Reviewed By: rovka Subscribers: vsk, arsenm, nhaehnle, mgorny, kristof.beyls, javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D39747 llvm-svn: 318356
* Move the setting of LLVM_BUILD_MODE to a macro so that we can re-use it in ↵Greg Bedwell2017-11-131-6/+10
| | | | | | | | compiler-rt Differential Revision: https://reviews.llvm.org/D38470 llvm-svn: 318034
* [CMake] Passthrough CMAKE_SYSROOT to external projectsPetr Hosek2017-11-091-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D39029 llvm-svn: 317744
* [cmake] Allow LLVM_BUILD_INSTRUMENTED to be set to IR or FrontendVedant Kumar2017-11-081-3/+8
| | | | | | | | | | - This deprecates LLVM_ENABLE_IR_PGO but keeps it around for now. - Errors out when LLVM_BUILD_INSTRUMENTED and LLVM_BUILD_INSTRUMENTED_COVERAGE are both set. Motivated by bogner's post-commit review of r313770. llvm-svn: 317725
* [CMake] Remove target to build native tablegenJonas Hahnfeld2017-11-081-14/+1
| | | | | | | | | | | | | This was once needed so that multiple tablegen binaries don't compile the library concurrently. However, this isn't needed anymore since adding USES_TERMINAL to the custom_command. This is supported by the fact that the target was only building LLVMSupport since some cleanups a year ago. If this dependency had really been needed, we would have seen complaints. Differential Revision: https://reviews.llvm.org/D39299 llvm-svn: 317695
* [CMake] Add custom target to create build directoryJonas Hahnfeld2017-11-081-1/+4
| | | | | | | | | | CMake does a poor job in tracking dependencies on files and directories directly. Create custom target similar to the configuration step. On my system, this avoids the reconfiguration on each build. Differential Revision: https://reviews.llvm.org/D39298 llvm-svn: 317694
* Move the srpm, ocaml_make_directory, llvm_vcsrevision_h, and llvm-headers ↵Aaron Ballman2017-11-041-0/+1
| | | | | | projects into the Misc folder on IDEs like Visual Studio rather than leave them in the root directory. NFC. llvm-svn: 317416
* CMake: Let LLVM_BUILD_32_BITS aware of large file.NAKAMURA Takumi2017-11-041-0/+5
| | | | llvm-svn: 317402
* [cmake] Make check_linker_flags operate via linker flagsShoaib Meenai2017-10-311-3/+1
| | | | | | | | | | | | | | | | | `check_linker_flags` currently sets the *compiler* flags (via `CMAKE_REQUIRED_FLAGS`), and thus implicitly relies on cmake's default behavior of passing the compiler flags to the linker. This breaks when cmake's build rules have been altered to not pollute the link line with compiler flags (which can be desirable for build cleanliness). Instead, set `CMAKE_EXE_LINKER_FLAGS` explicitly and use `CMP0056` to ensure the linker flags are passed along. Additionally, since we're inside a function, we can just alter the variable directly (as the alteration will be limited to the scope of the function) rather than saving and restoring the old value. Differential Revision: https://reviews.llvm.org/D39431 llvm-svn: 316972
* Fix -fuse-ld feature detection error.Rui Ueyama2017-10-301-1/+4
| | | | | | | | | | | | | | | | check_cxx_compiler_flag doesn't seem to try to link a program, so the existing code doesn't correctly detect the availability of a given linker. This patch uses check_cxx_source_compiles instead. I confirmed that cmake now reports this error Host compiler does not support '-fuse-ld=foo' for -DLLVM_USE_LINKER=foo. Differential Revision: https://reviews.llvm.org/D39274 llvm-svn: 316958
* [CMake] Fix linker detection in AddLLVM.cmakeTim Shen2017-10-301-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Fix linker not being correctly detected when a custom one is specified through LLVM_USE_LINKER CMake variable. In particular, cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold ../llvm resulted into Linker detection: GNU ld instead of Linker detection: GNU Gold due to the construction not accounting for such variable. It led to the general confusion and prevented setting linker-specific flags inside functions defined in AddLLVM.cmake. Thanks Oleksii Vilchanskyi for the patch! llvm-svn: 316956
* Force #define GTEST_LANG_CXX11.Zachary Turner2017-10-271-0/+7
| | | | | | | | | | | | | | | | | | gtest depends on this #define to determine whether it can use various classes like std::tuple, or whether it has to fall back to experimental classes in the std::tr1 namespace. The check in the current version of gtest relies on the value of the `__cplusplus` macro, but MSVC provides a non-conformant value of this macro, making it effectively impossible to detect C++11. In short, LLVM compiled with MSVC has been silently using the tr1 versions of several classes since the beginning of time. This would normally be pretty benign, except that in the latest preview of MSVC they have marked all of the tr1 classes deprecated, so it spews thousands of warnings. llvm-svn: 316798
* [cmake] Restrict resource file usage to Windows build hostsShoaib Meenai2017-10-251-2/+2
| | | | | | | | | | | | | | | | Resource file compilation requires a working resource compiler. Unfortunately, llvm-rc isn't quite there yet [1], and cmake's rc invocation only works on Windows [2]. Until both those issues are addressed, disable resource file usage on non-Windows build hosts, to unblock Windows cross-compilation. This is also consistent with the existing comment, which says "If *on Windows* and building with MSVC". [1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118433.html [2] https://public.kitware.com/pipermail/cmake/2017-October/066441.html Differential Revision: https://reviews.llvm.org/D39265 llvm-svn: 316594
* [cmake] Allow building fuzzers with OSS-Fuzz flags.Matt Morehouse2017-10-121-2/+7
| | | | | | | | | | | | Reviewers: kcc, bogner Reviewed By: bogner Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D38858 llvm-svn: 315629
* Revert "[CMake] Remove `CMAKE_.*_OUTPUT_DIRECTORY` (NFCI)"Brian Gesiak2017-09-291-0/+2
| | | | | | | | Summary: It appears polly makes use of the `CMAKE_RUNTIME_OUTPUT_DIRECTORY` variable when configuring its lit test suite. Reverting this for now. llvm-svn: 314551
* [CMake] Remove `CMAKE_.*_OUTPUT_DIRECTORY` (NFCI)Brian Gesiak2017-09-291-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Three `CMAKE_.*_OUTPUT_DIRECTORY` variables used to be set in CMake and referenced in various other parts of the project. However, in r198205 chapuni added a note to "don't set them anymore", and any remaining references to them were subsequently removed in r198316 and r199592. Now that the variables are no longer used anywhere, remove them, along with the comments advising against using them any longer. Test Plan: I ran `check-all` and confirmed the tests built and passed. Reviewers: beanz, chapuni Reviewed By: beanz Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D38389 llvm-svn: 314550
* Cleanup some problems with LLVM_ENABLE_DUMP in release builds, andDon Hinton2017-09-271-4/+0
| | | | | | | | always set LLVM_ENABLE_DUMP=ON for +Asserts builds. Differential Revision: https://reviews.llvm.org/D38306 llvm-svn: 314346
* CMake: Add option to set LLVM_ENABLE_DUMPMatthias Braun2017-09-261-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D38267 llvm-svn: 314186
* [lit] Add a test for the builtin config map.Zachary Turner2017-09-211-3/+6
| | | | | | | | | | | | | | | | | | | Config map is not exposed through the command line, so testing this is somewhat tricky. But basically we need a test that if a custom driver builds a config map and passes it to main, it gets respected. A config map allows config files in the source tree to be mapped to alternate config files in the build tree. This particular test works by having two config files in separate directories, and setting up a config map to have that redirects A/lit.site.cfg to B/altconfig. Then, we print a message in A/lit.site.cfg and B/altconfig and check that we do see the output from B but don't see the output from A. Additionally we test that the test suite specified by A's config map is properly discovered. Differential Revision: https://reviews.llvm.org/D38105 llvm-svn: 313887
* [lit] Make lit support config files with .py extension.Zachary Turner2017-09-211-6/+12
| | | | | | | | | | | | | | | | | Many editors and Python-related diagnostics tools such as debuggers break or fail in mysterious ways when python files don't end in .py. This is especially true on Windows, but still exists on other platforms. I don't want to be too heavy handed in changing everything across the board, but I do want to at least *allow* lit configs to have .py extensions. This patch makes the discovery process first look for a config file with a .py extension, and if one is not found, then looks for a config file using the old method. So for existing users, there should be no functional change. Differential Revision: https://reviews.llvm.org/D37838 llvm-svn: 313849
* [cmake] Add an option to build llvm with IR PGOVedant Kumar2017-09-201-5/+19
| | | | | | | | | | | | This adds an LLVM_ENABLE_IR_PGO option to enable building llvm and its tools with IR PGO instrumentation. Usage: -DLLVM_BUILD_INSTRUMENTED=On -DLLVM_ENABLE_IR_PGO=On (both options must be enabled) Differential Revision: https://reviews.llvm.org/D38066 llvm-svn: 313770
* [cmake] Unmark LLVM_BUILD_INSTRUMENTED_COVERAGE as experimentalVedant Kumar2017-09-201-2/+2
| | | | | | | | The coverage bot has been stable for a while: http://lab.llvm.org:8080/coverage/coverage-reports/index.html llvm-svn: 313769
* Make libcxx tests work when llvm sources are not present.Zachary Turner2017-09-201-3/+6
| | | | | | | | | | | | | | | | | | | Despite a strong CMake warning that this is an unsupported libcxx build configuration, some bots still rely on being able to check out lit and libcxx independently with no LLVM sources, and then run lit against libcxx. A previous patch broke that workflow, so this is making it work again. Unfortunately, it breaks generation of the llvm-lit script for libcxx, but we will just have to live with that until a solution is found that allows libcxx to make more use of llvm build pieces. libcxx can still run tests by using the ninja check target, or by running lit.py directly against the build tree or source tree. Differential Revision: https://reviews.llvm.org/D38057 llvm-svn: 313763
* [cmake] Add SOURCE_DIR argument to llvm_check_source_file_listShoaib Meenai2017-09-191-4/+16
| | | | | | | | | The motivation is to be able to check sources outside the current directory. See D31363 for example usage. Differential Revision: https://reviews.llvm.org/D37859 llvm-svn: 313648
* Resubmit "Fix llvm-lit script generation in libcxx."Zachary Turner2017-09-191-3/+3
| | | | | | | | After speaking with the libcxx owners, they agreed that this is a bug in the bot that needs to be fixed by the bot owners, and the CMake changes are correct. llvm-svn: 313643
* Revert "Fix llvm-lit script generation in libcxx."Zachary Turner2017-09-191-3/+3
| | | | | | | | | | | | This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9. There is a bot that is checking out libcxx and lit with nothing else and then running lit.py against the test tree. Since there's no LLVM source tree, there's no LLVM CMake. CMake actually reports this as a warning saying unsupported libcxx configuration, but I guess someone is depending on it anyway. llvm-svn: 313607
* Fix llvm-lit script generation in libcxx.Zachary Turner2017-09-191-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D37997 llvm-svn: 313606
* [cmake] Add a simple function to dump all variables.Zachary Turner2017-09-181-0/+7
| | | | | | This is useful when debugging CMake problems. llvm-svn: 313574
* Resubmit "Add a shared llvm.lit module that all test suites can use."Zachary Turner2017-09-161-0/+4
| | | | | | | | There were some issues surrounding Py2 / Py3 compatibility, but I've now tested with both Py2 and Py3 and everything seems to work. llvm-svn: 313467
* Revert lit changes related to lit.llvm module.Zachary Turner2017-09-161-4/+0
| | | | | | | | It looks like this is going to be non-trivial to get working in both Py2 and Py3, so for now I'm reverting until I have time to fully test it under Python 3. llvm-svn: 313429
* Resubmit "[lit] Add a lit.llvm module that all llvm projects can use"Zachary Turner2017-09-161-0/+4
| | | | | | | This was reverted alongside the revert of the lit/llvm-lit refactor, but now that that has re-landed, I'm relanding this as well. llvm-svn: 313426
* Resubmit "[lit] Force site configs to run before source-tree configs"Zachary Turner2017-09-151-8/+66
| | | | | | | | | | | | | | | | | | | | This is a resubmission of r313270. It broke standalone builds of compiler-rt because we were not correctly generating the llvm-lit script in the standalone build directory. The fixes incorporated here attempt to find llvm/utils/llvm-lit from the source tree returned by llvm-config. If present, it will generate llvm-lit into the output directory. Regardless, the user can specify -DLLVM_EXTERNAL_LIT to point to a specific lit.py on their file system. This supports the use case of someone installing lit via a package manager. If it cannot find a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or invalid, then we print a warning that tests will not be able to run. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313407
* Revert "[lit] Force site configs to run before source-tree configs"Zachary Turner2017-09-151-17/+5
| | | | | | | | This patch is still breaking several multi-stage compiler-rt bots. I already know what the fix is, but I want to get the bots green for now and then try re-applying in the morning. llvm-svn: 313335
* [cmake] Fix a variable shadowing bugReid Kleckner2017-09-151-0/+1
| | | | llvm-svn: 313331
* [lit] Revert "Add a lit.llvm module that all llvm projects can use"Zachary Turner2017-09-151-4/+0
| | | | | | | This is breaking due to some changes I forgot to merge in, so I'm temporarily reverting them until I can re-test that this works. llvm-svn: 313328
* [lit] Add a lit.llvm module that all test suites can use.Zachary Turner2017-09-151-0/+4
| | | | | | | | | | | | | | To further reduce duplicate code, this patch introduces a module that configs can simply import and get access to a lot of useful functionality such as setting up paths, adding features that are useful across all projects, and other utility-type functions. For now this only updates llvm's suite to use this new library, but subsequent patches will update other projects. Differential Revision: https://reviews.llvm.org/D37778 llvm-svn: 313325
* [lit] Force site configs to be run before source-tree configsZachary Turner2017-09-141-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch simplifies LLVM's lit infrastructure by enforcing an ordering that a site config is always run before a source-tree config. A significant amount of the complexity from lit config files arises from the fact that inside of a source-tree config file, we don't yet know if the site config has been run. However it is *always* required to run a site config first, because it passes various variables down through CMake that the main config depends on. As a result, every config file has to do a bunch of magic to try to reverse-engineer the location of the site config file if they detect (heuristically) that the site config file has not yet been run. This patch solves the problem by emitting a mapping from source tree config file to binary tree site config file in llvm-lit.py. Then, during discovery when we find a config file, we check to see if we have a target mapping for it, and if so we use that instead. This mechanism is generic enough that it does not affect external users of lit. They will just not have a config mapping defined, and everything will work as normal. On the other hand, for us it allows us to make many simplifications: * We are guaranteed that a site config will be executed first * Inside of a main config, we no longer have to assume that attributes might not be present and use getattr everywhere. * We no longer have to pass parameters such as --param llvm_site_config=<path> on the command line. * It is future-proof, meaning you don't have to edit llvm-lit.in to add support for new projects. * All of the duplicated logic of trying various fallback mechanisms of finding a site config from the main config are now gone. One potentially noteworthy thing that was required to implement this change is that whereas the ninja check targets previously used the first method to spawn lit, they now use the second. In particular, you can no longer run lit.py against the source tree while specifying the various `foo_site_config=<path>` parameters. Instead, you need to run llvm-lit.py. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313270
* Revert "Determine up front which projects are enabled."Zachary Turner2017-09-131-33/+2
| | | | | | | | | | | This was intended to be a generic CMake solution to a problem shared across several projects. It turns out it doesn't interact very well certain CMake configurations, and furthermore the "problem" is actually not a problem, as the problematic code is never executed to begin with. So this really isn't solving anything. llvm-svn: 313191
* Determine up front which projects are enabled.Zachary Turner2017-09-121-2/+33
| | | | | | | | | | | | | | | | | | | Some projects need to add conditional dependencies on other projects. compiler-rt is already doing this, and I attempted to add this to debuginfo-tests when I ran into the ordering problem, that you can't conditionally add a dependency unless that dependency's CMakeLists.txt has already been run (which would allow you to say if (TARGET foo). The solution to this seems to be to determine very early on the entire set of projects which is enabled. This is complicated by the fact that there are multiple ways to enable projects, and different tree layouts (e.g. mono-repo, out of -tree, external, etc). This patch attempts to centralize all of this into one place, and then updates compiler-rt to demonstrate as a proof of concept how this can simplify code. Differential Revision: https://reviews.llvm.org/D37637 llvm-svn: 313091
* [CMake] Update GetSVN.cmake to handle repoMinSeong Kim2017-09-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When repo is used with git, 'clang --version' option does not display the correct revision information (i.e. git hash on TOP) as the following: clang version 6.0.0 ---> clang version 6.0.0 (clang version) (llvm version) This is because repo also creates .git/svn folder as git-svn does and this makes repo with git uses "git svn info" command, which is only for git-svn, to retrieve its revision information, making null for the info. To correctly distinguish between git-svn and repo with git, the folder hierarchy to specify for git-svn should be .git/svn/refs as the "git svn info" command depends on the revision data in .git/svn/refs. This patch in turn makes repo with git passes through to the third macro, get_source_info_git, in get_source_info function, resulting in correctly retrieving the revision information for repo with git using "git log ..." command. This patch is tested with git, svn, git-svn, and repo with git. Reviewers: llvm-commits, probinson, rnk Reviewed By: rnk Subscribers: rnk, mehdi_amini, beanz, mgorny Differential Revision: https://reviews.llvm.org/D35532 llvm-svn: 312864
* Move some CLI utils out of llvm-isel-fuzzer and into the libraryJustin Bogner2017-09-021-0/+1
| | | | | | | | FuzzMutate might not be the best place for these, but it makes more sense than an entirely new library for now. This will make setting up fuzz targets with consistent CLI handling easier. llvm-svn: 312425
* [CMAKE] Move version control macros to AddLLVM.cmake so they can be reused ↵Don Hinton2017-09-021-0/+33
| | | | | | | | | | | | | by clang, etc. Summary: Move version control macros, find_first_existing_file and find_first_existing_vc_file to AddLLVM.cmake so they can be reused by sub projects like clang. Differential Revision: https://reviews.llvm.org/D36971 llvm-svn: 312419
* Disable 64bit file position on old 32 bit Androids.Eugene Zemtsov2017-09-011-5/+9
| | | | | | | | | | This is needed for building LLVM on Android with new NDK (newer than r15c) and API level < 24. Android C library (Bionic) didn't have support for 64 bit file position until Android N. Differential Revision: https://reviews.llvm.org/D37314 llvm-svn: 312389
* llvm-isel-fuzzer: Make buildable and testable without libFuzzerJustin Bogner2017-09-011-2/+6
| | | | | | | | | | | | | | This adds a dummy main so we can build and run the llvm-isel-fuzzer functionality when we aren't building LLVM with coverage. The approach here should serve as a template to stop in-tree fuzzers from bitrotting (See llvm.org/pr34314). Note that I'll probably move most of the logic in DummyISelFuzzer's `main` to a library so it's easy to reuse it in other fuzz targets, but I'm planning on doing that in a follow up that also consolidates argument handling in our LLVMFuzzerInitialize implementations. llvm-svn: 312338
* Revert r312240Alex Lorenz2017-08-311-2/+0
| | | | | | | The buildbots have shown that -Wstrict-prototypes behaves differently in GCC and Clang so we should keep it disabled until Clang follows GCC's behaviour llvm-svn: 312246
* Build LLVM with -Wstrict-prototypes enabledAlex Lorenz2017-08-311-0/+2
| | | | | | | | | | | Clang 5 supports -Wstrict-prototypes. We should use it to catch any C declarations that declare a non-prototype function. rdar://33705313 Differential Revision: https://reviews.llvm.org/D36669 llvm-svn: 312240
* cmake: Invent add_llvm_fuzzer to set up fuzzer targetsJustin Bogner2017-08-311-0/+7
| | | | | | | | | | | | | | | | This moves the cmake configuration for fuzzers in LLVM to a new macro, add_llvm_fuzzer. This will make it easier to keep things consistent while implementing llvm.org/pr34314. I've also made a couple of minor functional changes here: - the fuzzers now use add_llvm_executable rather than add_llvm_tool. This means they won't create install targets and stuff like that, because those made little sense for these fuzzers. - I've grouped these under "Fuzzers" rather than in with "Tools" for people who build with IDEs. llvm-svn: 312200
OpenPOWER on IntegriCloud