http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48874
kargl at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2011-05-04 17:00:31 UTC --- (In reply to comment #0) > Consider > > #include <stdio.h> > #include <complex.h> > > int main() > { > double _Complex a = 0.0 + I*0.0; > double _Complex b = 0.0 - I*0.0; > double _Complex c = -0.0 + I*0.0; > double _Complex d = -0.0 - I*0.0; > printf("a= (%g,%g)\n", creal(a), cimag(a)); > printf("b= (%g,%g)\n", creal(b), cimag(b)); > printf("c= (%g,%g)\n", creal(c), cimag(c)); > printf("d= (%g,%g)\n", creal(d), cimag(d)); > } > > This program, compiled with "gcc zero1.c -O2 -pedantic -Wall -std=c99" (or > -std=gnu99) prints > > a= (0,0) > b= (0,-0) > c= (0,0) > d= (-0,-0) > > That is, the sign of the real part of "c" is lost. Add -fdump-tree-original to > the compile flags shows the dump as To some of us this, this is a well-known problem/issue/feature of gcc. In the expression, -0.0 + I * 0.0, the I is treated as 0 + i 1 where i = sqrt(-1). So, you get -0.0 + (0 + i 1) * 0.0 = -0.0 + 0.0 + i 0.0, which yields 0.0 + i 0.0. There were/are fun issues with NaN and +-Inf. Joseph fixed some/all of those problems. For details, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581