Date: Thu, 8 Jul 2004 20:33:27 -0700 From: David Schultz <das@FreeBSD.ORG> To: src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/msun/src math.h Message-ID: <20040709033327.GA14984@VARK.homeunix.com> In-Reply-To: <200407090331.i693VAIL038494@repoman.freebsd.org> References: <200407090331.i693VAIL038494@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 09, 2004, David Schultz wrote: > das 2004-07-09 03:31:09 UTC > > FreeBSD src repository > > Modified files: > lib/msun/src math.h > Log: > Define the following macros in terms of [gi]cc builtins when the > builtins are available: HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY, > and NAN. These macros now expand to floating-point constant > expressions rather than external references, as required by C99. > Other compilers will retain the historical behavior. Note that > it is not possible say, e.g. > #define HUGE_VAL 1.0e9999 > because the above may result in diagnostics at translation time > and spurious exceptions at runtime. Hence the need for compiler > support for these features. > > Also use builtins to implement the macros isgreater(), > isgreaterequal(), isless(), islessequal(), islessgreater(), > and isunordered() when such builtins are available. > Although the old macros are correct, the builtin versions > are much faster, and they avoid double-expansion problems. The Intel compiler is too smart for its own good sometimes. I kept wondering why, despite icc's lack of a __builtin_isgreater(), it seemed to be using one anyway. It turns out that it had done some constant propagation and determined the value of my call to the libm routine __fpclassifyd() statically. Pretty spiffy.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040709033327.GA14984>