coreutils-9.4.185-541b02 tail/retry test failure

2024-03-27 Thread Bruno Haible
On two machines (Linux/sparc64 and Linux/riscv64, real hardware, Gentoo) I see reproducible test failures of tail/retry. See attached log files. I do *not* see these failures with architectures in the same farm (matoro.tk). I also do *not* see these failures in QEMU VMs with a local (surely ext4)

Re: coreutils-9.4.185-541b02 od/od-multiple-t test failure

2024-03-27 Thread Pádraig Brady
On 27/03/2024 12:03, Bruno Haible wrote: The tests/od/od-multiple-t.sh test fails on - Linux/ia64 (Gentoo, recent glibc, real hardware) - Linux/m68k (Debian 12, QEMU emulated) The first 'od' invocation that causes fail=1 to be set is: $ seq 19 > input $ ./od -An -taz -tfLz input 1 nl

Re: coreutils-9.4.185-541b02 od/od-multiple-t test failure

2024-03-27 Thread Bruno Haible
Pádraig Brady wrote: > The original bug report was not specific to floats, so I'll just remove them > from the test. I think it is enough to remove the 'long double' part from the test (option letter 'L'). 'float' and 'double' are standardized by IEEE 754 (except on Linux/m68k) and don't have und

Re: coreutils-9.4.185-541b02 od/od-multiple-t test failure

2024-03-27 Thread Pádraig Brady
On 27/03/2024 12:35, Bruno Haible wrote: Pádraig Brady wrote: The original bug report was not specific to floats, so I'll just remove them from the test. I think it is enough to remove the 'long double' part from the test (option letter 'L'). 'float' and 'double' are standardized by IEEE 754

Re: coreutils-9.4.185-541b02 od/od-multiple-t test failure

2024-03-27 Thread Bruno Haible
Pádraig Brady wrote: > > I think it is enough to remove the 'long double' part from the test > > (option letter 'L')... > > Pushed that in your name at: > https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=bec53850b Thank you. Yes, that's what I meant :-) I confirm that it fixes the t

Re: coreutils-9.4.170-7b206 undefined behaviour in tests

2024-03-27 Thread Kaz Kylheku
On 2024-03-24 07:20, Bruno Haible wrote: > I have proposed a fix for this in > , > but Paul Eggert opposes it. I took a look. There are reasons not to like it. It introduces a PTR_ADD(p, x) abstraction which is only different f