[Bug c/106574] New: gcc 12 with O3 leads to failures in glibc's y1f128 tests
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.c000p-113 ulp : 7. max.ulp : 5. 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574 --- Comment #1 from Michael Hudson-Doyle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574 --- Comment #3 from Michael Hudson-Doyle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574 --- Comment #6 from Michael Hudson-Doyle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574 --- Comment #8 from Michael Hudson-Doyle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574 --- Comment #9 from Michael Hudson-Doyle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574 --- Comment #10 from Michael Hudson-Doyle --- 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.800p-106 ulp : 12. max.ulp : 11. 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.c00p-105 ulp : 14. max.ulp : 9. 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.600p-106 ulp : 11. max.ulp : 9. 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.400p-105 ulp : 10. max.ulp : 9. 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.600p-106 ulp : 11. max.ulp : 9. 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574 --- Comment #12 from Michael Hudson-Doyle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574 Michael Hudson-Doyle changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #13 from Michael Hudson-Doyle --- 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.
