Date: Fri, 12 Jul 2013 00:42:03 +0100 (BST) From: Anton Shterenlikht <mexas@bris.ac.uk> To: mexas@bristol.ac.uk, sgk@troutmask.apl.washington.edu, thierry@FreeBSD.org Cc: fortran@freebsd.org Subject: Re: gfortran46: Error: Type of argument 'z' in call to 'dimag' at (1) should be COMPLEX(16), not COMPLEX(8) Message-ID: <201307112342.r6BNg32L090240@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20130711172542.GA67029@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>From sgk@troutmask.apl.washington.edu Thu Jul 11 18:32:18 2013
>>
>>The correct fixes are to properly declare the variables via Fortran's
>>kind type parameter and to use generic intrinsic functions.
>
>Please fix the quoting mechanism of your email client to
>NOT use tab characters. It leads to alot of wasted screen
>real estate.
>
>>$ 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.
And on ia64 is does not seem to be supported,
and -fdefault-real8 has no effect on ia64:
$ uname -a
FreeBSD mech-cluster241.men.bris.ac.uk 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r252055: Fri Jun 21 15:57:18 BST 2013 root@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64
$ 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
$
In contract, on amd64, -fdefault-real-8 makes
DIMAG expect complex(16), but complex(8) is given.
And changing the declaration to complex(16) makes
the code compile and work as expected, i.e. increase
the number of significant digits roughly by a factor of 2:
$ cat z.f90
complex*16 :: z
z = (1,2)
write (*,*) dimag(z)
end
$ gfortran46 z.f90
$ ./a.out
2.0000000000000000
$ gfortran46 -fdefault-real-8 z.f90
z.f90:3.18:
write (*,*) dimag(z)
1
Error: Type of argument 'z' in call to 'dimag' at (1) should be COMPLEX(16), not COMPLEX(8)
$ sed s/\*16/\(kind=16\)/g z.f90 > zz.f90
$ cat zz.f90
complex(kind=16) :: z
z = (1,2)
write (*,*) dimag(z)
end
$ gfortran46 zz.f90
zz.f90:3.18:
write (*,*) dimag(z)
1
Error: Type of argument 'z' in call to 'dimag' at (1) should be COMPLEX(8), not COMPLEX(16)
$ gfortran46 -fdefault-real-8 zz.f90
$ ./a.out
2.0000000000000000000000000000000000
$
Anyway, it is important to know that -fdefault-real-8
does not affect the complex declarations.
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'm not sure what to do about this.
Anton
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307112342.r6BNg32L090240>