On Thu, 2 Jul 2026, Marc Glisse wrote: > Richard Biener: > > > One complication of #pragma FENV access is that the restrictions > > of placement is too lose as we can properly only support > > at most per-function level changes via options. > > I am not sure about that. Supporting even the per-function level is not > really doable with the current representation of FP operations in gcc. > The closest I can think would be replacing (in the front-end) every FP > operation by a call to a noipa function that does the actual operation, > marking the whole function noipa, and possibly more to protect from > other functions called from there.
Yeah, I think the path of least resistance would be to introduce internal functions for IEEE flag setting operations, possibly "rich", as in having input and output of flag register(s) and argument(s) specifying the EH operations in effect. There's the old issue of GIMPLE and multiple register outputs, and things like regular function calls would not have IEEE flag inputs/outputs. Those regular calls are also fegetexceptflag and friends, so we can't really ignore this. But modeling the flag reg as global memory will be difficult, esp. as we go towards representing this on the RTL side where at least scheduling has to be aware of this. It also makes "not doing -O0" more difficult. There's a similar other case, 'errno', which is in the way of optimizations. So any good design might help both. Richard. > Once we add a new way to represent FP operations, it can specify per > operation if the rounding is up/nearest/dynamic/don'tcare, if the > exceptions are must/mustnot/don'tcare (possibly several values for > different exceptions?), etc. Using #pragma STDC FENV_ACCESS may opt in > the whole function (and any function this gets inlined into) to the new > representation (migrating operations from outside the region to inside > could for instance generate spurious flags), but it does not set the > same flags on the operations originally in the outer region, and > different optimizations are possible for inside/outside (and we could > offer something more fine-grained than fenv_access). I am not sure how > realistic this is though. > > (anyway, if someone found a way to implement fenv_access at the function > level without making it imply -O0, I certainly wouldn't complain) > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald; (HRB 36809, AG Nuernberg)
