On Mon, Oct 11, 2021 at 11:28:39AM -0500, Segher Boessenkool wrote: > On Mon, Oct 11, 2021 at 08:46:17AM -0500, Paul A. Clarke wrote: > > On Fri, Oct 08, 2021 at 05:31:11PM -0500, Segher Boessenkool wrote: [...] > > > > With respect to volatile, I worry about removing it, because I do > > > > indeed need that instruction to execute in order to clear the FPSCR > > > > exception enable bits. That side-effect is not otherwise known to the > > > > compiler. > > > > > > Yes. But as said above, volatile isn't enough to get this to behave > > > correctly. > > > > > > The easiest way out is to write this all in one piece of (inline) asm. > > > > Ugh. I really don't want to go there, not just because it's work, but > > I think this is a paradigm that should work without needing to drop > > fully into asm. > > Yes. Let's say GCC still has some challenges here :-( > > > Is there something unique about using an "asm" statement versus using, > > say, a builtin like __builtin_mtfsf or a hypothetical __builtin_mffsce? > > Nope. > > > Very similar methods are used in glibc today. Are those broken? > > Maybe.
Ouch. > If you get a real (i.e. not inline) function call there, that > can save you often. Calling a real function in order to execute a single instruction is sub-optimal. ;-) > > Would creating a __builtin_mffsce be another solution? > > Yes. And not a bad idea in the first place. The previous "Nope" and this "Yes" seem in contradiction. If there is no difference between "asm" and builtin, how does using a builtin solve the problem? PC
