https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #16 from kargls at comcast dot net --- On 11/29/24 10:35, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805 > > --- Comment #15 from anlauf at gcc dot gnu.org --- > (In reply to kargls from comment #14) >>>> If 'r' is of type REAL and 'z' is of type COMPLEX, the Fortran standard >>>> is clear that the interpretation is >>>> >>>> <result is complex> = r * z >>>> = (r, 0.) * z >>> >>> Is that really clear from the standard? >> >> Not in F2023. It is very clear in F77, 6.1.4 "Type and Interpretation >> of Arithmetic Expressions", Table 2. That table explicitly says the >> type conversion is >> >> <result is complex> = cmplx(r, 0.) * z > > That makes the conversion from real to complex sort of "slightly anti-linear": > > print *, cmplx (-1.), - cmplx (1.) > > gives: > > (-1.00000000,0.00000000) (-1.00000000,-0.00000000) > > etc. The '-' is an unary minus operator. In 'cmplx(-1.)', it operates on only the real part. In '- cmplx(1.)', it operates on both parts. I don't see anything anti-linear here. >>> In your quote I read "the effect is as if ... converted ...". >>> >>> With IEEE arithmetic available, it seems to be not clear to me if the >>> imaginary part has to be +0.; couldn't its sign depend on the sign of >>> the real part? Would that be a non-conforming implementation? >> >> Fortran 2023 does not specify any particular value for the imaginary >> part when type conversion occurs. It would be ludicrous to assume >> any value other than 0; but hey, got for it set it to -3.141526 > > I was more thinking of e.g.: > > complex function my_cmplx (r) > real, intent(in) :: r > my_cmplx = cmplx (r, sign (0., r)) > end function my_cmplx > > which when used as: > > print *, my_cmplx (1.), my_cmplx (-1.) > > gives: > > (1.00000000,0.00000000) (-1.00000000,-0.00000000) If one opens up a descent book on Complex Analysis, the real numbers are likely described as a subset of the complex numbers such that the imaginary part is 0. But, again, Fortran 2023 does not specify the actual value of the imaginary part when a real is converted. Go ahead, change gfortran to use -0. I suspect you'll get a few bug reports about code suddenly ending up on the wrong Riemann sheet or issues with branch cuts. gfortran's current behavior is conforming. More importantly, it is consistent for constant folding, simplification, and code generation. If you (or anyone) adds a new option for this micro-optimization, then please audit constant folding, simplification, and the runtime library.
