On 04/01/2024 17:55, Segher Boessenkool wrote:
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.
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 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).
(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".
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.)
You would not typically want random nearby code to use -fwrapv as well,
for example.
No, not normally. (Some people would like C to work that way, but not me!)
Segher
