similar to: A new code coverage bot

I've configured the bot to test lld and polly. The first batch of reports for the new tools are not ready yet, but anyone can monitor the build: http://lab.llvm.org:8080/green/view/Experimental/job/clang-stage2-coverage-R/ Matthias, I will ask around about adding a link to this bot on llvm.org once it graduates from the Experimental pane on greendragon. thanks, vedant > On Sep 23,

The bot hiccupped earlier but looks stable now. The average turnaround seems to be 3.5 hours. clang: http://lab.llvm.org:8080/coverage/coverage-reports/clang/index.html lld: http://lab.llvm.org:8080/coverage/coverage-reports/lld/index.html polly: http://lab.llvm.org:8080/coverage/coverage-reports/polly/index.html > On Sep 23, 2016, at 11:58 PM, Tobias Grosser via llvm-dev

Hi , I could see the LLVM code coverage info at the below links http://lab.llvm.org:8080/coverage/coverage-reports/clang/index.html http://llvm.org/reports/coverage/ I am interested in the branch coverage metric. I could not find the branch coverage related info . Can anyone let me know how to find it. If it is not available , I am happy to work on it, if I can get some details on why

Probably this job: lab.llvm.org:8080/green/job/clang-stage2-coverage-R/ 💬 from 📱 > On May 31, 2019, at 3:35 PM, Duncan Exon Smith <dexonsmith at apple.com> wrote: > > +Chris Matthews, do you know where the configs are stored for this? > >> On 2019 May 31, at 12:39, Chris Bieneman <beanz at apple.com> wrote: >> >> Hey Nico, >> >> I'm

On Mon, Jun 3, 2019 at 2:06 PM <vsk at apple.com> wrote: > Hi Nico, > > Sorry for the delay, I've been OOO. The llvm-cov bot should produce > reports for llvm-undname starting today. > Thanks! It looks like http://lab.llvm.org:8080/coverage/coverage-reports/index.html now has an "llvm-undname" entry, but

On Wed, Jun 5, 2019 at 1:33 PM <vsk at apple.com> wrote: > > > On Jun 4, 2019, at 4:41 PM, Nico Weber <thakis at chromium.org> wrote: > > On Mon, Jun 3, 2019 at 2:06 PM <vsk at apple.com> wrote: > >> Hi Nico, >> >> Sorry for the delay, I've been OOO. The llvm-cov bot should produce >> reports for llvm-undname starting today. >>

Hi Everyone, I have uploaded a patch that allows one to successfully gather gcov/gcda coverage information on programs which unload shared libraries. It¹s a simple fix, just adding a few COMPILER_RT_VISIBILITY (i.e. __attribute__((visibility("hidden")))) in GCDAProfiling.c. Now, I¹d like to include a test program to demonstrate the fix. AFAICT, there seems to be a single test for

On Mon, Jun 10, 2019 at 2:11 PM <vsk at apple.com> wrote: > > > On Jun 6, 2019, at 9:56 AM, Nico Weber <thakis at chromium.org> wrote: > > On Wed, Jun 5, 2019 at 1:33 PM <vsk at apple.com> wrote: > >> >> >> On Jun 4, 2019, at 4:41 PM, Nico Weber <thakis at chromium.org> wrote: >> >> On Mon, Jun 3, 2019 at 2:06 PM <vsk at

Hey Nico, I'm actually not sure where the configurations for that bot are stored. I suspect Duncan may have a better idea. I'm reasonably certain that the missing +x is just an oversight. -Chris > On May 30, 2019, at 6:24 PM, Nico Weber via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Vedant or Chris: Ping :) > > On Wed, May 29, 2019 at 7:56 AM Nico Weber

Hi Vedant and Chris, is the config for http://lab.llvm.org:8080/coverage/coverage-reports/index.html public somewhere? If so, where? (I looked in zorg but didn't find it.) If not, could you add "llvm-undname" to the list of binaries passed to llvm/utils/prepare-code-coverage-artifact.py so that llvm/lib/Demangle/MicrosoftDemangle.cpp (and friends) show up? (If the config is public,

+ Vedant Hi Hal, thanks. I apologize if my answers aren't as thorough as you would like; what I'm proposing is simply an extension to the existing infrastructure, so it would be enabled automatically as part of code coverage. Mapping of branch regions would be done in CoverageMappingGen and instrumented using the same profiling instrumentation mechanism under

Hi, Alan Thanks for making it clear. But I was more confused now :( I tested on a simple program and used both gcov and lcov to get branch coverage. The code and build commands as below: *Example simple.cc* #include <string> // If not comment this line, the branch coverage won't reach to 100% // #include <iostream> int main(int argc, const char* argv[]) { std::string str =

Vedant Kumar asked me to post my design thoughts concerning branch coverage at llvm-dev since there is general interest. My team at Texas Instruments is developing an embedded ARM C/C++ compiler with LLVM. I would like to enhance LLVM's code coverage capability with branch condition coverage (for C/C++), similar to GCC/GCOV support for branch coverage. This is useful for TI, and I think

Hi, Alan Really very excited to receive your email and sorry to be slow replying, it has been exceptionally busy over the last few days ;( Your explanation made the problem clear to me. So gcov branch coverage should be called condition coverage and clang region coverage is branch coverage in fact(also known as *decision/C1*), right? And llvm/clang will support all the following coverage

Hi, I'd like to add a new pass to LLVM which removes redundant profile counter updates. The goal is to speed up code coverage testing and profile generation for PGO. I'm sending this email out to describe my approach, share some early results, and gather feedback. Problem Overview ================ A profile counter is redundant if it's incremented in exactly the same basic blocks

Hi Dean, We didn't discuss using XRay instrumentation during the BoF but it is an interesting idea (by the way, thanks for your talk about XRay internals!). XRay provides the advantage of being able to turn profiling on and off, but I'm not sure how the resulting data could be used. The code coverage feature is highly dependent on the frontend's profile counter placement. The mapping

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

Hello, Our goals for the code coverage BoF (10/19) were to find areas where we can improve the coverage tooling, and to learn more about how coverage is used. I'd like to thank all of the attendees for their input and for making the BoF productive. Special thanks to Mandeep Grang, who volunteered as a mic runner at the last minute. In this email I'll share my (rough) notes and outline

With llc, the size of the names section can vary widely depending on the value of -DLLVM_TARGETS_TO_BUILD. Enabling coverage shouldn't increase the name section size much. I only see one place where this happens, and it's relatively cold: http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R at

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