[Bug c++/105905] New: A possible rounding error

[Bug c++/105905] New: A possible rounding error

[zhonghao at pku dot org.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105905

            Bug ID: 105905
           Summary: A possible rounding error
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

magnum is a data visualization library. I notice that its programmers
complained a rounding error in gcc. It occurs when compiling their code in the
release version. To fix the problem, they change their test cases, which is a
workaround:

https://github.com/mosra/magnum/commit/fb51f25a7b613aa5be744deea5a4ddb88f3de064

I also open an issue in magnum. Its programmers can provide more feedback.

[Bug middle-end/105905] A possible rounding error

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105905

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
          Component|c++                         |middle-end
   Last reconfirmed|                            |2022-06-09

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There is not enough information to figure out what is going wrong. It could be
fma usage or it could be that they are in 32bit x86 which uses x87 which does
fp slightly different. Or it could be an unitizlized variable on their side
causing the issue.

[Bug middle-end/105905] A possible rounding error

[zhonghao at pku dot org.cn]

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.
"

[Bug middle-end/105905] A possible rounding error

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105905

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So clang defaults to -ffp-contract=off (maybe on which is actually the same as
off for GCC) while GCC defaults to -ffp-contract=fast. And with -march=native,
the FMA instruction is enabled which allows GCC to do contractions for some
floating point and uses FMA more.

Using -ffp-contract=off (or -ffp-contract=on) will get the behavior the
developer wants.