[Bug c/106574] New: gcc 12 with O3 leads to failures in glibc's y1f128 tests

[Bug c/106574] New: gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com]

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

            Bug ID: 106574
           Summary: gcc 12 with O3 leads to failures in glibc's y1f128
                    tests
           Product: gcc
           Version: 12.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: michael.hudson at canonical dot com
  Target Milestone: ---

Initially reported here, but more likely to be a gcc issue: if I build glibc
with gcc 12 and -O3 (as is the default in Debian/Ubuntu) I get this failure:

(kinetic-amd64)root@anduril:/build/glibc-EA2Jch/glibc-2.36/build-tree/amd64-libc#
./elf/ld-linux-x86-64.so.2 --library-path .:./elf:./math 
./math/test-float128-y1
testing _Float128 (without inline functions)
Failure: Test: y1_downward (0x1.c1badep+0)
Result:
 is:         -2.49850711930108135145795303826944004e-01 
-0x1.ffb1bae4fa20118544b142160f5fp-3
 should be:  -2.49850711930108135145795303826943836e-01 
-0x1.ffb1bae4fa20118544b142160f58p-3
 difference:  1.68518870133883137142398069976181140e-34  
0x1.c000000000000000000000000000p-113
 ulp       :  7.0000
 max.ulp   :  5.0000
Maximal error of `y1_downward'
 is      : 7 ulp
 accepted: 5 ulp

Test suite completed:
  216 test cases plus 212 tests for exception flags and
    212 tests for errno executed.
  2 errors occurred.

Building the e_j1f128.os object with -O2 or with gcc-11 fixes the failure.

Not sure how to reduce this to a smaller test case, but I'm happy to try
things.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com]

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

--- Comment #1 from Michael Hudson-Doyle <michael.hudson at canonical dot com> ---
oops forgot the link to my glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=29463

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
this is just 2 ulp difference ...

This could be constant folding difference between GCC and what is done for
_Float128 in the software. Which could mean this is a not a bug.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com]

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

--- Comment #3 from Michael Hudson-Doyle <michael.hudson at canonical dot com> ---
Certainly this could be "handled" by bumping the tolerance I guess. Not sure
how to tell if that is appropriate though...

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Michael Hudson-Doyle from comment #3)
> Certainly this could be "handled" by bumping the tolerance I guess. Not sure
> how to tell if that is appropriate though...

You have to look what GCC actually does, like if it is constant folding as
suggested or sth else.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
It's possible code is being moved across SET_RESTORE_ROUNDL, in which case 
maybe math_opt_barrier needs to be used in glibc code to prevent that 
movement.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com]

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

--- Comment #6 from Michael Hudson-Doyle <michael.hudson at canonical dot com> ---
Are there any tips as to how to diagnose this further? I tried putting a
math_opt_barrier on this line:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/ldbl-128/e_j1l.c;h=54c457681aecef079cb64d406ca89e05d2ce4fc5;hb=HEAD#l872
and it didn't help, although the failing test is hitting the case the
SET_RESTORE_ROUNDL is in.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I'd suggest looking at the generated assembly.  I don't know exactly what 
you mean by "putting a math_opt_barrier on this line"; it would need to be 
used in a way that ensures a dependency for all the code after 
SET_RESTORE_ROUNDL (for example, "xx = math_opt_barrier (xx);").

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com]

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

--- Comment #8 from Michael Hudson-Doyle <michael.hudson at canonical dot com> ---
I just changed

      z = xx * xx;

to

      z = math_opt_barrier(xx * xx);

which perhaps isn't sufficient.

But my reading of the assembly is that the issue is that some of the math code
is being moved _after_ the restore of the fpu state implied by
SET_RESTORE_ROUNDL (FE_TONEAREST).

I included some snippets in https://paste.ubuntu.com/p/RMdWK6yr2F/.

This seems bad?

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com]

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

--- Comment #9 from Michael Hudson-Doyle <michael.hudson at canonical dot com> ---
I uploaded the object file with the bad code to
https://people.canonical.com/~mwh/e_j1f128.os.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com]

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

--- Comment #10 from Michael Hudson-Doyle <michael.hudson at canonical dot com> ---
FWIW, I see a similar error on ppc64el with what looks like a similar cause. (I
also see other errors that do not go away with s/O3/O2/ so that might be
something slightly different).

O3:

(kinetic-ppc64el)root@bobonevm3:/build/glibc-9T9BfE/glibc-2.36/build-tree/ppc64el-libc#
./elf/ld64.so.2 --library-path .:./elf:./math  ./math/test-ibm128-y1
testing long double (without inline functions)
Failure: Test: y1_downward (0x2p+0)
Result:
 is:         -1.07032431540937546888370772277496e-01 
-0x1.b667a3914664758b0c44371e580p-4
 should be:  -1.07032431540937546888370772277477e-01 
-0x1.b667a3914664758b0c44371e520p-4
 difference:  1.84889274661174641893373882488153e-32  
0x1.800000000000000000000000000p-106
 ulp       :  12.0000
 max.ulp   :  11.0000
Maximal error of `y1_downward'
 is      : 12 ulp
 accepted: 11 ulp
Failure: Test: y1_upward (0x1.c1bc2ep+0)
Result:
 is:         -2.49838507061808223791568937534715e-01 
-0x1.ffab54c8e53c466a84209c10030p-3
 should be:  -2.49838507061808223791568937534759e-01 
-0x1.ffab54c8e53c466a84209c100a0p-3
 difference:  4.31408307542740831084539059139024e-32  
0x1.c00000000000000000000000000p-105
 ulp       :  14.0000
 max.ulp   :  9.0000
Failure: Test: y1_upward (0x2p+0)
Result:
 is:         -1.07032431540937546888370772277458e-01 
-0x1.b667a3914664758b0c44371e4c0p-4
 should be:  -1.07032431540937546888370772277475e-01 
-0x1.b667a3914664758b0c44371e518p-4
 difference:  1.69481835106076755068926058947474e-32  
0x1.600000000000000000000000000p-106
 ulp       :  11.0000
 max.ulp   :  9.0000
Maximal error of `y1_upward'
 is      : 14 ulp
 accepted: 9 ulp

Test suite completed:
  175 test cases plus 171 tests for exception flags and
    171 tests for errno executed.

O2:

(kinetic-ppc64el)root@bobonevm3:/build/glibc-9T9BfE/glibc-2.36/build-tree/ppc64el-libc#
./elf/ld64.so.2 --library-path .:./elf:./math  ./math/test-ibm128-y1
testing long double (without inline functions)
Failure: Test: y1_upward (0x1.c1bc2ep+0)
Result:
 is:         -2.49838507061808223791568937534728e-01 
-0x1.ffab54c8e53c466a84209c10050p-3
 should be:  -2.49838507061808223791568937534759e-01 
-0x1.ffab54c8e53c466a84209c100a0p-3
 difference:  3.08148791101957736488956470813589e-32  
0x1.400000000000000000000000000p-105
 ulp       :  10.0000
 max.ulp   :  9.0000
Failure: Test: y1_upward (0x2p+0)
Result:
 is:         -1.07032431540937546888370772277458e-01 
-0x1.b667a3914664758b0c44371e4c0p-4
 should be:  -1.07032431540937546888370772277475e-01 
-0x1.b667a3914664758b0c44371e518p-4
 difference:  1.69481835106076755068926058947474e-32  
0x1.600000000000000000000000000p-106
 ulp       :  11.0000
 max.ulp   :  9.0000
Maximal error of `y1_upward'
 is      : 11 ulp
 accepted: 9 ulp

Test suite completed:
  175 test cases plus 171 tests for exception flags and
    171 tests for errno executed.
  3 errors occurred.

(I also see llround errors on ppc64el, no idea what's going on there...)

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 10 Aug 2022, michael.hudson at canonical dot com via Gcc-bugs wrote:

> I just changed
> 
>       z = xx * xx;
> 
> to
> 
>       z = math_opt_barrier(xx * xx);
> 
> which perhaps isn't sufficient.

That wouldn't prevent the multiplication being moved before 
SET_RESTORE_ROUNDL, though it should suffice for the later computations as 
they all depend on z.

> But my reading of the assembly is that the issue is that some of the math code
> is being moved _after_ the restore of the fpu state implied by
> SET_RESTORE_ROUNDL (FE_TONEAREST).

To avoid code being moved after the restore, "math_force_eval (p);" just 
before the return would be appropriate.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com]

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

--- Comment #12 from Michael Hudson-Doyle <michael.hudson at canonical dot com> ---
Ah OK, yes that fixes the failure. Does this mean all uses of
SET_RESTORE_ROUND* should be using math_opt_barrier / math_force_eval to avoid
this issue? Sounds awkward. I guess having a macro to call an always_inline
function with a given rounding mode would be less error prone but also make
code harder to read... anyway back to the glibc tracker I guess.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com]

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

Michael Hudson-Doyle <michael.hudson at canonical dot com> changed:

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

--- Comment #13 from Michael Hudson-Doyle <michael.hudson at canonical dot com> ---
I fixed this in glibc so marking INVALID here. The general issue of preventing
fp operations being moved over rounding mode changes is all fairly depressing
but I'm not sure a general fix is realistic.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |MOVED