libdfp failed to build from source in Fedora rawhide/f33 https://koji.fedoraproject.org/koji/taskinfo?taskID=47992721 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild Please fix libdfp at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, libdfp will be orphaned. Before branching of Fedora 34, libdfp will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source
Created attachment 1705432 [details] build.log file build.log too big, will only attach last 32768 bytes
Created attachment 1705433 [details] root.log file root.log too big, will only attach last 32768 bytes
Created attachment 1705434 [details] state.log
I disabled LTO for this package and rebuilt it successfully.
I've had a look into the s390x test-fail if libdfp is build with gcc 10 and LTO. Details of failed tests: cat ./test-nextdown-d128.out FAIL: test-nextdown-d128 Summary of test results: 1 FAIL 167 PASS The useful output is on stderr: Failure: Test: nextdown (0) Result: is: 1.00000000000000000000e-6176 1.000000000000000000000000000000000e-6176 should be: -1.00000000000000000000e-6176 -1.000000000000000000000000000000000e-6176 difference: 2.00000000000000000000e-6176 2.000000000000000000000000000000000e-6176 ulp : 2.0000 max.ulp : 0.0000 ... Failure: Test: nextdown (-0) Failure: Test: nextdown (DEC_SUBNORMAL_MIN) Failure: Test: nextdown (3) Failure: Test: nextdown (9.999999999999999999999999999999998E+DEC_MAX_EXP) Failure: Test: nextdown (-0.999999999999999999999999999999999E-DEC_MIN_EXP) Failure: Test: nextdown (-DEC_MAX) The first Failure occures with GCC 10 if build and linked with -flto. BUT this also occures if __nextafterd128 is inlined, e.g. if it is a static function (without lto. Then it happens also with older GCCs)! Then __nextdownd128 inlines the __nextafterd128 (x, y = -1*__builtin_infd32()) invocation and instead of loading y from stack, the values are loaded from literal pool: 00000000000006d0 <__nextdownd128>: 6d0: b3 c1 00 3d ldgr %f3,%r13 6d4: b3 c1 00 1f ldgr %f1,%r15 6d8: c0 d0 00 00 00 a4 larl %r13,820 <_fini+0x70> 6de: e3 f0 ff 50 ff 71 lay %r15,-176(%r15) 6e4: 68 00 30 00 ld %f0,0(%r3) 6e8: 68 20 30 08 ld %f2,8(%r3) Load y = -1*__builtin_infd32() from literal pool. 6ec: 68 40 d0 40 ld %f4,64(%r13) 6f0: 68 60 d0 48 ld %f6,72(%r13) (gdb) pdfp128 4 Sign: negative INFINITY!!! (gdb) i r f4 f6 f4 -1.0565890622713305e+270 (raw 0xf800000000000000) f6 0 (raw 0x0000000000000000) if (x == y) 6f4: b3 ec 00 04 cxtr %f0,%f4 6f8: a7 84 00 22 je 73c <__nextdownd128+0x6c> 6fc: 68 40 d0 30 ld %f4,48(%r13) 700: 68 60 d0 38 ld %f6,56(%r13) 704: b3 ec 00 04 cxtr %f0,%f4 708: a7 84 00 23 je 74e <__nextdownd128+0x7e> if (x > y) compares the adjusted value in literal pool as the jump is jnhe instead of jnh (compare to __nextafterd128). 70c: 68 40 d0 20 ld %f4,32(%r13) 710: 68 60 d0 28 ld %f6,40(%r13) This adjusted value is: (gdb) i r f4 f6 f4 1.0503920589735513e+270 (raw 0x77ffcff3fcff3fcf) f6 -5.1902764286268403e+250 (raw 0xf3fcff3fcff3fcff) (gdb) pdfp128 4 Sign: positive Exponent: 6144 Digits: 9.999 999 999 999 999 999 999 999 999 999 999 (D*10^E) 0 3 6 9 12 15 18 21 24 27 30 33 => As x in f0/f2 is 0.0 is now smaller than y, the code jumps to the "else"-path which do not use epsilon=-1*epsilon. Therefore the sign is now positive instead of the expected negative. 714: b3 e8 00 04 kxtr %f0,%f4 718: a7 54 00 28 jnhe 768 <__nextdownd128+0x98> 71c: 68 40 d0 10 ld %f4,16(%r13) 720: 68 60 d0 18 ld %f6,24(%r13) ... For comparison, the same sequence from the not inlined version: 0000000000000630 <__nextafterd128>: 630: b3 c1 00 5d ldgr %f5,%r13 634: c0 d0 00 00 00 d6 larl %r13,7e0 <_fini+0x30> 63a: 68 00 30 00 ld %f0,0(%r3) 63e: 68 20 30 08 ld %f2,8(%r3) Load y from the arguments 642: 68 40 40 00 ld %f4,0(%r4) 646: 68 60 40 08 ld %f6,8(%r4) if (x == y) 64a: b3 ec 00 04 cxtr %f0,%f4 64e: a7 84 00 1d je 688 <tst_nextafterd128+0x58> 652: 68 10 d0 30 ld %f1,48(%r13) 656: 68 30 d0 38 ld %f3,56(%r13) 65a: b3 ec 00 01 cxtr %f0,%f1 65e: a7 84 00 1c je 696 <tst_nextafterd128+0x66> if (x > y) compares the argument and the jump is jnh 662: b3 e8 00 04 kxtr %f0,%f4 666: a7 d4 00 23 jnh 6ac <tst_nextafterd128+0x7c> 66a: 68 40 d0 20 ld %f4,32(%r13) 66e: 68 60 d0 28 ld %f6,40(%r13) I have informed our gcc guy. He will have a look into this issue. I haven't looked into the ppc64le / x86_64 fails, but at least, they differ: - On ppc64le: Details of failed tests: cat ./check-localplt.out Extra PLT reference: libdfp.so: __dpd_extenddftd Extra PLT reference: libdfp.so: __dpd_extenddfdd Extra PLT reference: libdfp.so: __dpd_truncdfsd Extra PLT reference: libdfp.so: __dpd_trunctddf Extra PLT reference: libdfp.so: __dpd_trunctdsd2 cat ./test-acos-d128.out cat ./test-acos-d64.out cat ./test-fmaxmag-d128.out cat ./test-fmaxmag-d64.out cat ./test-fminmag-d128.out cat ./test-fminmag-d64.out FAIL: check-localplt FAIL: test-acos-d128 FAIL: test-acos-d64 FAIL: test-fmaxmag-d128 FAIL: test-fmaxmag-d64 FAIL: test-fminmag-d128 FAIL: test-fminmag-d64 Summary of test results: 7 FAIL 161 PASS - On x86_64: Details of failed tests: cat ./check-localplt.out Extra PLT reference: libdfp.so: __bid_floatsidd Extra PLT reference: libdfp.so: __bid_eqdd2 Extra PLT reference: libdfp.so: __bid_unordtd2 Extra PLT reference: libdfp.so: __bid_addsd3 Extra PLT reference: libdfp.so: __bid_divdd3 Extra PLT reference: libdfp.so: __bid_unordsd2 Extra PLT reference: libdfp.so: __bid_floatunsdisd Extra PLT reference: libdfp.so: __bid_floatditd Extra PLT reference: libdfp.so: __bid_nedd2 Extra PLT reference: libdfp.so: __bid_floatunsdidd Extra PLT reference: libdfp.so: __bid_gtdd2 Extra PLT reference: libdfp.so: __bid_subdd3 Extra PLT reference: libdfp.so: __bid_floatsitd Extra PLT reference: libdfp.so: __bid_addtd3 Extra PLT reference: libdfp.so: __bid_ltdd2 Extra PLT reference: libdfp.so: __bid_ltsd2 Extra PLT reference: libdfp.so: __bid_lttd2 Extra PLT reference: libdfp.so: __bid_eqsd2 Extra PLT reference: libdfp.so: __bid_floatdidd Extra PLT reference: libdfp.so: __bid_gedd2 Extra PLT reference: libdfp.so: __bid_mulsd3 Extra PLT reference: libdfp.so: __bid_eqtd2 Extra PLT reference: libdfp.so: __bid_multd3 Extra PLT reference: libdfp.so: __bid_fixsdsi Extra PLT reference: libdfp.so: __bid_trunctddd2 Extra PLT reference: libdfp.so: __bid_gtsd2 Extra PLT reference: libdfp.so: __bid_floatunsditd Extra PLT reference: libdfp.so: __bid_floatdisd Extra PLT reference: libdfp.so: __bid_adddd3 Extra PLT reference: libdfp.so: __bid_unorddd2 Extra PLT reference: libdfp.so: __bid_gttd2 Extra PLT reference: libdfp.so: __bid_nesd2 Extra PLT reference: libdfp.so: __bid_divsd3 Extra PLT reference: libdfp.so: __bid_extendsdtd2 Extra PLT reference: libdfp.so: __bid_netd2 Extra PLT reference: libdfp.so: __bid_floatsisd Extra PLT reference: libdfp.so: __bid_muldd3 Extra PLT reference: libdfp.so: __bid_divtd3 Extra PLT reference: libdfp.so: __bid_fixdddi Extra PLT reference: libdfp.so: __bid_fixddsi Extra PLT reference: libdfp.so: __bid_extendddtd2 Extra PLT reference: libdfp.so: __bid_fixsddi Extra PLT reference: libdfp.so: __bid_fixtddi Extra PLT reference: libdfp.so: __bid_letd2 Extra PLT reference: libdfp.so: __bid_fixtdsi Extra PLT reference: libdfp.so: __bid_trunctdsd2 Extra PLT reference: libdfp.so: __bid_subsd3 Extra PLT reference: libdfp.so: __bid_subtd3 Extra PLT reference: libdfp.so: __bid_getd2 FAIL: check-localplt Summary of test results: 1 FAIL 167 PASS
Just as information, Tulio has now opened the libdfp-github issue referencing this bug: "Issues when building with LTO #150" https://github.com/libdfp/libdfp/issues/150