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: 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


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