http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59159
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2013-11-18 Ever confirmed|0 |1 --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- Well, as you want to guard against propagation across FP state changes I'd rather make that explicit (thus, not make it a generic no-op propagation barrier). Of course thinking about a better representation of FP state in the middle-end would be better as requiring the user to pass every value through such a built-in isn't a nice user interface (yeah, better than making up asms ...). __builtin_protect (...) for a generic name, __builtin_protect_fenv (...) for sth more specific. Both need to be type-generic and only result in no overhead when the argument and return value are registers - consider float f1, f2; foo (&f1, &f2); .. = __builtin_protect (f1); .. = __builtin_protect (f2); which would still cause a redundant load that cannot be optimized until RTL optimization at least. I wonder whether a very early pass splitting functions at FENV clobber points and preventing re-inlining would be a better solution in the end (yeah, making them nested with all the optimization side-effects that causes, which also means _very_ early as unnesting happens more or less during gimplification - or you re-invent unnesting in parts at least).