Is source-based coverage on LLVM Clang being actively maintained?

ankurrj7 · May 28, 2026, 12:27pm

I wanted to understand the current status and long-term direction of source-based coverage in LLVM/Clang.

Over the past few months, I’ve filed a couple of coverage accuracy issues, and while investigating them I also noticed several existing issues related to coverage mapping and reporting accuracy that appear to have been open for years without much activity.

I’m interested in contributing and helping improve this area, but before investing deeper I’d like to understand the overall picture from the community:

Is source-based coverage still being actively maintained?
Are there active maintainers or ongoing efforts around coverage mapping accuracy?
Is this infrastructure considered reliable and strategic for future use, or is it currently in more of a maintenance-only state?
Are there known limitations or architectural issues that make some of these bugs difficult to address?

We currently rely quite a bit on LLVM source-based coverage internally, so understanding its future direction and support level would really help.

justincady · May 28, 2026, 2:26pm

My understanding is it is actively maintained; there have been several fixes and enhancements this year. In recent history there have been several talks about SBCC as well (ex. this one from the Fuchsia team).

But yes, there are a number of long-standing issues. I filed a few and asked about them a while back in this thread.

cc @evodius96 @chapuni

ankurrj7 · May 28, 2026, 2:39pm

Thanks @justincady ,
Yes, I saw your thread earlier, and most of the issue you reported was what I was looking into. That’s what left me wondering how other are using SBC and not encoutering thoise issue or atleast it would be good to know if some of those can be fixed or not.

evodius96 · May 28, 2026, 3:21pm

Hi, yes I am one of the maintainers.

As @justincady mentioned, there’s been good activity, but yes there are a number of open issues and not a lot of contributors. I’d welcome your contributions, and I (and @chapuni and others) will assist with PRs.

I contributed support for Branch Coverage and MC/DC, and my team actively uses these features in our downstream compiler toolchains.

justincady · May 28, 2026, 4:13pm

I wondered the same thing. I learned from @evodius96 that many of the specific problems I reported surface due to increased code complexity (ex. our codebase contains many branching macros, unfortunately).

It’s possible these could be fixed, of course. But when I investigated fixing some of the unresolved issues I found that it’s quite difficult to fix one mapping scenario without breaking others. FWIW the maintainers were responsive and supportive in the PRs for the fixes I was able to create.

ankurrj7 · May 28, 2026, 5:59pm

thanks @evodius96 this is encouraging to know
I had filled following issues .

github.com/llvm/llvm-project

llvm-cov / clang reports unreachable code as executed when function exits via exit()

opened 01:52PM - 04 Feb 26 UTC

ankurrj7

coverage

We have observed cases where code coverage reports generated using icx and llvm-…cov mark unreachable code as executed, even though control flow cannot reach those lines at runtime. In particular, when a function calls exit(), the compiler and coverage tools do not treat this call as a non-returning path, resulting in incorrect basic block / region coverage. This leads to misleading coverage reports. ```console basic_block.c 1| |#include <stdio.h> 2| |#include <unistd.h> 3| |#include <stdlib.h> 4| | 5| | 6| |void fun1() 7| 1|{ 8| 1| printf("In some func never return\n"); 9| 1| exit(0); 10| 1|} 11| | 12| |int main(void) 13| 1|{ 14| 1| puts("This is a shared library test..."); 15| 1| fun1(); // this will never return 16| 1| printf("Hello 1\n"); // This is not reachable code , and cannot be marked as Hit 17| 1| if (1) { 18| 0| printf("Hello 2\n"); 19| 0| } 20| 1| return 0; 21| 1|} 22| | ``` Here by no chance line number 16 should be marked as hit as func1 never returns . problem here is icx is not treating function call as end of previous region /block

github.com/llvm/llvm-project

llvm-cov reports incorrect coverage when JMP is present in code

opened 01:47PM - 04 Feb 26 UTC

ankurrj7

coverage

llvm-cov show --instr-profile=app.profdata myapp 1| |#include <stdio.h…> 2| |#include <setjmp.h> 3| | 4| 1|int main() { 5| 1| jmp_buf env; 6| | 7| 1| if (setjmp(env) == 0) { 8| 1| printf("first\n"); 9| 1| longjmp(env, 1); 10| 1| } else { 11| 0| printf("second\n"); 12| 0| } 13| 1|} 14| | runnig this program clealry shows ./myapp first <<-- first printf is hit second ,< -- second printf is hit

I am still new to llvm and still kind of exploring . but surely i will try to help in whatever manner i can .

code base i am working on is really complex and there are many issue which we have noticed already most of them are related to accuracy of report
i will keep this thread alive and hopefully try fixing few of them for sure

ankurrj7 · May 28, 2026, 6:01pm

@justincady yes more or less same case , code base really complex , i worked out couple of cases myself but i am still very new so not sure if i am introducing any regression or not.

ankurrj7 · May 30, 2026, 4:25pm

i have some initial thoughts on this issue llvm-cov / clang reports unreachable code as executed when function exits via exit() · Issue #179662 · llvm/llvm-project · GitHub
can someone help me if this is right direction to explore ?
cc @justincady @evodius96

Topic		Replies	Views
Guidance on Issues with Code Coverage Accuracy Using Clang	3	464	July 2, 2025
How to get branch coverage by using 'source-based code coverage' LLVM Dev List Archives	6	454	May 6, 2020
Customizing SBCC for lcov workflows LLVM Dev List Archives	1	147	February 2, 2018
clang and code coverage? Clang Frontend	6	269	August 30, 2010
Source-based coverage results degradation between clang-14 and clang-18 Clang Frontend clang	4	359	February 11, 2025

Is source-based coverage on LLVM Clang being actively maintained?

Related topics