gcc-14 bugs, pile 2

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.

Summary

Here are the bugs themselves:

• tree-optimization/110652: bootstrap failure for -Werror.
• middle-end/110697: bootstrap failure for -Werror.
• tree-optimization/110726: wrong code on llvm: a |= a == 0.
• target/110787: wrong code on gmp
• tree-optimization/110838: wrong code on x365
• target/110880: aarch64 ICE on highway-1.0.5
• tree-optimization/111009: wrong code on perf from linux
• tree-optimization/111048: wrong code on highway-1.0.6
• target/111051: gcc fails to use avx2 primitives on avx512 targeted functions on highway-1.0.6
• target/111060: i686-linux gcc fails to build it’s own libbstdc++ due to missing Float16 support.

Histograms time!

Type of bugs:

• wrong-code: 5
• other: 4
• ICEs: 1

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.

Subsystems:

• tree-optimization: 5
• target: 4
• middle-end: 1

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!