The following program gives "nan nan" output instead of expected "0 0" #include <stdio.h> _Complex double a, r; double b = 1.0 / 0.0; int main (void) { __real__ a = 1.0; __imag__ a = -1.0; r = a / b; printf ("%f %f\n", __real__ r, __imag__ r); return 0; } As alois.schloegl@tugraz.at pointed out <<<< Prof. W .Kahan mentions in his "Lecture Notes on the Status of IEEE 754" p.10 http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF "when (0+3i)/inf is turned naively into (0+3i)*(inf-i)/(inf^2+0^2) it generates a NaN instead of the expected 0." >>>> This may be of some relevance here.
I don't see anything wrong with this.
I do not understand. "nan" is not "0". That seems to be the problem.
I noticed that my attempt to do multiple selection of gcc version did not quite work. I see this bug with gcc 3.2.2, 3.3.3 and as late as 3.4.3 20041212 (Red Hat 3.4.3-10).
Subject: Re: New: double complex / inf gives nan instead of 0 On Thu, 23 Dec 2004, dmitri at unm dot edu wrote: > The following program gives "nan nan" output instead of expected "0 0" It would have been helpful to point to C99 G.5.1 paragraph 4 third bullet point as the source of your expectation. We don't yet implement the C99 requirements for complex numbers (either the normative ones, or the non-normative ones in Annex G), though it would be useful to do so.
Joseph's comment points to the exact right place. The result should be zero. Confirmed with gcc 3.3 and mainline. W.
I'm tempted to mark this as duplicate of middle-end/18902, which I will try to (partially) fix after 4.0 branches. Ok with everyone?
This PR only covers a special case of the other PR, so I would be tempted to keep both open and if the other one is fixed checked whether this also covers the special case discussed here. I'm not sure whether this special case here immediately follows from fixing PR 18902. W.
> I'm not sure whether this special > case here immediately follows from fixing PR 18902. It does, indeed, this one is a *really* a special case: have a look to the test case that I have attached to 18902 (and verified fixed by a preliminary patch ;) But, if we want to keep both open, it's ok with me!
I'll be happy to defer to your superior technical knowledge :-) W.
Ok ;) Then, let's close this one. *** This bug has been marked as a duplicate of 18902 ***