JavaScript's parseInt and parseFloat return NaN on something as benign as "well, that wasn't a number". var jsonish = "..."; var number = parseFloat(js

JavaScript's parseInt and parseFloat return NaN on something as benign as "well, that wasn't a number". var jsonish = "..."; var number = parseFloat(jsonish); if (!isNaN(number)) { // deserialized a number } else { // ...try deserializing as a boolean or string next... } Fast math optimizations can break code like this by breaking isNaN. I was porting a C++ project to a certain platform - and that platform enabled a -ffast-math equivalent by default in Release (but not Debug) builds! This broke duktape, a JS engine said project embedded, in some nasty and subtle ways. Instead of storing a number/pointer/??? (8 bytes) + type tag (4? bytes) for each dynamically typed JS value, duktape can bit-pack values into a single 8 byte "double" value by storing object/string handles as NaN values - this isn't an uncommon trick for dynamically typed scripting stuff: https://github.com/svaarala/duktape/blob/c3722054ea4a4e50f485516c70167e323636d9db/src-input/duk_tval.h https://github.com/svaarala/duktape/blob/c3722054ea4a4e50f48... Naturally, the -ffast-math equivalent broke isNaN checks, which caused random object/string handles to be mistakenly reinterpreted as "numbers" - but only in Release builds, for this one particular platform, in one rarely taken branch, so neither QA nor CI caught it, leading to hours of manufacturing a repro case, stepping through an absurd amount of code, and then finally looking at the default build rules and facepalming. Cursing the platform vendor under my breath, I overrode the defaults to align with the defaults of every other config x platform combination we already had: no fast math. If you want those optimizations, use SSE-friendly NaN-avoiding intrinsics - or, if you must use the compiler flags, ensure you do so consistently across build configs and platforms, perhaps limited to a few TUs or modules if possible. This allows you to have a chance at using your Debug builds to debug the resulting "optimizations".