* timespec test failure on Linux/s390x
@ 2021-08-30 1:15 Bruno Haible
2021-08-30 1:49 ` Paul Eggert
0 siblings, 1 reply; 6+ messages in thread
From: Bruno Haible @ 2021-08-30 1:15 UTC (permalink / raw)
To: bug-gnulib; +Cc: Paul Eggert
In a testdir of all of Gnulib, on Linux/s390x, test-timespec fails:
../../gltests/test-timespec.c:152: assertion 'eq (timespec_add (a, sumbc), timespec_add (sum, c))' failed
Aborted (core dumped)
In test-timespec.c:152 the local variables are:
test = {{tv_sec = -9223372036854775808, tv_nsec = -1},
{tv_sec = -9223372036854775808, tv_nsec = 0},
{tv_sec = -9223372036854775808, tv_nsec = 1},
{tv_sec = -9223372036854775808, tv_nsec = 999999999},
{tv_sec = -9223372036854775807, tv_nsec = 0},
{tv_sec = -9223372036854775807, tv_nsec = 1},
{tv_sec = -9223372036854775807, tv_nsec = 999999999},
{tv_sec = -1, tv_nsec = 0},
{tv_sec = -1, tv_nsec = 1},
{tv_sec = -1, tv_nsec = 999999999},
{tv_sec = 0, tv_nsec = 0},
{tv_sec = 0, tv_nsec = 1},
{tv_sec = 0, tv_nsec = 999999999},
{tv_sec = 1, tv_nsec = 0},
{tv_sec = 1, tv_nsec = 1},
{tv_sec = 1, tv_nsec = 999999999},
{tv_sec = 1234567890, tv_nsec = 0},
{tv_sec = 1234567890, tv_nsec = 1},
{tv_sec = 1234567890, tv_nsec = 999999999},
{tv_sec = 9223372036854775806, tv_nsec = 0},
{tv_sec = 9223372036854775806, tv_nsec = 1},
{tv_sec = 9223372036854775806, tv_nsec = 999999999},
{tv_sec = 9223372036854775807, tv_nsec = 0},
{tv_sec = 9223372036854775807, tv_nsec = 1},
{tv_sec = 9223372036854775807, tv_nsec = 999999999},
{tv_sec = 9223372036854775807, tv_nsec = 2000000000}}
ntests = 26
computed_hz = 1000000000
i = 1
a = {tv_sec = -9223372036854775808, tv_nsec = 0}
roundtrip = {tv_sec = -9223372036854775808, tv_nsec = 0}
prevroundtrip = {tv_sec = -9223372036854775808, tv_nsec = 0}
j = 1
b = {tv_sec = -9223372036854775808, tv_nsec = 0}
sum = {tv_sec = 0, tv_nsec = 0}
diff = {tv_sec = 0, tv_nsec = 0}
rdiff = {tv_sec = 0, tv_nsec = 0}
k = 13
c = {tv_sec = 1, tv_nsec = 0}
sumbc = {tv_sec = -9223372036854775807, tv_nsec = 0}
timespec_add (a, sumbc) = {tv_sec = -9223372036854775808, tv_nsec = 0}
timespec_add (sum, c) = {tv_sec = 1, tv_nsec = 0}
* Questions:
Is timespec_add (a, sumbc) wrong?
Or does this particular triple (a, b, c) need to be exluded from the tests?
* struct timespec is defined as:
struct timespec
{
__time_t tv_sec; /* Seconds. */
...
};
and apparently __time_t is 64 bits wide and signed.
* Debugging the relevant invocation of timespec_add (a, sumbc):
#0 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) print rs
$4 = -9223372036854775808
(gdb) print bs
$5 = -9223372036854775807
(gdb) next
34 int nsd = ns - TIMESPEC_HZ;
(gdb)
35 int rns = ns;
(gdb)
37 if (0 <= nsd)
(gdb)
49 if (INT_ADD_WRAPV (rs, bs, &rs))
(gdb)
51 if (bs < 0)
(gdb)
53 rs = TYPE_MINIMUM (time_t);
(gdb)
54 rns = 0;
(gdb)
64 return make_timespec (rs, rns);
(gdb) print rs
$6 = -9223372036854775808
Bruno
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: timespec test failure on Linux/s390x
2021-08-30 1:15 timespec test failure on Linux/s390x Bruno Haible
@ 2021-08-30 1:49 ` Paul Eggert
2021-08-30 2:39 ` Bruno Haible
2021-09-12 15:28 ` Bruno Haible
0 siblings, 2 replies; 6+ messages in thread
From: Paul Eggert @ 2021-08-30 1:49 UTC (permalink / raw)
To: Bruno Haible; +Cc: bug-gnulib
On 8/29/21 6:15 PM, Bruno Haible wrote:
> ../../gltests/test-timespec.c:152: assertion 'eq (timespec_add (a, sumbc), timespec_add (sum, c))' failed
> Aborted (core dumped)
>
> In test-timespec.c:152 the local variables are:
> ...
> ntests = 26
> computed_hz = 1000000000
> i = 1
> a = {tv_sec = -9223372036854775808, tv_nsec = 0}
> roundtrip = {tv_sec = -9223372036854775808, tv_nsec = 0}
> prevroundtrip = {tv_sec = -9223372036854775808, tv_nsec = 0}
> j = 1
> b = {tv_sec = -9223372036854775808, tv_nsec = 0}
> sum = {tv_sec = 0, tv_nsec = 0}
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. Since you're using GCC, line 49 should be
equivalent to '__builtin_add_overflow (rs, bs, &rs)' (though you should
check this), and that suggests a GCC bug. (Yes, I know, everybody at
first blames the compiler. :-)
Which version of GCC are you using?
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98269> says that
__builtin_add_overflow does not work in GCC 6.5 on s390x, and that the
bug is fixed in GCC 7. Could this be the problem?
> sumbc = {tv_sec = -9223372036854775807, tv_nsec = 0}
> timespec_add (a, sumbc) = {tv_sec = -9223372036854775808, tv_nsec = 0}
...> * Questions:
> Is timespec_add (a, sumbc) wrong?
No, it's right.
> Or does this particular triple (a, b, c) need to be exluded from the tests?
I suspect the bug is in the earlier call to timespec_add, as mentioned
above.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: timespec test failure on Linux/s390x
2021-08-30 1:49 ` Paul Eggert
@ 2021-08-30 2:39 ` Bruno Haible
2021-09-12 15:28 ` Bruno Haible
1 sibling, 0 replies; 6+ messages in thread
From: Bruno Haible @ 2021-08-30 2:39 UTC (permalink / raw)
To: Paul Eggert; +Cc: bug-gnulib
Paul Eggert wrote:
> Which version of GCC are you using?
s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
> I suspect the bug is in the earlier call to timespec_add, as mentioned
> above.
I'll debug that call...
Bruno
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: timespec test failure on Linux/s390x
2021-08-30 1:49 ` Paul Eggert
2021-08-30 2:39 ` Bruno Haible
@ 2021-09-12 15:28 ` Bruno Haible
2021-09-12 19:40 ` Paul Eggert
1 sibling, 1 reply; 6+ messages in thread
From: Bruno Haible @ 2021-09-12 15:28 UTC (permalink / raw)
To: Paul Eggert; +Cc: bug-gnulib
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: timespec test failure on Linux/s390x
2021-09-12 15:28 ` Bruno Haible
@ 2021-09-12 19:40 ` Paul Eggert
2021-09-12 22:44 ` Bruno Haible
0 siblings, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2021-09-12 19:40 UTC (permalink / raw)
To: Bruno Haible; +Cc: bug-gnulib
On 9/12/21 8:28 AM, Bruno Haible wrote:
> I can't determine whether it's a GCC or a QEMU bug.
Surely it is a QEMU bug, as QEMU isn't properly implementing the
z/Architecture Principles of Operation (POP). Page 7-25 of the current
edition (SA22-7832-12) says that the AGR instruction treats its operands
as 64-bit signed binary integers, and sets condition code 3 (the
overflow flag) if the result overflows. You can get a copy of the POP
here (requires registration):
https://www.ibm.com/support/pages/zarchitecture-principles-operation
> The QEMU bug hypothesis
> looks more probable to me, so I've opened this ticket:
> https://gitlab.com/qemu-project/qemu/-/issues/616
The patch you submitted to QEMU looks reasonable. However, there are
similar bugs in cc_calc_sub_32 and cc_calc_sub_64 that should also be
fixed. I attempted to submit a comment to that effect on the gitlab.com
website but couldn't easily figure out how to make commenting work there.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-12 22:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-30 1:15 timespec test failure on Linux/s390x Bruno Haible
2021-08-30 1:49 ` Paul Eggert
2021-08-30 2:39 ` Bruno Haible
2021-09-12 15:28 ` Bruno Haible
2021-09-12 19:40 ` Paul Eggert
2021-09-12 22:44 ` Bruno Haible
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).