This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: single to double conversion
Hi Brian,
Brian Barnes wrote:
> 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.
Ok, I did some tests with g77, 3.3.5.
------------------
double precision test
test = 1e99
print *, test
test = 0.12345678901234567
print *, test
test = 1d99
print *, test
test = 0.12345678901234567d0
print *, test
end
------------------
Here, g77 regards the first constants (as gfortran) as real and prints:
INF (gfortran: compile time error: Real constant overflows)
0.123456791 (0.123456791043282)
1.E+99 (1.000000000000000E)
0.123456789 (0.123456789012346)
In such a case, g77 and gfortran (on AMD64) behave the same: in the
first two assignments, precision is lost (in line with the Fortran
standard).
I now tried your pseudo-code example:
-----------------------
program main
real*8 number,ran_u
number=ran_u() !!number will be TRASH!! contain random memory
bits, etc
print *,number
end
function ran_u()
real ran_u
ran_u=42.42
end
-----------------------
This fails with default-settings to compile with NAG f95 ("Wrong data
type for reference to function RAN_U from MAIN"); it compiles, however,
with default settings with the Intel Fortran Compiler, the g95, sunf95
and gfortran and produce (on AMD64):
5.484265999324755E-315
(The sun compiler also warns that the function result differs from its
definition.)
With g77 I get (indeed):
42.4199982
(Actually, also if I split the source files: g77 -c test1.f; g77 -c
test2.f; g77 test*.o; yields 42.42. I really wonder what g77 is doing
here. Swapping real*8 and real does also work.)
I don't know what g77 does, but
(a) the result depends strongly on the compiler, actually of the 5
compilers tested, only g77 got the intended result
(b) g77 also crops the precision with r8variable = 1.23456789 (without
using "d0"). Probably the DEC compiler does as well.
I thus would recommend to use "-r8" for the DEC compiler,
"-fdefault-real-8" for gfortran and analogously for your other
compilers! (g77 actually does not have such an option.)
>> 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.
>
See http://gcc.gnu.org/wiki/GFortran43 ("Formal/actual argument checking
for same file procedures"). This feature is planned for gfortran 4.3,
i.e. this feature will likely relatively fast be implemented (in
few/couple of months)
I think implementing something similar to ifort's -gen-interface (which
creates a mod_function.mod for every fortran file compiled) is not
planed for the near future.
Tobias