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.
> > 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)
