user_prc_threshold test failing on MAC OS X with fortran 6.0.0

[Juergen Reuter]

107,119d106
< | 
< | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
< |  Initialize e+e- => ttbar threshold resummation:
< |  Use analytic (LL) or TOPPIK (NLL) form factors for ttA/ttZ vector
< |  and axial vector couplings (S/P-wave) in the threshold region.
< |  Cf. threshold shapes from A. Hoang et al.: [arXiv:hep-ph/0107144],
< |  [arXiv:1309.6323].
< |  Numerical NLL solutions calculated with TOPPIK [arXiv:hep-ph/9904468]
< |  by M. Jezabek, T. Teubner.
< | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
< | 
< | Opening grid file: SM_tt_threshold.grid
< | Threshold setup unchanged: reusing existing threshold grid.
227,239d213
< | 
< | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
< |  Initialize e+e- => ttbar threshold resummation:
< |  Use analytic (LL) or TOPPIK (NLL) form factors for ttA/ttZ vector
< |  and axial vector couplings (S/P-wave) in the threshold region.
< |  Cf. threshold shapes from A. Hoang et al.: [arXiv:hep-ph/0107144],
< |  [arXiv:1309.6323].
< |  Numerical NLL solutions calculated with TOPPIK [arXiv:hep-ph/9904468]
< |  by M. Jezabek, T. Teubner.
< | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
< | 
< | Opening grid file: SM_tt_threshold.grid
< | Threshold setup unchanged: reusing existing threshold grid.

[Juergen Reuter]

Apparently, for MAC OS X with gfortran 6.0 there is a re-initialization for the processes user_prc_threshold_p3 and _p4, but not with the other compilers. Why?

[Juergen Reuter]

This is - again - not a problem of gfortran 6, it also happens with gfortran 4.9. It is most probably a problem with the single pass linker. Can we please have in the future smaller steps in the commits such that we can break down what is causing the trouble!?

[Juergen Reuter]

On Linux with 4.7.4 before commit 7333/4 it was also re-initializing in user_prc_threshold_p2 so if you find out why that stopped we are having the problem on the MAC.

[Juergen Reuter]

We couldn't trace down the true cause for the chain of linking on MAC OS X (and BSD) and removed the condition on the initialization in such that the initialization is always called in the SM_tt_threshold model (which is in any case not intended for many processes to be run in parallel). Done in r7338. Closing.