https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
--- Comment #12 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Marc Glisse from comment #11) > Since I had forgotten where it was, let me write here that it is git branch > /users/glisse/fenv Since it became impossible (hooks) to push to that branch a while ago, I should post somewhere the FIXME file I couldn't push last year: Looking at LLVM, I notice that my design in the gcc fenv branch seems to be missing a fundamental piece: it has nothing preventing "normal" operations from outside from migrating towards the protected region, where they may end up using an unexpected rounding mode (unprotected doesn't mean any rounding mode, it means the default one), or setting flags that we will observe. One idea to prevent this would be to make sure that there are no normal FP operations in functions that have protected operations (does that mean we should mark functions? Just checking if there is a protected FP op doesn't work if we call a function that does the op). This means that we should turn all FP operations of the function into protected ones (possibly with more relaxed flags if they are not in the protected region), and we should also do that whenever inlining mixed functions. And cross my fingers that the compiler doesn't start using FP ops out of thin air. Would that be sufficient?
