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. 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)
