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 onllvm
:a |= a == 0
.target/110787
: wrong code ongmp
tree-optimization/110838
: wrong code onx365
target/110880
:aarch64
ICE onhighway-1.0.5
tree-optimization/111009
: wrong code onperf
fromlinux
tree-optimization/111048
: wrong code onhighway-1.0.6
target/111051
:gcc
fails to useavx2
primitives onavx512
targeted functions onhighway-1.0.6
target/111060
:i686-linux
gcc
fails to build it’s ownlibbstdc++
due to missingFloat16
support.
Histograms time!
Type of bugs:
wrong-code
: 5other
: 4ICEs
: 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
: 5target
: 4middle-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 its implementation.
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 PR111048
the most. There gcc
generated
wrong code for highway-1.0.6
library in -mavx2
mode.
When handling the following loop:
[32];
u8 in_lanesfor (unsigned i = 0; i < 32; i += 2) {
[i + 0] = 0;
in_lanes[i + 1] = ((u8)0xff) >> (i & 7);
in_lanes}
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!