https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117805
--- Comment #13 from mjr19 at cam dot ac.uk ---
(In reply to kargls from comment #11)
> On 11/28/24 04:54, rguenth at gcc dot gnu.org wrote:
>
> The Fortran standard stops at this point and does not specify the
> actual underlying algorithm.
That seems to me to be the point that the interpretation really relies on. For
evaluating z=z1*z2, a processor may use
if (aimag(z1).eq.0) then
z=cmplx(real(z1)*real(z2),real(z1)*aimag(z2))
else
z=cmplx(real(z1)*real(z2)-aimag(z1)*aimag(z2),
real(z1)*aimag(z2)+real(z2)*aimag(z1))
endif
or it might choose to use
if-known-at-compile-time (aimag(z1).eq.0) then [...]
At which point R*Z2 and cmplx(R,0.0)*Z2 would both be evaluated the fast way,
and so R*Z2 would be evaluated as though R were converted to complex. It would
potentially give a different answer to Z1*Z2 in the case where Z1 happens, by
unexpected chance, to be (R,0), but that is still standard compliant.
The standard does not guarantee that the same algorithm is always used, or that
the same input values always produce exactly the same result. It does not even
impose accuracy requirements.
As discussed on the J3 email list, it does not prohibit the historic algorithm
of
if my-processor-is-very-slow-at-multiplying
t=real(z1)*(real(z2+aimag(z2))
z=cmplx(t-aimag(z2)*(real(z1)+aimag(z1),
t+real(z2)*(aimag(z1)-real(z1))
else
[...]
which has three multiplies and five adds, rather than the usual four multiplies
and two adds.
Fortran has its roots long before IEEE-754 appeared, and when different
processors would certainly evaluate the same expression differently. J3 appears
to believe that IEEE-754, where supported, impacts real arithmetic, but not the
components of complex arithmetic. Given that the standard does not define which
real operations must be performed in order to evaluate a complex expression,
this is not unreasonable.
