gcc-14 bugs, pile 2

September 6, 2023

Two more months of gcc-14 development have passed. The bug rate slowed down considerably. Let’s look at the new bugs since. This time it is mere 10 bugs.


Here are the bugs themselves:

Histograms time!

Type of bugs:

This was an unusual cycle: most of the bugs were related to the wrong code generated by gcc. Some of them (like gmp and perf ones) were very nasty to extract and report.


As usual half the bugs are lurking in tree-optimization part of the compiler. Though this time target-specific bugs are frequent as well.

A note on highway

3 out of 10 bugs were exposed by a highway library. It’s such a great vectorizer benchmark for gcc!

Initially I was a bit upset by the amount of C++ template indirections highway uses on it’s implementation.

As it exercises all the possible vector units available for the platform (SSE{2,3,4}, AVX{1,2} and many others) it was hard for me to narrow down to a single failing unit type: attempts to remove code for one of them fails the build for others.

But! I found an easy way to deal with it! We can disable most irrelevant targets in hwy/detect_targets.h by adding all the irrelevant targets to HWY_BROKEN_TARGETS define. I usually add everything except the broken target (usually HWY_AVX2 :).

And then reduction becomes trivial: I expand all the templates and get the simple function with a failure.

Parting words

gcc master still yields new bugs. It is still quite a bit of fun to get and extract build compiler failures from real world usage.

I liked https://gcc.gnu.org/PR111048 the most. There gcc generated wrong code for highway-1.0.6 library in -mavx2 mode.

When handling the following loop:

u8 in_lanes[32];
for (unsigned i = 0; i < 32; i += 2) {
  in_lanes[i + 0] = 0;
  in_lanes[i + 1] = ((u8)0xff) >> (i & 7);

gcc broke i = 12; iteration and instead of i[13] = 0xf; (0xff >> 4) stored something like i[13] = 0xef; there. gcc was able to fully constant-fold the loop (and did it slightly incorrectly).

Have fun!