Re: timespec test failure on Linux/s390x

[Bruno Haible]

Paul Eggert wrote:
> That value of 'sum' is wrong; it should be most-negative value {tv_sec = 
> -9223372036854775808, tv_nsec = 0} because A and B are both that value, 
> and 'sum = timespec_add (a, b)' is supposed to be saturated addition.
> 
> My guess is that timespec-add.c's line 49 'INT_ADD_WRAPV (rs, bs, &rs)' 
> is not correctly returning true when RS and BS are both the 
> most-negative value.

Yes, this is what happens.

Breakpoint 4, main () at ../../gltests/test-timespec.c:135
135                     struct timespec sum = timespec_add (a, b);
(gdb) print a
$11 = {tv_sec = -9223372036854775808, tv_nsec = 0}
(gdb) print b
$12 = {tv_sec = -9223372036854775808, tv_nsec = 0}
(gdb) step
timespec_add (a=..., b=...) at ../../gllib/timespec-add.c:30
30      {
(gdb) next
31        time_t rs = a.tv_sec;
(gdb) 
32        time_t bs = b.tv_sec;
(gdb) 
33        int ns = a.tv_nsec + b.tv_nsec;
(gdb) 
34        int nsd = ns - TIMESPEC_HZ;
(gdb) 
35        int rns = ns;
(gdb) 
37        if (0 <= nsd)
(gdb) print rs
$13 = -9223372036854775808
(gdb) print bs
$14 = -9223372036854775808
(gdb) print ns
$15 = 0
(gdb) print nsd
$16 = -1000000000
(gdb) next
49        if (INT_ADD_WRAPV (rs, bs, &rs))
(gdb) next
64        return make_timespec (rs, rns);

> that suggests a GCC bug. (Yes, I know, everybody at 
> first blames the compiler. :-)

I can't determine whether it's a GCC or a QEMU bug. The QEMU bug hypothesis
looks more probable to me, so I've opened this ticket:
https://gitlab.com/qemu-project/qemu/-/issues/616

Bruno