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