Some fixes and improvements in GCC

GCC 16 will probably release in a couple of months, and comes with a couple of my patches. There’s nothing too big this time, but a couple of bug fixes and some quality-of-life changes.

You no longer need to explicitly pass -ftest-coverage for -fcondition-coverage and -fpath-coverage to be useful, it is now implied. The -ftest-coverage flag controls if GCC creates the .gcno files gcov needs to create the report. The coverage support in GCC is built on top of arc profiling which underpins profile guided optimization (PGO), and the PGO doesn’t need the .gcno, only the .gcda (counters). Coverage was a sort of side effect, and MC/DC and prime path coverage was built on that framework. Unlike arc profiling, it doesn’t make much sense to ask for MC/DC and prime path coverage without also wanting to read the reports, so this makes GCC a bit easier to use.

I fixed a bug where gcov-dump printed the wrong offset for condition blocks, and taught it how to print the PATHS tag. gcov-dump is mostly useful for developing gcov itself, but it’s nice that it’s there. There’s a another bugfix in there too, which caused bad counter updates, but this bug was never included in a release.

I have revised my paper on MC/DC, collected some data for it; on how the instrumentation affects compile time, runtime overhead, and object size. What I found was that compile times suffered greatly when analyzing expressions with many conditions joined by a single operator. A phase of the CFG analysis is figuring out which other conditions to mask when we take an edge, and this step evaluated all possible candidates. What I realised is that we don’t need to evaluate all of them, the search starting at the left-adjacent operand (which we must also include) will dominate and always find all the masked conditions. This had a massive impact on compile times.

This is one of those problems that don’t really show up in testing that easily, because under normal circumstances this isn’t a problem. I wrote a small test program which causes the worst behaviour, a single (x && y && ... && z). I tested two cases, 1 is (x && y && ... && z) and 4 is (x1 || ... || x8) && .... These are the compile times before and after the fix:

Those numbers are for all of GCC, including parsing, code generation, and linking. I also measured just the MC/DC analysis pass (finding the masking table and emit the instrumentation code), and get somewhere between 15–20 times speedup, not bad at all. As it turns out, algorithms matter.

    before: 20822.303 ms (41.645 ms per expression)
    after:   1288.548 ms ( 2.577 ms per expression)

As you can see from the graphs, the performance hit really starts to kick in past 16 conditions, which is quite rare in practice. Still, faster is nice. I did find one case with 27 conditions in GNU ls, but that’s very much the exception.