https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #16)
> > 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.
OK, then try:
print *, cmplx (-1. * (-1.)), cmplx (-1.) * cmplx (-1.)
which gives:
(1.00000000,0.00000000) (1.00000000,-0.00000000)
This is why I said "slightly anti-linear".
> >>> 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.
The mapping of reals onto the complex plane itself is not the problem.
It is the rule that for real*complex one needs to convert the real number
to complex before the arithmetic operation which produces non-analytic
behavior.
> 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.
I did not say that gfortran is not conforming. It is the conversion rules
that are broken.
