https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105905
--- Comment #2 from zhonghao at pku dot org.cn ---
A programmer answered me, and provided some details. Here, I copy his response:
"This code:
Vector2 v{Math::sin(37.0_degf), Math::cos(37.0_degf)};
Utility::print("{:.10}\n", v[1]);
Utility::print("{:.10}\n", (v*v.lengthInverted())[1]);
Utility::print("{:.10}\n", (v/v.length())[1]);
prints the following in a debug build (-march=native -g) and in a release build
without -march=native (so just -O3.
0.7986354828
0.7986354828
0.7986354828
However, it prints the following in a -march=native -O3 build.
0.7986354828
0.798635602
0.7986355424
Okay, so I thought it's some optimization kicking in, producing a different
result, but then I realized that this code:
Vector2 v{Math::sin(37.0_degf), Math::cos(37.0_degf)};
// Utility::print("{:.10}\n", v[1]);
Utility::print("{:.10}\n", (v*v.lengthInverted())[1]);
Utility::print("{:.10}\n", (v/v.length())[1]);
prints
0.7986354828
0.7986354828
even with -march=native -O3. So, ummm, the v[1] in combination with
Utility::print() causes that particular optimization to kick in, and if it's
not there, it doesn't optimize anything? If I change Utility::print() to
std::printf(), it also stops being strange and prints 0.7986354828 three times.
So I suppose there has to be sufficiently complex code around these operations
to make some optimization kick in? I tried to look at the disassembly, the
"strange" variant has a bunch of FMA calls, the non-strange variant has none,
but those calls could also have been somewhere else, I'm not that good at
understanding the compiler output.
I tested with GCC 10 as well, and it has the same weird behavior as 11.
Unfortunately I don't remember if I was at GCC 10 or 9 before that commit.
Clang prints 0.7986354828 always.
"
