On Wed, 27 Jun 2018, Wilco Dijkstra wrote: > Joseph Myers wrote: > > On Tue, 26 Jun 2018, Wilco Dijkstra wrote: > > > > That looks incorrect indeed but that's mostly a problem with -fmath-errno > > > as it > > > would result in GCC assuming the function is const/pure when in fact it > > > isn't. > > > Does ATTR_MATHFN_FPROUNDING imply that errno is dead after the call? > > > > No, it implies a pure function, so the previous errno value is still live > > after the call. > > OK, so given GLIBC math functions may set errno anyway (irrespectively of the > math-errno setting used), those 2 settings are not sufficient. Ideally you'd > need > to model GLIBC style errno as may or may not be set (still pure since it > doesn't > affect global state but not assuming errno is live afterwards). But perhaps it > doesn't matter since this has been incorrect for years now...
Well, in some cases I think it can be treated as pure with -fno-math-errno, because that option implies functions may or may not set errno. So (in the absence of spurious errno settings from libm functions not encountering errors), if the compiler reuses an errno value from before a libm function call because the function was marked as pure, that's equivalent to the function call not in fact setting errno. The trouble is that (a) generating a read of errno after the call when the actual access in the abstract machine was before the call would be bad if that call in fact sets errno, and (b) each execution of a call in the abstract machine should either execute as if it set errno, or execute as if it did not set errno, and optimizations might not preserve that property. -- Joseph S. Myers jos...@codesourcery.com
