In just a few short weeks it is time for the annual NDC Techtown conference where I this year will be giving the talk Mastering MC/DC from first principles. It is an excellent conference; the programme is splendid and I’m quite sure there will be many interesting conversations between sessions, I truly recommend attending. Do come see my talk and come chat with me.

I will be also be giving a lecture on MC/DC in Tokyo and will be in Japan 4th-10th. If you would like to meet up, maybe have lunch or talk business, please send me an email and we’ll figure something out.

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