https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
--- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to jos...@codesourcery.com from comment #6) > Generically (and if the command-line options are such that floating-point > control / status bits are to be respected by optimizations), *any* > function call might access or modify floating-point control and status > bits, subject to e.g. const functions not being able to access them, pure > functions not being able to modify them, functions whose body is known > having properties based on analysis of that body, built-in functions > having semantics based on what the compiler knows about those functions. If FENV_ACCESS is OFF most of those things can be ignored as well. But FENV_ACCESS is much too blunt a hammer for most of our uses. > And then a subset of asms may similarly access or modify them (based on > inputs / outputs / clobbers, but maybe on some architectures existing > practice doesn't provide a register name that inputs / outputs / clobbers > can use to refer to floating-point state). Like PowerPC. But we *do* model vscr (vector status and control register). It won't be hard to add fpscr. > Then you'd need something like Marc Glisse's -ffenv-access patches (August > 2020) to represent the other side of things, how floating-point operations > also access / modify such bits. Yeah, we need something for normal computational FP insns to clobber (on PowerPC load/store insns never change the fpscr / fenv, but I bet that is different on other archs). Thanks for the pointer, I'll find Marc's work.
