Can you elaborate? What fast-math can sneak into a library that disabled fast-math at compile time?
> fast-math enables some dynamic initialization of the library that changes the floating point environment in some ways.
I wasn’t aware of this, I would love to see some documentation discussing exactly what happens, can you send a link?
But you're correct that it's probably usually fine in practice.
A lot of library code is in headers (especially in C++!). The code in headers is compiled by your compiler using your compile options.
But yeah, it's probably a good idea to not put code which breaks under -ffast-math in headers if possible.
Hey I grant and acknowledge that using fast-math carries a little risk of surprises, we don’t necessarily need to try to think of corner cases. I’m mostly pushing back a little because using floats at all carries almost as much risk. A lot of people seem to use floats without knowing how inaccurate floats are, and a lot of people aren’t doing precision analysis or handling the exceptional cases… and don’t really need to.
Turn on fast-math, it flips the FTZ/DAZ bit for the entire application. Even if you turned it on for just a shared library!
Small nit, but floats aren't inaccurate, they have non uniform precision. Some float operations can be inaccurate, but that's rather path dependent...
One problem with -ffast-math is that a) it sounds appealing and b) people don't understand floats, so lots of people turn it on without understanding what it does, and that can introduce subtle problems in code they didn't write.
Sometimes in computational code it makes sense e.g. to get rid of denorms, but a very small fraction of programmers understand this properly, or ever will.
I wish they had named it something scary sounding.
"Some times" here being almost all the time. It is rare that your code will break without denormals if it doesn't already have precision problems with them.