Re: single to double conversion

[Brian Barnes <bcbarnes at artsci dot wustl dot edu>]

On Wed, 27 Sep 2006, Tobias Burnus wrote:

> I wouldn't be surprised if you pass "-r8" to DEC's f90 compiler.
>
> Note: If you have somewhere "real(4)" rather than "real", this does not
> help as this stays with 4byte-precision.

No: I did not pass -r8 to DEC's compiler.  Nor was anything specified as
real(4) or real*4.  g77 and DEC's f90 compiler really do behave
differently from gfortran with my code, which is the only reason I would
trouble the gfortran mailing list about this.  :)  The makefiles were
rather simple.  -Wall, -03 (or -01 for testing), bounds checking.  This
applies to all compilers.

> and returns. Otherwise if you call an external subroutine (which is also
> external if it is in the same file), the compiler does not know whether
> a real(4) or a real(8) is requested by that subroutine.
> To my very little* knowledge it has not changed (the problem remains:
> The compiler needs to be told (module, "contains", interface,
> "external"), which argument it has too pass to the function, otherwise
> it might do the wrong thing).
> [other comments]
> In your example above the problem is that you tell the compiler to
> assume real(8) as return value, however, it returns something different.

Yes, that is exactly the problem, and it was easily fixed by making the
precision in the function match the precision of the calling subroutine.

However, in g77, the real*4 of the function was 'detected' and
auto-promoted to real*8 in the subroutine.  There was loss of precision,
but that was not important to us.  The g77 compiler seemed to have no
problem at all in knowing that the precision of the subroutine and
function differed, and handling the difference gracefully.

gfortran, on the other hand, gives errant results for the real*8 variable,
and there is no possible warning by the compiler.  This comes back to my
original question:  if g77 handles this correctly, why does gfortan fail?
Can the behaviour of gfortran be changed?  If it is intentional behaviour,
can code like this, __which will never work__, be caught with a warning?

(the pseudo-code in question)
program main
real*8 number,ran_u
number=ran_u()   !!number will be TRASH!! contain random memory bits, etc
end
function ran_u()
...single precision algorithm...
ran_u=result
return
end

> I think there exists a bug report (feature request) to catch such
> problems if they occur in the same file. Some compilers (such as the
> intel compiler) offer an option (ifort: -gen-interfaces; this creates
> interface information for compiled fortran files), which also allows to
> check such problems, if the routines are in different files.

I would second this feature request.

Thanks,

Brian