[Tim]
A *good* compiler won't collapse *any* fp expressions at compile-time ...
[Martin von Loewis]
Of course, that doesn't say anything about what *most* compilers do.
Doesn't matter in this case; I told /F not to worry about it having taken that all into account. Almost all C compilers do a piss-poor job of taking floating-point seriously, but it doesn't really matter for the purpose /F has in mind. [an example of gcc precomputing the best possible result]
return (double)1/6; ... .long 0x55555555,0x3fc55555
No problem. If you set the HW rounding mode to +infinity during compilation, the first chunk there would end with a 6 instead. Would affect the tail end of the repr(), but not the str().
... when compiling with -fomit-frame-pointer -O2. That still doesn't say anything about what most compilers do - if there is interest, we could perform a comparative study on the subject :-)
No need.
The "would break 754" argument is pretty weak, IMO - gcc, for example, doesn't claim to comply to that standard.
/F's question was about fp. 754 is the only hope he has for any x-platform consistency (C89 alone gives no hope at all, and no basis for answering his question). To the extent that a C compiler ignores 754, it makes x-platform fp consistency impossible (which, btw, Python inherits from C: we can't even manage to get string<->float working consistently across 100% 754-conforming platforms!). Whether that's a weak argument or not depends entirely on how important x-platform consistency is to a given app. In /F's specific case, a sloppy compiler is "good enough". i'm-the-only-compiler-writer-i-ever-met-who-understood-fp<0.5-wink>-ly y'rs - tim