extended precision mlm_matching_isr fails with gfortran 7.0.1

[Juergen Reuter]

308,309c308,309
< Sum of beam remnant momenta: p(0:3) =      905.339        0.000        0.000     -295.747 
< Sum of outgoing momenta: p(0:3) =         1054.661        0.000        0.000      295.747 
---
> Sum of beam remnant momenta: p(0:3) =     1440.726        0.000        0.000        2.215 
> Sum of outgoing momenta: p(0:3) =          519.274        0.000        0.000       -2.215 
315,316c315,316
< Sum of beam remnant momenta: p(0:3) =      443.986        0.000        0.000      -18.939 
< Sum of outgoing momenta: p(0:3) =         1516.014        0.000        0.000       18.939 
---
> Sum of beam remnant momenta: p(0:3) =      303.860        0.000        0.000       11.261 
> Sum of outgoing momenta: p(0:3) =         1656.140        0.000        0.000      -11.261 

[Juergen Reuter]

This has been reported to the gcc/gfortran team as we believe that it is a problem with the optimiser: ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 The bug goes away when compiled with -fno-inline and also with -Wall. There are some things that are suspicious like e.g. mixing of types in the max statement within the shower_get_pdf function that is used in integral_over_z_part_isr. Also, when trying to call the mother subroutine, shower_step_isr from another routine in order to build a smaller test case, the problem goes away. Promoting shower_step_isr to a TBP of shower_t does not solve the problem.

[Juergen Reuter]

As Steve Kargl suggested, making the attribute of the integral variable in the shower functions volatile prevents the compiler from optimising the dangerous if-clause away.

[Juergen Reuter]

Milestone renamed