https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #14 from kargls at comcast dot net --- (In reply to anlauf from comment #12) > (In reply to kargls from comment #11) > > This is not processor-dependent behavior. gfortran implements > > real*complex in accordance with the words of the Fortran standard. > > > > 10.1.5.2.1 Interpretation of numeric intrinsic operations > > > > The two operands of numeric intrinsic binary operations may > > be of different numeric types or different kind type parameters. > > Except for a value of type real or complex raised to an integer > > power, if the operands have different types or kind type parameters, > > the effect is as if each operand that differs in type or kind type > > parameter from those of the result is converted to the type and > > kind type parameter of the result before the operation is performed. > > > > 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 > 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 -- steve
