On Fri, Jan 05, 2024 at 03:24:48PM +0100, David Brown via Gcc-help wrote: > On 04/01/2024 17:55, Segher Boessenkool wrote: > >Most things work on function basis; almost nothing works per RTL > >instruction. There is no per-instruction representation for -fwrapv > >in the RTL stream. > > Yes, I appreciate that. And I can also imagine that carrying such > option information in the AST to make this possible would be a > significant burden, and very rarely of benefit - so unless there is some > other important use-case then it is not a good trade-off. Things like -fwrapv and -ftrapv have semantics that naturally could be done per-insn. Many things are not like that :-/ But even then, what is supposed to happen if some optimisation works on a bunch of insns, some with -fwrapv (or -ftrapv) semantics and some not? The only safe thing to do is to not allow any transformations on mixed insns at all. > >Yes, but that is only true for -ffast-math (which means "the user does > >not care about correct results" anyway). > > (Getting a little off-topic... > > Um, that's not what "-ffast-math" means. It means "the user is using > floating point as a close approximation to real number arithmetic, and > promises to stick to numerically stable calculations". All my uses of > floating point are done with "-ffast-math", and I /do/ care that the > results are correct. But the definition of "correct" for my work is "as > close to the theoretical real number result as you can get with a > limited accuracy format, plus or minus small rounding errors". -ffast-math is allowed to introduce any rounding error it wants. Which can (in a loop for example) easily introduce unlimited rounding error, bigger than the actual result. And this is not just theoretical either. Yes, there is a lot of code where this doesn't matter, in practice. How lucky do you feel today? The only way to safely use -ffast-math is to inspect the generated machine code. After each and every compilation you do. And everyone who uses a different compiler version (or is on a different target, etc.) has to do the same thing. > For other people, full IEEE compliance, support for NaNs, and > bit-perfect repeatable results regardless of optimisations and target > details, are important for correctness. And that's fine, and it's great > that gcc supports both kinds of code - though I believe that > "-ffast-math" would actually be more appropriate for a large proportion > of programs.) Most people think that IEEE 754 was a huge step forward over wild west floating point like we used decades ago. Segher
