Silverfrost Forums

Welcome to our forums

Unexpected Warning related to real constants

24 Jan 2020 4:26 #24920

Compiling the following code (named constant_warning.for) results in unexpected warnings:

      REAL*8 x      
      REAL*4 y      
      x=10000000.0  
      x=10000000.0_4
      x=10000000.0_8
      y=10000000.0  
      y=10000000.0_4
      y=10000000.0_8
      write(*,*) x,y
      end           

. Compiling with ftn95 version 8.60 via

ftn95 constant_warning.for /ALT_KINDS

results in warnings

c:\ds\samples\salford_8.60>ftn95 constant_warning.for /ALT_KINDS
[FTN95/Win32 Ver. 8.60.0 Copyright (c) Silverfrost Ltd 1993-2019]
     Licensed to:  Dipl.-Ing. H. Stapelfeldt
     Organisation: Stapelfeldt Ingenieurgesellsch. mbH

0003)       x=10000000.0
WARNING - A REAL constant has been truncated with possible loss of precision -
    maybe a KIND is required
0006)       y=10000000.0
WARNING - A REAL constant has been truncated with possible loss of precision -
    maybe a KIND is required
    NO ERRORS, 2 WARNINGS  [<main program> FTN95 v8.60.0]

which are unexpected to me. This happens, as well, if adding option /64 to the compile options.

Moreover, in the same situation the INTEL compiler ifort (64 bit) does not complain and displays no warning. Nor does ftn95 version 7.10 complain in this situation (and displays no warning).

Is there an explanation for the warnings? I am unsure if I should pay attention to the warnings. If not, how would I force ftn95 to not show them?

Thanks, Dietmar

24 Jan 2020 7:47 #24921

The constants are single precision real vales which in general are limited to 6 or 7 significant decimal digits.

In this case the warnings can be ignored but constants should often be given the relevant type as in 1.0D0.

26 Jan 2020 12:30 (Edited: 26 Jan 2020 10:31) #24922

I have seen that some bugs are still present in FTN95 8.51 in regard to the precision of real variables when the /alt_kinds compiler option is used. I hope that this bug is no longer present in 8.60.

program tst
implicit none
integer, parameter :: sp = selected_real_kind(6,30), &
                      dp = selected_real_kind(15,300)
real(dp) :: xd
!
xd = acos(-1.0_dp)
print *, 'sp, dp = ', sp, dp
print *, 'xd = ', xd
end program tst

Without /alt_kinds, the value displayed for xd is 3.14159265359, which has all 12 digits correct. With /alt_kinds, the value displayed is 3.14159274101, which has only the first 7 digits correct.

26 Jan 2020 5:25 #24923

My test replicates what has been reported. I do see the error with /alt_kinds when calculating ACOS or ATAN, however I agree with the warning reported for '10000000.0', as it is being truncated.

program tst
implicit none
integer, parameter :: sp = selected_real_kind(6,30), &
                      dp = selected_real_kind(15,300)
real(dp) :: xd, x
real(sp) :: y
!
   print *, 'sp, dp = ', sp, dp
!
   xd = acos(-1.0_dp)
   print *, 'xd_acos = ', xd
!
   xd = atan(1.0_dp)*4
   print *, 'xd_atan = ', xd
!
   x=10000000.0 
   y=10000000.0 
   write(*,*) x,y
!
   x=10000000.1 
   y=10000000.1 
   write(*,*) x,y
!
end program tst
26 Jan 2020 7:35 #24924

mecej4

Thanks for the bug report which I have noted needs fixing.

27 Jan 2020 9:01 #24929

Hello,

I still do not understand why constant

10000000.0_4

in line 4 and 7 does not produce the same warning as constant 10000000.0 .

Regards, Dietmar

27 Jan 2020 9:37 #24930

The kind number 4 stands for an IEEE 64-bit real in the FTN95 default notation, and thus a double precision constant is being assigned to a double precision variable in the two lines that you cited.

27 Jan 2020 10:02 #24931

For /alt_kinds, the _4 gives single precision.

If you provide the kind for a constant then FTN95 assumes that you know what you want. If you don't provide a kind value and there is a potential loss of precision then FTN95 provides a warning.

27 Jan 2020 3:34 #24932

mecej4,

thanks for your info.

To your information: the bug you mentioned is present for version 8.60 of ftn95, as well.

Regards, Dietmar

27 Jan 2020 4:48 #24933

Quoted from DietmarSiepmann To your information: the bug you mentioned is present for version 8.60 of ftn95, as well.

That's what I noted from the responses by John Campbell and Paul Laidler.

Thanks.

19 Feb 2020 6:58 #24989

The bug relating to acos(-1.0_dp) reported by mecej4 above has now been fixed for the next release of FTN95 (i.e. the release after v8.61).

FTN95 evaluates acos(-1.0_dp) at compile time and was using the default real kind at this point in the compilation.

21 Feb 2020 9:29 #24996

I tried the following code variation from earlier tests with the real constant 0.1, which is a value that I thought would give a warning, but it did not with Ver 8.61 for 'x = 0.1' ? my compile options were 32-bit and /debug What do others get ?

      integer*4, parameter :: sp = selected_real_kind (6)
      integer*4, parameter :: dp = selected_real_kind (10)

      REAL(dp) :: x1,x2,x3
      REAL(sp) :: y1,y2,y3

      x1=0.1 
      x2=0.1_sp
      x3=0.1_dp
      y1=0.1 
      y2=0.1_sp
      y3=0.1_dp

      write(*,*) x1,y1
      write(*,*) x2,y2
      write(*,*) x3,y3

      end 
26 Feb 2020 2:30 #25017

John,

I compiled your sample with version 8.61 and did not get a warning, too (compilation with and without /debug and with and without /64).

Regards, Dietrmar

Please login to reply.