similar to: [LLVMdev] CommandLine handling of -help and -version options

Hi Justin , Thank you for the confirmation and we would like to know that ,going forward the clang has the support the gcc gcov format or use the -fprofile-instr-generate -fcoverage-mapping and get ride of gcov format . We are planing to customize the clang code coverage for embedded world ,before we start tweaking the gcov / -fprofile-instr-generate code-base ,we would like to take feedback

George Karpenkov <ekarpenkov at apple.com> writes: > Should -DCMAKE_CXX_COMPILER be also specified? CMake is smart enough to infer that from C_COMPILER: % grep CMAKE_CXX_COMPILER CMakeCache.txt CMAKE_CXX_COMPILER:FILEPATH=/Users/bogner/llvm-lkgc/bin/clang++ >> On Aug 24, 2017, at 11:29 AM, Justin Bogner <mail at justinbogner.com> wrote: >> >> (kcc, george:

On Tue, Jul 21, 2015 at 6:30 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> > wrote: > > > > Paweł Bylica <chfast at gmail.com> writes: > > > I can confirm that the issue has been caused by NDEBUG flag. >

Compiling for AArch64: CommandLine Error: Option 'aarch64-branch-relax' registered more than once! Hi all! I am trying to run LDC (LLVM-based D compiler) on AArch64. The compiler contains all IR and target specific passes. You can view it as combined llc/opt tool. It uses the same strategy as opt to collect the passes with the NameParser. Like llc, it calls

Hi, Recently I started getting some weird errors from multiple tools (on Linux x86-64): λ lld lld: ../lib/Support/CommandLine.cpp:202: void (anonymous namespace)::CommandLineParser::registerCategory(llvm::cl::OptionCategory *): Assertion `std::count_if(RegisteredOptionCategories.begin(), RegisteredOptionCategories.end(), [cat](const OptionCategory *Category) { return cat->getName() ==

On Thu, May 28, 2015 at 2:09 PM, Justin Bogner <mail at justinbogner.com> wrote: > It sounds to me like this documentation just needs some clean up to be > clearer up front about what's going on. If nobody else gets to it first, > I'll take a shot at improving the situation when I have a chance. I just reworked this section a bit in r238504. Dario, does this help?

Hi Justin, > This looks like something I fixed recently, in r290271: ... ... > The tablegen build adopted USES_TERMINAL for this same reason in > r280748. I applied the 2 patches you mentioned above on my 3.9.1 tree and although the build seems to go along nicely than the earlier reported symptoms I can still see LLVMSupport being built a bit too many times than expected. $ cat

Umesh Kalappa <umesh.kalappa0 at gmail.com> writes: > Hi Justin , > > Thank you for the confirmation and we would like to know that ,going > forward the clang has the support the gcc gcov format or use the > -fprofile-instr-generate -fcoverage-mapping and get ride of gcov > format . Going forward, the -fprofile-instr-generate -fcoverage-mapping (which I'll refer to as

George Karpenkov <ekarpenkov at apple.com> writes: > OK so with Kuba’s help I’ve found the error: with optimization, dead > stripping of produced libraries is enabled, > which removes coverage instrumentation. > > However, this has nothing to do with the move to compiler-rt, so I’m > quite skeptical on whether it has worked > beforehand. > > A trivial fix is to do:

James Y Knight <jyknight at google.com> writes: > On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <Jeremy.Lakeman at gmail.com> > wrote: > >> Semantic versioning would recommend "v8.0.0-dev", "v8.0.0-rc1" etc. The >> hyphen indicating that this is a pre-release version coming before "v8.0.0" > > > Here's my proposal: > -

Justin Bogner <mail at justinbogner.com> writes: > I'll go ahead and file one though - more and more people are using phab > for llvm, so the problems with it are coming up more and more often. https://secure.phabricator.com/T8269

I decided to try out the fuzzer library and clang-fuzzer, but it doesn't seem to build for me. From the cmake files, I was pretty sure all I need to do is set -DLLVM_USE_SANITIZE_COVERAGE=ON, but with this I get a number of link errors for "lib/Fuzzer/test/LLVMFuzzer-CounterTest", for example: lib/libLLVMFuzzer.a(FuzzerLoop.cpp.o): In function `SetDeathCallback':

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

Kostya Serebryany <kcc at google.com> writes: > Justin, > Calling appendToUsed has horrible complexity and if we call it in > every function clang consumes tons of memory (6Gb when compiling one > of the clang's source files). This killed my machine today :) > > The solution is to call appendToUsed once per module, instead of once > per function. Oh right,

I'll need more details then. Maybe you can share the binary & its .sancov file? Or if you have a way to reproduce it? On Tue, Mar 7, 2017 at 1:23 PM Kostya Serebryany <kcc at google.com> wrote: > On Tue, Mar 7, 2017 at 12:50 PM, Mike Aizatsky <aizatsky at google.com> > wrote: > > Justin, > > I haven't seen this before. I suspect it is because of

I would like to use the on disk hash table that's currently in clang for instrumentation based profiling. This is a single header file that's currently found in include/clang/Basic/OnDiskHashTable.h, and I propose to move it to include/llvm/Support/OnDiskHashTable.h. Any strong objections to moving this? Also, the header includes a "clang::io" namespace with some operations for

Diego Novillo <dnovillo at google.com> writes: > On Thu, May 28, 2015 at 2:09 PM, Justin Bogner <mail at justinbogner.com> wrote: > >> It sounds to me like this documentation just needs some clean up to be >> clearer up front about what's going on. If nobody else gets to it first, >> I'll take a shot at improving the situation when I have a chance. >

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

On 19 August 2016 at 19:35, Justin Bogner <mail at justinbogner.com> wrote: > I think you misunderstood what I meant here. Whether "moving to git" > will affect my workflow depends very much on "how we're moving to > git". That's exactly what I understood. :) > For example, if we do a monorepo, I may now need to lay code out > differently on my

(kcc, george: sorry for the re-send, the first was from a non-list email address) My configuration for building the fuzzers in the LLVM tree doesn't seem to work any more (possibly as of moving libFuzzer to compiler-rt, but there have been a few other changes in the last week or so that may be related). I'm building with a fresh top-of-tree clang and setting -DLLVM_USE_SANITIZER=Address