Handle FMA on RISC-V

[hrw]

MathCore, Matrix tests fail on RISC-V:

266 - gtest-math-mathcore-stressMathCoreUnit (Failed)

Discrepancy in PtEtaPhiMVector operations() :
62919.12458590859 != 62919.124585843325 discr = 5 (Allowed discrepancy is 1.7763568394002505e-13)

300 - gtest-math-matrix-testMatrixTSparse (Failed)

Expected equality of these values:
m1
Which is: 80-byte object <90-0A 9E-93 FF-FF 00-00 00-00 00-00 00-00 00-02 04-00 00-00 05-00 00-00 01-00 00-00 00-00 00-00 14-00 00-00 05-00 00-00 00-00 00-00 00-00 B0-3C 01-E2 1E-94 FF-FF 00-00 30-26 61-55 55-55 00-00 00-62 60-55 55-55 00-00 A0-2B 61-55 55-55 00-00>
m2
Which is: 264-byte object <48-76 56-55 55-55 00-00 00-00 00-00 00-00 00-02 04-00 00-00 05-00 00-00 01-00 00-00 00-00 00-00 14-00 00-00 00-00 00-00 00-00 00-00 00-00 B0-3C 01-00 00-00 03-00 00-00 18-2D 44-54 FB-21 09-40 ... 53-B7 49-9E A1-B8 34-40 40-42 AC-EF 82-70 37-40 E0-09 61-55 55-55 00-00 60-E2 1E-94 FF-FF 00-00 50-2A 61-55 55-55 00-00 20-0A 61-55 55-55 00-00 30-E3 1E-94 FF-FF 00-00 60-E1 1E-94 FF-FF 00-00>

422 - test-stressmathcore (Failed) longtest

Based on my experience with similar failures on AArch64 (years ago) I suspected FMA handling. Looked through code and found some places where disabling/handling FMA was needed.

This Pull request:

Changes or fixes:

It is an attempt to get 'root' build properly on RISC-V. Or at least to get some of tests to pass (we still have a list of tests to skip).

Checklist:

• tested changes locally
• updated the docs (if necessary)

[hrw]

We have build on RISC-V koji: https://riscv-koji.fedoraproject.org/koji/taskinfo?taskID=256015

The list of skipped tests:

%ifarch riscv64
# - gtest-io-io-RIoUring
# - gtest-net-net-testParallelMergingFile
# - gtest-tree-ntuple-ntuple-attributes
# - gtest-tree-ntuplebrowse-ntuple-browse
#   Error initializing io_uring: Function not implemented
#
# - gtest-roofit-roofitcore-testRooFitCore
#   Received unexpected diagnostic of severity 4000 at
#   'TUnixSystem::DispatchSignals' reading 'segmentation violation'.
#
# - gtest-roofit-roofitcore-testNaNPacker
# - gtest-roofit-roofitcore-testLikelihoodGradientJob
#   According to the RISC-V ISA specification, the hardware FPU automatically
#   canonicalizes the result of any floating-point operation that yields a NaN
#   into a standard canonical NaN (`0x7ff8000000000000`). This process
#   permanently clears any custom payload bits stored in the mantissa, causing
#   software that relies on bit-preserving NaN manipulation—such as ROOT's
#   `RooNaNPacker`—to fail on arithmetic tests.
excluded="${excluded}|\
gtest-io-io-RIoUring|\
gtest-net-net-testParallelMergingFile|\
gtest-tree-ntuple-ntuple-attributes|\
gtest-tree-ntuplebrowse-ntuple-browse|\
gtest-roofit-roofitcore-testRooFitCore|\
gtest-roofit-roofitcore-testLikelihoodGradientJob|\
gtest-roofit-roofitcore-testNaNPacker"
%endif

[hahnjo]

I don't think it's the right approach to forbid FMA - it will be slower, no? Failing tests are a sign of too tight tolerances...

[hrw]

For now we want this package to build. Previous builds just added failed tests to exclude list.

I decided to try different approach. Without FMA we at least have something which builds and works as expected (so it passes tests).

I am open to other solutions.

[hahnjo]

I maintain that the tests should be fixed. Disabling FMA is a workaround, and if we put it in now nobody will be working to remove it.

[hrw]

Can "root" get some central way to tell "this architecture has FMA precision" instead of forcing any new architecture to reinvent the wheel?

The whole build takes 14 hours on current RISC-V hardware (SpacemiT K3 - the fastest available CPU). The way how it builds (single thread for most of time) does not help.

[hrw]

I will resume my work on root around 20th August.

[github-actions]

Test Results

     4 files       4 suites   12h 45m 58s ⏱️
 3 777 tests  3 771 ✅ 6 💤 0 ❌
14 764 runs  14 764 ✅ 0 💤 0 ❌

Results for commit ede5ce9.