Several fixes for icx2023.2 (including fixes for sqrt FPEs in ixx/oxx/vxx)

[valassi]

This MR includes a few minor fixes for new platforms (#734), in particular icx2023.2 and clang16

• increase tolerance for rambo momenta in comparison tests RAMBO is unstable in single precision #735 (this also affects gcc)
• workaround for FPE in testxxx in icx 2023.2 Floating point exceptions in testxxx using icx2023.2 (FPEs from sqrt in ixxx/oxxx/vxxx) #736
• add wrappers for clang16 compilation

[valassi]

This has become another very complex FPE fixing campaign... and not only in ixx/oxx/vxx. The icx optimizer, based now on clang17, is doing even more strange stuff. In some cases I have data which is supposed to be exactly 0 and I am unable to take a sqrt of that, so I do it ONLY if it is GREATER than 0.

Rerunning all tests tonight. Hopefully it looks better.

[valassi]

I have rerun all tests overnight - now all FPEs are fixed in icpx.

I have also made minor changes in the gtest handling of compiler-specific build directories (#125 and #738) for allwoing backward compatibility to epoch1/epoch2, which were previously failing the CI

This is now ready, I will self-merge. I will document the full contents a posteriori

[valassi]

I have merged this MR #737 with another set of comprehensive FPE fixes. Here's some documentation

• This started off as a very minor port of the code to the latest icx2023.2 from cvmfs (see Test builds with newer compilers (gcc13, clang16, icpx2023.2...) #734). I added a few wrapper scripts also for clang16.
• I increased the tolerance for RAMBO momenta comparisons from 3E-2 to 4E-2 in single precision. This closes RAMBO is unstable in single precision #735.
• What took me again a long time was, again, new FPEs. In MR Fixes in xxxxx for IEEE_DIVIDE_BY_ZERO FPE; separate cpu/gpu namespaces and fix runtest segfault #723 (related to Four floating point exceptions in CPP launch of pp_ttW (IEEE_DIVIDE_BY_ZERO FPE in vxxxxx function in SIMD mode) #701 Ensure clang and icc builds are also ok with the new ixx/oxx/vxx #724 Disabling auto vectorization in ixx/oxx causes a loss of performance #727) I had implemented many fixes for floating point exceptions in SIMD divisions by zero, in some cases using the volatile keyword, which had been triggered in part by the clang (and icx 2023.1?) optimizers. In moving from icx2023.1 to icx2023.2 (which implies internally a move from clang16 to clang17), the optimizer has now triggered new floating point exceptions around sqrt operations, possibly around sqrt of negative values. As in my previous patch, most changes were in the ixx/oxx/vxx hardcoded functions, and again I fixed these with a generous use of volatile. However there were also FPEs in the test infrastructure itself, and I also added sqrt functions with volatile arguments to the fptype/vector headers. In some cases, I had a hard time understanding why there was a problem at all. Anyway, these are all fixed. This closes Floating point exceptions in testxxx using icx2023.2 (FPEs from sqrt in ixxx/oxxx/vxxx) #736.
• While doing these tests, at some point I got an FPE deep down in libm, called by the googletest framework. This was when using ggogletest built with gcc, against madgraph4gpu in icx. For lack of better ideas, I tried to do a clean compiler-dependent rebuild of googletest with separate directories (as I had suggested already in GoogleTest library should be rebuilt when changing compiler #125). This fixed the issue, and I kept this in production. I even implemented a backward-compatible mechanism for epoch1/epoch2 in the CI, just in case. This fixes FPE in icpx tests when gtest was built with a different compiler #738.

It should also be noted that another whole set of FPEs is still pending in #733. These are invalid (sqrt?), underflow and overflow FPEs. Initial investigations in WIP MR #706, in any case, suggest that this is due to some bug in coupling propagation in non-SM processes, rather than to the ixx/oxx/vxx functions. To be followed up... that is high priority as it is a blocker for ATLAS pp->ttW.

Volia that's all for the documentation of this MR.

cc @roiser @oliviermattelaer @hageboeck @Jooorgen @zeniheisser