Once one code path is optimized it is what it is, there can be nothing "slightly different" as long as your code is the same
You have missed my point. For the author, he thinks of "the code" as the C code that he can see. The fact that passing different compiler flags may result in "the code" ending up in different machine code is not something he's used to thinking about. So you have to be careful when explaining such concepts to beginners.
I disagree. Changing FP optimizations is not something that can surprise anybody in producing different results. If the results were exactly the same we wouldn't need different options in the compiler as there wouldn't be a trade off to decide about.
It's the "religious" claims (presenting very well thought-through engineering as if some god, magic or a random number generator is inside, it's not) that motivate some people to say things like "we'll never know." You won't if you approach it dogmatically or fatalisticaly.
When you turn on FP optimizations you say to the compiler "sacrifice some bits here and there, give me more speed." I don't know any manual that explains such options and doesn't make that clear. Counterexamples welcome here too.
I'm not saying you're wrong about what it does, or even about whether it's documented. I'm saying that most compiler optimizations don't behave that way, and I can certainly see this being a surprise to someone who views optimizations generally as correctness-preserving transformations.
Because people may not realize that such things are possible, they may not realize that, say, -ffast-math in gcc is dangerous. Yes, the man page says it right there, but that assumes you know what that means.
You have missed my point. For the author, he thinks of "the code" as the C code that he can see. The fact that passing different compiler flags may result in "the code" ending up in different machine code is not something he's used to thinking about. So you have to be careful when explaining such concepts to beginners.