Fix SIGFPE crash (855) in rotxxx by adding volatile in aloha_functions.f

[valassi]

Hi @oliviermattelaer I think this is ready for review, can you please have a look?

This fixes the SIGFPE crash in rotxxx (#855, also mentioned in #826 - and maybe this is also related to what you discuss as a crash in #852?). It uses an ugly workaround of just adding 'volatile' to disable optimizations (from SIMD?) deep inside the fortran code. Ugly, but it works, and has no performance penalties I think here. And this is also exactly the same technique I used to fix many SIGFPEs in cudacpp in the ixx/oxx functions last here.

It also slightly modifies my test scripts to enable testing a different config which is not 1. I do not understand why the SIGFPE crash only seems to happen with some specific iconfig (which may also have other issues), but it seems wuite clear that the issues are independent. Rephrasing: I would add volatile in any case, and then go on and investigate channel/iconfig mappings as in your #853.

Note, this IMO brings us one step of progress, but other issues remain open

• the susy_gg_t1t1 still has no cross section (No cross section in SUSY gg_t1t1 log file #826)
• after fixing the SIGFPE crash, iconfig 104 in SM gg_ttgg gives an LHE color mismatch (MAJOR ISSUE: color mismatch fortran/cpp in LHE file for iconfig 104 in SM gg_ttgg (channel/iconfig mapping AND icolamp issues) #856)
  As mentioned above, I would go ahead and add volatile, and then investigate the rest.

I will still run large scale tests tonight, but the code will almost certainly not change. So this is ready for review. Thanks.
Andrea

[valassi]

Hi @oliviermattelaer I completed my tests and I confirm that adding volatile fixes this SIGFPE in rotxxx (the code was crashing without and is not crashing with volatile).

There is no performance change, or at most a 1-2% negligible change.
See 346c9df

Can you please review and approve? Thanks Andrea

[valassi]

But to be honest, I'm worried about why we have such sigfpe suddenly here (and not in the pure fortran code).

On this specific point: note that there is one difference:

• pure fortran madevent does not link cudacpp: by default, SIGFPE will not cause crashes (but they should be summarised as a warning in the end?)
• fortran/cudacpp links cudacpp, which amongst other things instructs SIGFPE to cause crashes

It is far fetched, but one possible explanation is

• rotxxx in optimized code uses somthing (SIMD?) which triggers a SIGFPE, and this is true whethere or not we link cudacpp: remember, if we turnoff optimization the issue disappears
• the SIGFPE only triggers a crash if we link cudacpp, where we agreed to crash on SIGFPEs
• volatile helps prevent the SIGFPE in the first place, which is perfectly understandable in case this is coming from fortran SIMD in the first place (we see all the time in cudacpp simd)

[valassi]

I have merged the latest upstream/master and have rerun the CI which now includes tmad tests.

In upstream/master, the CI had 12 failures: 9 from rotxxx crashes, and 3 from no cross section in susy.

In this branch, now the 9 rotxxx failures have disappeared, while the 3 no cross sections have stayed.
THIS SHOWS THAT ADDING VOLATILE DOES WORK.
In addition, 3 new issues have appeared in pp_tt012j (#872).

(Note also: after removing rotxxx crashes, I was expecting other issues to appear, but they did not apart from #872 above. In particular I thought that #856 would appear. Maybe these only exist in manual tests, I will cross check... or maybe for that one I need to use iconfig 104.)

[valassi]

OK I will do the rotxxx patch in the upstream mg5amcnlo. I reopen this one anyway (in WIP). I will include here the upgrade to the new mg5amcnlo when it is done. (And I am curious to see already what my new CI gives if the volatile are included).

I have now completed the move of 'volatile' from cudacpp patch.common to the upstream mg5amcnlo in the gpucpp branch, pending this PR mg5amcnlo/mg5amcnlo#113

The generated code is the same (well I just changed a comment), the results do not change

As mentiond above, the rotxxx crashes disappear from the CI, while a new xsec discrepancy #872 appears. I will also try to make issue #856 appear in the CI (and possibly another one).

This will soon be ready for review.

[valassi]

I configured the tmad test for gg_ttgg to use iconfig=104. Issue #856 (LHE color mismatch in gg_ttgg for iconfig=104) is now appearing in the CI. (NB THIS ONLY APPEARS IF ROTXXX IS FIXED) See #856 (comment)

NB there are now 9 errors in the CI, three fptype for each of the following three issues

• no cross section No cross section in SUSY gg_t1t1 log file #826 in susy_gg_t1t1
• LHE color mismatch MAJOR ISSUE: color mismatch fortran/cpp in LHE file for iconfig 104 in SM gg_ttgg (channel/iconfig mapping AND icolamp issues) #856 in gg_ttgg
• xsec discrepancy Cross section mismatch in pp_tt012j (P2_gu_ttxgu) in CI tmad tests - reset_cumulative_variable was called twice in fortran and once in cudacpp #872 in pp_tt012j

[valassi]

I have added the 3x3 issues mentioned above to the list f known issues to bypass.
In that case, the CI tests succeed:

I will now disable these bypasses (so that tests fail in the CI). Then this is ready to be merged.

[valassi]

I have disabled bypasses, now 9 tests fail as expected. This is ready to be merged.

@oliviermattelaer can you please review/approve?
NB: there is no CODEGEN change. Effectively this is ONLY the update to the upstream including volatile (and regenerated code, plus history and logs).

[oliviermattelaer]

Yes let's merge this,

Olivier

[valassi]

Thanks! I will merge this now Andrea