> 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

> 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/addenda32.rst#procedure-call-related-attributes https://github.com/ARM-software/abi-aa/blob/master/addenda32...