This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: why a parameter changes when transfered to subroutine


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]