OMP vs NOOMP bit-comp fail at qsat call with CCE high

[MichaelWhitall]

Hi folks,

One of my tickets is currently getting a "pink fail" in rose stem due CCE high NOOMP changing answers (only at the level of floating-point rounding error), but CCE high OMP preserving KGO exactly, so that the two have diverged. I've traced the change in answers for the NOOMP run to a call to qsat in pc2_bm_initiate.F90, and have confirmed that all the inputs to that qsat call were identical between the OMP and NOOMP runs. Ticket (and link to the dev branch) are here:
UM:#7407

The qsat call that is changing answers is the one now at L703 of pc2_bm_initiate.F90 (and strangely only that one, not the virtually identical one at L727).

Presumably this is happening because CCE has started making a different choice about how to optimise the affected qsat call depending on whether using OMP or not (I have heavily refactored the surrounding code in order to add new functionality under switches). I've heard of this happening before, but not sure how to fix it.

Does anyone know how to force CCE to make the same optimisation choices with and without OMP? Is there a compiler directive or something?

Cheers!
Mike

[MichaelWhitall]

An update; I had a vague recollection that this problem has happened before elsewhere, and turned out to be a Cray compiler issue associated with inlining subroutine calls. So I took a wild guess and added
!DIR$ NOINLINE
before the offending qsat call. This seems to fix the problem (both the OMP and NOOMP runs now preserve KGO and bit-compare with eachother). But does anyone know how bad disabling inlining is for optimisation / whether there might be an alternative fix that's more optimal?