similar to: [LLVMdev] [RFC] Moving OnDiskHashTable from clang to LLVM

Rafael Avila de Espindola <rafael.espindola at gmail.com> writes: >> On Mar 22, 2014, at 1:31, Justin Bogner <mail at justinbogner.com> wrote: >> Also, the header includes a "clang::io" namespace with some operations >> for reading and writing little endian files. Should these be directly >> renamed to "llvm::io", or would something like

Rafael Espíndola <rafael.espindola at gmail.com> writes: >> They're obviously related. Endian.h defines types like ulittle32, which >> DTRT when read and written from memory, whereas clang::io has functions >> to read and write memory like so: >> >> void Emit32(raw_ostream& Out, uint32_t V); >> uint32_t ReadLE32(const unsigned char

On Fri, Mar 28, 2014 at 1:33 PM, Justin Bogner <mail at justinbogner.com>wrote: > Chandler Carruth <chandlerc at google.com> writes: > > Format 2 > > -------- > > > > This format should be efficient to read and preferably reasonably > > compact. We'll convert from format 1 to format 2 using llvm-profdata, > > and clang

On Sat, Mar 22, 2014 at 1:18 AM, Justin Bogner <mail at justinbogner.com>wrote: > Chandler Carruth <chandlerc at google.com> writes: > > I think it would be worthwhile to consider the alternative of having > > the profile library write out data files in a format which is > > essentially "always" transformed by a post-processing tool before > >

Instrumentation-based profiling data is generated by instrumented binaries through library functions in compiler-rt, and read by the clang frontend to feed PGO. The current data format is a naive textual format. The files consist of a number of counters for each function in a program. Use cases ========= There are a few use cases that drive our requirements: A. Looking up the counters for a

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

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

Can we improve the error message here? We should be able to check zlib::isAvailable and give an error like "profile uses zlib compression but the profile reader was built without zlib support" or so in this case. Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> writes: > The __llvm_prf_names section is compressed but your llvm-profdata tool is > probably not built

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:

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

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

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 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 28 May 2014 17:44, Justin Bogner <mail at justinbogner.com> wrote: > In the autoconf system, I'm pretty sure compiler-rt's build is triggered > by a Makefile in clang, tools/clang/runtime/compiler-rt/Makefile. This > Makefile comments "We currently only try to generate runtime libraries > on x86", so I guess that's the place to start if you want to get it