On Thu, Jan 04, 2024 at 04:24:20PM +0100, David Brown via Gcc-help wrote: > In my case, I wrote it in that second version! But had "-fwrapv" worked > through inlining, it would have been convenient and neat, especially as > I had several related functions (for a wrapping-integer class). Most things work on function basis; almost nothing works per RTL instruction. There is no per-instruction representation for -fwrapv in the RTL stream. Things are even worse for -O2 vs. -O3 etc. > More generally, I think the expected semantics are that the additional > options apply to code inside the function, and at the boundary you don't > care which set of options apply. So if you have normal floating point > code that sets "x", and then call an inline function with -ffast-math > using "x" as a parameter and returning "y", then the inlined could can > assume "x" is finite and not a NaN, and the later code can assume the > returned value "y" is similarly finite. If the calculations for "x" > produce a NaN, then the code will be UB - that's the programmer's fault. Yes, but that is only true for -ffast-math (which means "the user does not care about correct results" anyway). You would not typically want random nearby code to use -fwrapv as well, for example. Segher
