I am not quite sure whether the minimum/maximum which also calls this function needs similar treatment. It seems to me that loop is only used for reductions and thus is fine?

Glad you are checking other uses, there were three in the simd file. Looks like the problematic commit was merged last February.

Looks like we are more likely to get more recent hardware on actions.

Yeah, that would explain why it is suddenly so common. I think the other things are fine, but most of our other code just uses dimensions, etc. (variables which are never modified) here. So if that is enough to avoid compiler reordering, (which it probably is due to the volatile flag?), then I should do the same here as it is simpler. E.g.:

npy_clear_floatstatus_barrier((char*)dimensions);

Does the actual value matter as long as it is valid memory? I vaguely recall the discussion about these barrier functions but have forgotten how they worked.

The value doesn't matter, the whole point is that it is types as volatile so that the process can't reorder the instructions/math. I doubt reordering is likely here anyway, since there is a loop, but I am not sure what reorder magic compilers are capable of.

But considering that, I am honestly not sure that a stack allocated value like this is a valid "barrier"...

ISTR that the only reason the variable was passed in was to make volatile work. If so, then it has no other effect.

Thanks Sebastian, lets see if this fixes things.

FWIW, when I put this in I used the compiler explorer to test out what assembly was emitted by different constructs. I added the local variable reference to force the compiler not to reorder the barrier call. It didn't seem to matter what variable I used, as long as the compiler did not optimize it away.

Thanks very much for fixing this - it's actually been causing us a reasonable amount of grief. Given the simple and low-risk nature of the final change, just wondering if it's possible to reconsider it for inclusion in 1.19.5?

We've worked around most occurrences of this issue with some python-level code changes (e.g. using np.real(np.conj(x) * x)) but of course some uses of complex np.abs exist in other libraries which are still tripping us up.

Either way, thanks again!

@tjb900 it is already included in the 1.19.x branch, just waiting for the actual release.

Ah, of course - I misinterpreted the label changes. Thanks.