[PATCH 0/7] riscv64 ptest fixes

[OOHehir <oo.hehir@gmail.com>]

This series re-enables the strace, python3 & tcl8 ptests on riscv64 & fixes the
three riscv64 failures that are not timeouts: lttng-tools, tcl/tcl8 &
python3-numpy. Patches 2, 3 & 6 only edit the riscv64 lists in
ptest-packagelists.inc; patch 1 skips one slow strace test on riscv64 &
patches 4, 5 & 7 carry the fixes.

I sent these results to Khem Raj & Trevor Gamblin before posting. Trevor
suggested profiling the per-test durations under QEMU first; patch 1 skips
the slowest test found (see "Per-test durations" below).

Where to look:
- Patch 7 works round a confirmed GCC 15+ bug:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127908
  GCC moves the float-to-integer conversion above the range check in its
  inline ceil/floor/trunc, so ceil(+-inf) raises FE_INVALID.
  -fno-fp-int-builtin-inexact makes GCC call libm instead.
- Patch 4 carries an lttng-tools fix under review upstream:
  https://review.lttng.org/c/lttng-tools/+/18903
- Patch 5 skips binary-40.3, which expects a negative float NaN to stay negative
  when widened to double. RISC-V returns the positive canonical NaN, as the ISA
  requires. Reported on an existing MIPS ticket:
  https://core.tcl-lang.org/tcl/tktview/bf029ced86

Testing:
- qemuriscv64: testimage of core-image-ptest-<pkg> with the autobuilder's
  PTEST_RUNNER_TIMEOUT of 450 s (a test is killed after 450 s without output),
  on my machine, a Xeon E5-1680 v3 from 2014 (a plough-horse rather than a
  stallion). An autobuilder worker will be faster per core, but busier.
- VisionFive 2 v1.3B (JH7110, 4x U74, 8 GB): each package in
  core-image-minimal, ptest-runner -t 1800.

  package  qemuriscv64                  VisionFive 2
  strace   1081 pass, 0 fail, 24 min    1212 pass, 0 fail
  python3  44546 pass, 0 fail, 71 min   44698 pass, 0 fail
  tcl8     152 pass, 0 fail, 10 min     only failure was binary-40.3

Per-test durations under QEMU (TCG), as the longest time without output is
what the 450 s limit measures:
- strace (make -j4, every output line timestamped): the longest gap is 283 s,
  ending with qual_fault-syscall.test, which patch 1 skips on riscv64. Next are
  filtering_syscall-syntax.test (139 s), trace_creds.gen.test (90 s) &
  strace--tips-full.test (65 s); the rest are under 50 s.
- python3: regrtest -j4 prints a progress line at least every 30 s, so the
  longest gap in the full run is around 30 s. Its slowest modules
  (test_concurrent_futures.test_process_pool, about 17 min, & the
  test_multiprocessing_* modules, 6-11 min) are made of many short cases: run
  one at a time, no single case takes over 71 s (MiscTestCase.test_large_pool,
  69-71 s in each start method). So I have not skipped anything there.
- tcl8: tcltest prints once per test file. The longest is reg.test (115 s),
  then regexp.test (70 s) & io.test (45 s).

Still parked: tcl, lttng-tools, perl, python3-cffi, libpcap & zstd pass, but
are too slow for the 450 s limit on my machine. Under TCG (QEMU's software CPU
emulation), ptest-runner kills tcl in unicodeNormalize.test, lttng-tools in
test_valid_filter, perl in t/re/regexp_qr_embed_thr (485 s alone, so perl may
pass on a faster worker) & python3-cffi, each after 450 s without output.
libpcap's run-ptest prints nothing until TESTrun finishes, which takes 9.5 min
even on the board. zstd's compression/window-resize.sh exceeds the 200 s
per-case limit in cli-tests.

To confirm that these fail only on time, I reran them under QEMU with this
series, PTEST_RUNNER_TIMEOUT = "7200" & the cli-tests limit raised to 3600 s
(local changes, not in this series). All passed with 0 failures, as they do on
the board:

  zstd           43 pass            10 min
  libpcap        14801 pass         24 min
  tcl            175 test files     46 min
  lttng-tools    2088 pass          85 min
  python3-numpy  45769 pass        104 min
  python3-cffi   1724 pass         187 min
  perl           2729 pass         219 min

python3-numpy stays parked too: patch 7 fixes its only failure (72 cases of
test_unary_spurious_fpexception), but under the 450 s limit numpy 2.5.4 is
killed before pytest prints its first result.

glib-2.0 is left parked. It passed one run on QEMU (308 pass, 31 min) & on the
board, but it was parked for intermittent failures, which one run cannot rule
out:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15891
https://bugzilla.yoctoproject.org/show_bug.cgi?id=16230

The numpy results above are for 2.5.3, before the rebase. numpy 2.5.4 with
patch 7, under QEMU with the 7200 s limit: 45993 pass, 0 fail, 87 min. One
earlier 2.5.4 run had a single failure, a wall-clock check in f2py
(test_nameargspattern_backtracking) that requires a regex search to take under
0.2 s & measured 0.22 s under TCG; it passed on the rerun.

OOHehir (7):
  strace: skip qual_fault-syscall.test on riscv64
  ptest-packagelists.inc: re-enable strace for riscv64
  ptest-packagelists.inc: re-enable python3 for riscv64
  lttng-tools: skip kernel cases when kernel tests are disabled
  tcl, tcl8: skip binary-40.3 on RISC-V
  ptest-packagelists.inc: re-enable tcl8 for riscv64
  python3-numpy: call libm for ceil/floor/trunc on riscv64

 .../distro/include/ptest-packagelists.inc     |   7 +-
 .../python/python3-numpy_2.5.4.bb             |   7 ++
 meta/recipes-devtools/strace/strace_7.2.bb    |  13 +++
 meta/recipes-devtools/tcltk/tcl/run-ptest     |   5 +
 meta/recipes-devtools/tcltk8/tcl8/run-ptest   |   5 +
 ...our-LTTNG_TOOLS_DISABLE_KERNEL_TESTS.patch | 108 ++++++++++++++++++
 .../lttng/lttng-tools_2.16.0.bb               |   1 +
 7 files changed, 141 insertions(+), 5 deletions(-)
 create mode 100644 meta/recipes-kernel/lttng/lttng-tools/0001-tests-honour-LTTNG_TOOLS_DISABLE_KERNEL_TESTS.patch

-- 
2.43.0