3 ms·
I do find it bit odd that all the floating point environment control flags are usually pretty well hidden away in most programming languages; I feel those are s
by zokier 4y ago
I do find it bit odd that all the floating point environment control flags are usually pretty well hidden away in most programming languages; I feel those are something that could be more clearly exposed, maybe even as a first-class language feature. But even just having some raii-style scoped environments could be neat
- kccqzy 4y agoIt's that way because processors make it a special register (MXCSR) rather than something that you can specify on a per-operation basis.
- planede 4y agoIMO if it was properly exposed in C, or even as a GNU extension, then "fast math" would be part of the function type. 1. A non-fast-math function calling a fast-math function (or the other way around) should result in the floating point environment to be changed on entering the function, and reset on leaving the function. 2. A function calling an other function of the same kind shouldn't touch the floating point environment. 3. Function pointers to different kind of functions shouldn't be convertible to each other (that is `void ()() __attribute__((fast_math))` and `void ()()` are unrelated types). As for a compiler flag altering the default "fast_math" or "no_fast_math" attribute, I'm not sure about. It's probably a bad idea. Libraries that want to make this configurable can always do their own macro. Altering the floating point environment for everybody in a global constructor within the library is just horrible.