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]

single to double conversion


Hello,

We have some legacy code (computational chemistry and mathematical
optimization) which has been heavily used with g77 and DEC f90
compilers.  When compiling under gfortran 4.1 on FC5 or CentOS 4.4, I
encountered a change in the behaviour of our random number generator.

The fix turned out to be declaring every part of the RNG as double
precision, as the result was being passed from a single precision function
in the RNG to a double precision variable in the main program.  This
conversion, which would be implicit and automatically promote single to
double in g77, does not occur in gfortran and therefore the code did not
work properly.  No problems in DEC's f90 either.

After doing some gfortran reading, I turned on -Wconversion to catch other
possible type mismatch errors.  It presents many of them, including ones
such as:

 In file func.f:610

                  dot = 0.5
                       1
Warning: Conversion from REAL(4) to REAL(8) at (1)


 In file func.f:583

                  pot = pot+4*ptry(1)**2*coul/rij*erfc(rij*kappa)
                            1
Warning: Conversion from INTEGER(4) to REAL(8) at (1)


However, it fails to catch the actual problematic code, where ran_u(), my
uniform distribution generator, is decleared as real*8 in one subroutine,
but calculated as real*4 in the actual function.

So I guess I have a few questions:

1.  Why was the implicit conversion of single to double changed from g77
to gfortran?  I'm guessing it's strict adherence to the standard?  Is it
possible to have implicit conversion as a GNU extension or compiler
option?

2.  Can any real math errors occur in code compiled with gfortran when
simple math is written out in single precision (or similar things, such as
the integer multiplication above)?  If so, is that desireable?  If not,
should -Wconversion report those warnings?  There are many of them in our
medium size, legacy, math-heavy code and compiler output gets quite
spammy.

3.  Is it a bug for -Wconversion not to return a warning for code such as:

program main
implicit none
real*8 number,ran_u
number=ran_u()
end

function ran_u()
...single precision algorithm...
ran_u=result
return
end

The above code can produce catastrophic errors.  ran_u and number in the
program segment may have values radically different than ran_u as
calculated in the function.


Anyway, my problem is solved, but I am hoping to hear about these things
from the Fortran team.  I also realize the -fdefault-real-8 would
have solved my problem, but that is not an option I always want to use.
I'm sorry if these questions have all been asked before, but the search
function on the gfortran mailing list page appears to be broken.

Overall, I have been very happy with my gfortran experience.  Its warnings
from -Wall are much more complete and useful than those provided by g77.
Its compile time is slightly slower at -O1 levels, and I have not yet
tested its performance.  It seems to be a solid product, and I am thrilled
that the GCC suite will finally be shipping with a 64-bit friendly and
Fortran 95 capable compiler!  Thank you for all your hard work.  Good luck
in the future.

Sincerely,

Brian Barnes
Washington University in St. Louis


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