> The ARM architecture floating point units (VFP, NEON) support RunFast mode, which includes flush-to-zero and default NaN. The latter means that payload of NaN operands is not propagated, all result NaNs have the default payload, so in R, even NA * 1 is NaN. Luckily, RunFast mode can be disabled, and when it is, the NaN payload propagation is friendlier to R NAs than with Intel SSE (NaN + NA is NA). We have therefore updated R to disable RunFast mode on ARM on startup, which resolved all the issues observed.

Hmm. ELF object files for Arm can represent this with build attributes [1]:

    Tag_ABI_FP_denormal, (=20), uleb128
        0  The user built this code knowing that denormal numbers might be flushed to (+) zero
        1  The user permitted this code to depend on IEEE 754 denormal numbers
        2  The user permitted this code to depend on the sign of a flushed-to-zero number being
           preserved in the sign of 0

    Tag_ABI_FP_number_model, (=23), uleb128
        0  The user intended that this code should not use floating point numbers
        1  The user permitted this code to use IEEE 754 format normal numbers only
        2  The user permitted numbers, infinities, and one quiet NaN (see [RTABI32_])
        3  The user permitted this code to use all the IEEE 754-defined FP encodings

Seems like their code should be tagged Tag_ABI_FP_denormal = 1, Tag_ABI_FP_number_model = 3 if it were an ELF .o, .so, or executable, in which case <waves hands> some other part of the toolchain or system would automatically configure the floating point unit to provide the required behavior.

Does Mach-O have a similar mechanism?

[1] https://github.com/ARM-software/abi-aa/blob/master/addenda32...