Bug 19138 - double complex / inf gives nan instead of 0
Summary: double complex / inf gives nan instead of 0
Status: RESOLVED DUPLICATE of bug 18902
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.2.2
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-23 14:35 UTC by Dmitri A. Sergatskov
Modified: 2004-12-23 23:22 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 3.3.1 4.0.0
Last reconfirmed: 2004-12-23 17:14:40


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitri A. Sergatskov 2004-12-23 14:35:35 UTC
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.
Comment 1 Andrew Pinski 2004-12-23 14:41:48 UTC
I don't see anything wrong with this.
Comment 2 Dmitri A. Sergatskov 2004-12-23 14:43:23 UTC
I do not understand. "nan" is not "0". That seems to be the problem.
Comment 3 Dmitri A. Sergatskov 2004-12-23 15:18:25 UTC
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).
Comment 4 jsm-csl@polyomino.org.uk 2004-12-23 15:50:35 UTC
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.

Comment 5 Wolfgang Bangerth 2004-12-23 17:14:39 UTC
Joseph's comment points to the exact right place. The result should be zero. 
Confirmed with gcc 3.3 and mainline. 
W. 
Comment 6 Paolo Carlini 2004-12-23 19:20:44 UTC
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?
Comment 7 Wolfgang Bangerth 2004-12-23 23:06:15 UTC
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. 
Comment 8 Paolo Carlini 2004-12-23 23:17:06 UTC
>                                           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!
Comment 9 Wolfgang Bangerth 2004-12-23 23:19:19 UTC
I'll be happy to defer to your superior technical knowledge :-) 
W. 
Comment 10 Paolo Carlini 2004-12-23 23:22:47 UTC
Ok ;) Then, let's close this one.

*** This bug has been marked as a duplicate of 18902 ***