A few days ago I pushed support for coverage suppression in GCC. Sometimes we write very defensive guards, especially in debug builds (like asserts), that are intended to never trigger because they signal a logic bug elsewhere. It’s hard to argue that defensive code and asserts isn’t excellent, but they paradoxically introduce a problem for coverage since we now introduce decisions and code paths that will never be exercised. The new #pragma suppress_coverage and __attribute__((suppress_coverage)) address this problem. GCC could already ignore files for coverage (with -fprofile-filter-files and -fprofile-exclude-files), but this is more granular.

This post describes a proposal and is a call for clients, if you will. I have an idea for an optimization in the GCC MC/DC instrumentation (-fcondition-coverage) that I estimate would reduce the overhead in both compile time, object size, and run time, roughly 2-3 times, and I am looking for clients to fund this work.

GCC has supported MC/DC since version 14 (released May 2024) and works quite well. I recently fixed a performance bug that made a massive difference for (very) large expressions, which went unnoticed for a while because such large expressions are quite uncommon and the performance has been adequate. I do believe we can improve both the compile time and the quality of instrumentation further.

Graph improvements

I wanted zcov to quickly and naturally show the coverage status of a piece of code. Most of the time we’re interested in missing coverage as that is where we need to do work, either adding a test, improving the spec, or figuring out if there is a mismatch between the code as-is and then goals we’re trying to achieve. zcov can now colour code the blocks to show this, using a common red/yellow/green system. This works quite well; the red blocks immediately stand out. In fact, differently coloured blocks stand out, so if a function is mostly covered, missing coverage stands out, and vice versa.