Marking more functions as pure / const

Bruce Evans brde at
Tue Feb 20 05:06:17 UTC 2018

On Mon, 19 Feb 2018, Eitan Adler wrote:

> There are a few functions that are explicitly marked as "not pure2"
> (const) but can be marked as pure. The difference between them is
> "does the function /read/ from global memory?".
> Is there anything wrong with this diff?  Not touched are all the other
> functions which all seem to at least be __pure if not __pure2.

Maybe these functions are even __pure2.  Their pointer arg is output-only,
and gcc docs only emphasize that functions which have pointer args and
examine the data pointed to must not be declared const.

Most of the other functions aren't __pure because they have side effects
on the FP env.  They are further from being __pure2 because they depend
on the FP env.

I don't like the __pure macro.  __pure2 means the gcc-2 syntax for the
original __pure macro.  __pure was reserved for non-use, but someone used
it for something completely different (different syntax and different
meaning).  Spelling gcc2's __const__ as __pure2 and the subtle difference
between __pure2 and the repurposed __pure add to the confusion.

> Index: lib/msun/src/math.h
> ===================================================================
> --- lib/msun/src/math.h (revision 329611)
> +++ lib/msun/src/math.h (working copy)
> @@ -242,11 +242,11 @@ double sinh(double);
> double tanh(double);
> double exp(double);
> -double frexp(double, int *); /* fundamentally !__pure2 */
> +double frexp(double, int *) __pure; /* fundamentally !__pure2 */
> ...

This comment was written to inhibit futher uses of __pure*.  The original
version used __pure, but that seemed to be wrong because there are side
effects.  Now I think it was correct and the comment is wrong.  Another
comment about __pure2 still only says that __pure2 means that there are
no side effects.  The only possible side effects are for signaling NaNs,
and we don't worry about these for functions like fabs*() and declare
fabs*() as __pure2.  The only possible impurity is the pointer arg, but
it is write-only.

The comment is also missing the detail that the FP env affects purity for
input.  This is a larger source of impurity in practice.  The exception
flags are not used as often as the rounding mode.  The rounding mode being
in the FP env means that most math functions do depend on global state,
namely the FP env, so are not __pure2.

Please check if __pure2 applies to write-only pointer args and use it
if possible.  Then no comment here is needed.  Otherwise, change the
comment to say !__pure2 because of the pointer arg.  Update the general
comment about __pure2.  Did it always mean no pointer args?


More information about the freebsd-numerics mailing list