This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: why a parameter changes when transfered to subroutine
- From: Craig Powers <enigma at hal-pc dot org>
- To: fortran at gcc dot gnu dot org
- Cc: fanbin <fan dot wisdom at gmail dot com>
- Date: Sat, 28 Jul 2007 01:27:04 -0400
- Subject: Re: why a parameter changes when transfered to subroutine
- References: <11839809.post@talk.nabble.com>
fanbin wrote:
I got a subroutine resh_dis(hubble,redshift,distance) which calculate this:
distance = 1.0D0/hubble*redshift*3000000D0*(1+redshift/2)/((1+redshift)**2)
in the subroutine all variables (including hubble ) were defined to be
real(kind=8), I admit that in the main program the hubble is real(kind=4)
like 62.0, than when I transfer it to the subroutine, the distance simply
become infinity, if I tranfered 62.0D0 instead of 62.0, everything becomes
fine, why?
Why? Because when you give the subroutine what it's expecting (62.0_8
into a real(8) argument), things will work, and when you don't, they
won't. With a subroutine expecting real(8), if you try to pass it
real(4) you have an illegal program -- if you're really lucky, it fails
spectacularly and you find the problem quickly. If you're unlucky, it
fails in a subtle way and you have to spend a lot of effort chasing it,
or you don't find it at all.
Problems of this sort are best avoided by the heavy use of modules,
which automatically produce explicit interfaces for their member
routines. You can also make explicit interfaces for non-module
routines, but that involves interface blocks which are clumsy and
error-prone.
This is a general fortran problem, not specific to gfortran. I would
expect similar behavior from any other compiler.