gfortran46: Error: Type of argument 'z' in call to 'dimag' at (1) should be COMPLEX(16), not COMPLEX(8)

[Steve Kargl]

On Fri, Jul 12, 2013 at 12:42:03AM +0100, Anton Shterenlikht wrote:
>>From sgk at troutmask.apl.washington.edu Thu Jul 11 18:32:18 2013
>>
>>>$ cat dcargu.f
>>>       FUNCTION DCARGU(C)
>>>       IMPLICIT REAL*8 (A-H,O-Z)
>>>       REAL*8     DCARGU
>>>       COMPLEX*16 C
>>
>>>         IF (DIMAG(C).GT.0.D0) THEN
>>
>>I suspect you are being hit by -fdefault-real-8 or
>>similar option.  If this is the case, you may want
>>to ask the ASTER developers if they know what that
>>option actually does.
> 
> (cc to thierry@ - the maintainer)
> 
> It's actually in the port's Makefile:
> 
> .if ${ARCH} == "i386"
> FLAGARCH=       -DP_LINUX -DLINUX
> FFLAGARCH=
> .else
> FLAGARCH=       -DLINUX64
> FFLAGARCH=      -fdefault-integer-8 -fdefault-real-8
> .endif
> 
> Anyway, please correct my analysis if it's wrong.
> 
> complex*16 is the same as complex(kind=8), meaning
> 16 bytes total, or two 8-byte reals.
> The effect of -fdefault-real-8 is to make DIMAG
> expect not complex(8) but complex(16), but *only*
> on platforms where complex(16) is supported.

Yes, this is essentially the cause of the problem.
I downloaded french/aster, and quite frankly, I
would not trust any results from that code.  Given
the amount of Fortran code, blindly using
-fdefault-integer-8 and -fdefault-real-8 is not a
good idea.

> And on ia64 is does not seem to be supported,
> and -fdefault-real8 has no effect on ia64:

I don't have access to ia64, so can't look into
gfortran's behavior.

> $ cat z.f90 
> complex*16 :: z
> z = (1,2)
> write (*,*) dimag(z)
> end
> $ gfortran46 -Wall z.f90
> $ ./a.out
>    2.0000000000000000     
> $ gfortran46 -Wall -fdefault-real-8 z.f90
> $ ./a.out 
>    2.0000000000000000     

You need to look at -fdump-tree-original.
This produces gcc's intermediate code, and
may show the promotion.

> I agree with you that this routine from the
> Aster code is not very well written, i.e.
> is not written with portability in mind.
> However, code_Aster is massive and I don't think
> it likely the developers will want to fix
> issues like this.

I suspect that the code_aster developers have no
idea how dangerous these options are, or understand
their limitations.  If the code_aster developers
do not want to do a proper port of the Fortran code
from single precision to double precision, then they
probably should use -freal-4-real-8, which is likely
closers to what they want.

-- 
Steve