Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Feb 2003 21:42:23 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        David Schultz <dschultz@uclink.Berkeley.EDU>
Cc:        Lukas Ertl <l.ertl@univie.ac.at>, <standards@FreeBSD.ORG>
Subject:   Re: C99 floating point macros
Message-ID:  <20030209200824.R24643-100000@gamplex.bde.org>
In-Reply-To: <20030209003350.GA20683@HAL9000.homeunix.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Feb 2003, David Schultz wrote:

> Thus spake Lukas Ertl <l.ertl@univie.ac.at>:
> > Ok, please review the following patch. I hope I didn't take it too easy.
>
> Hmm...why not just use some macros, like this?
>
> #define	isgreater(x, y)		(!isunordered((x), (y)) && (x) > (y))
> #define	isgreaterequal(x, y)	(!isunordered((x), (y)) && (x) >= (y))
> #define	isless(x, y)		(!isunordered((x), (y)) && (x) < (y))
> #define	islessequal(x, y)	(!isunordered((x), (y)) && (x) <= (y))
> #define	islessgreater(x, y)	(!isunordered((x), (y)) && \
> 					((x) > (y) || (y) > (x)))
> #define	isunordered(x, y)	(isnan(x) || isnan(y))

If there were no signaling NaNs, then the even simpler macros:

	#define	isgreater(x, y)		((x) > (y))

etc., would work on i386's at least, since gcc generates comparison
instructions (fucom, not fcom) which don't raise the invalid exception
(IE) for quiet NaNs.

However, not raising IE for signaling NaNs seems to be necessary (to
support C99's interpretation of IEC 60559:1989).  At least on i386's,
this is handled by isunordered() above provided we unbreak isnan() so
that just calling it doesn't raise IE for float and long double signaling
NaNs.  (isnan() needs to be a macro since converting its arg to a
common type doesn't work if the arg is a signaling NaN although it
works in all other cases.  Even on i386's it is not clear that args
can be and are always passed to isnan() without invoking the FPU in a
way that would raise IE for signaling NaNs.  Similarly for fpclassify().)

Very old versions of gcc on i386's generated fcom instead of fucom.
Since fucom works a little differently on signaling NaNs and there are
now standard comparison macros, it is not clear that generating fucom
is actually better.  It is also not clear that the comparison and
classification macros are specified correctly (or that I interpreted
the spec correctly) for signaling NaNs.  C99 seems to either overspecify
or underspecify the behaviour for signaling NaNs by not distinguishing
them from quiet NaNs.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-standards" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030209200824.R24643-100000>