cvs commit: src/lib/msun/src s_cimag.c s_cimagf.c s_cimagl.c s_conj.c s_conjf.c s_conjl.c

[David Schultz]

On Thu, Aug 07, 2008, Gabor Kovesdan wrote:
> David Schultz ha scritto:
> >das         2008-08-07 14:39:56 UTC
> >
> >  FreeBSD src repository
> >
> >  Modified files:
> >    lib/msun/src         s_cimag.c s_cimagf.c s_cimagl.c s_conj.c 
> >                         s_conjf.c s_conjl.c 
> >  Log:
> >  SVN rev 181374 on 2008-08-07 14:39:56Z by das
> >  
> >  Use cpack() and the gcc extension __imag__ to implement cimag() and
> >  conj() instead of using expressions like z * I. The latter is bad for
> >  several reasons:
> >  
> >  1. It is implemented using arithmetic, which is unnecessary, and can
> >     generate floating point exceptions, contrary to the requirements on
> >     these functions.
> >  
> >  2. gcc implements complex multiplication using a formula that breaks
> >     down for infinities, e.g., it gives INFINITY * I == nan + inf I.
> >  
> I've also checked that this part was a bit messy and incomplete and I've 
> thought of working on this, thus I'm happy to see that you are working 
> on improving the C99 complex.h support. My only concern is that, is it a 
> good idea to use GCC extensions in our libc? Isn't this a significant 
> limit of the portability?

A lot of things are part of the standard library specifically
because they can't be implemented in standard C.  Some things,
such as the complex data type and the tgmath.h header, can't be
implemented without compiler extensions, period.  As it happens,
cimag() can be implemented in standard C, but it's uglier:

	double
	cimag(complex double z)
	{
	 	union {
			complex double cpx;
			double components[2];
		} u;

		u.cpx = z;
		return (u.components[1]);
	}

I can convert it if you want, but it seems moot at the moment
because even icc supports the rather basic __real__ and __imag__
extensions, and any compiler that doesn't support gcc's way of
doing things is going to need a lot more work than this.