New compilation - array problems

Quoted from colt1954

Quoted from Kenneth_Smith Colt1954,

You appear to be multiplying a single precision complex by a double precision real. Are you using 32 bit or 64 bit compiler? Reason for the question will be apparent in the following note to the folks at Silverfrost.

Paul,

Testing this, I found that multiplying a single precision complex by the double precision real produces incorrect results, for WIN32 (X64 is OK).

A simple example demonstrating the incorrect results is below. Mathematically the correct return value is 2.00 + j 2.00, but the return value with this code incorrect for Win32.

integer, parameter :: dp = kind(1.d0), sp = kind(1.0)
complex(kind=sp) a, z     
real(kind= dp) b     
a = cmplx(1.0,1.0)
b = 2.0
z = a*b
print*, 'a  ',   a
print*, 'b  ',   b
print*, 'a*b',   z
end

Multiplying a double precision complex by the single precision real produces the correct results.

The correct results are also obtained when the real and the complex number have the same precision (or kind number).

Rather perplexing. This looks like a compiler bug to me.

Ken

Ken this looks promising will check it out tomorrow how do I check 32 versus 64 bit compiler etc Also will Implicit none have any effect I since it appears in subroutines where VEC array gets used...?

Hi Ken,

Had a look at you last post, if I changed the VEC array to double precision in the first dummy programme (that originally worked) it still worked even though GENG array was just complex (single precision i assume). Just need to change programme VEC array to SP and check that solves the zero array issue??

Ken has found a bug that did not exist in version 7.2 and earlier. Here is the bug, quite evident at the assembly level:

   0006   z = a*b                                                                                AT 3c
      0000003c(20/4/83)          dfld      B
      0000003f(21/4/83)          dfmul     A[8]
      00000042(22/4/83)          dfld      B
      00000045(23/4/83)          dfmul     A
      00000048(24/3/29)          fstp      Z
      0000004b(25/3/29)          fstp      Z[4]

The instruction at 0000003F should have been multiplying by A[4], since a is single-precision.

colt1954,

I am not sure but I guess from your remark

i use the rebuild option not sure how you invike the above are you suggeting you do it in command mode?

that you are using PLATO to build your application. I do not know what you mean with command mode, but you may execute the commands Dan mentioned from within a Windows command window/command prompt (located in %windir%\system32\cmd.exe where windir is an environment variable which in my case is c:\windows). In my environment command

FTN95 aaa.f95 /link /debug /undef

produces the lines

[FTN95/Win32 Ver. 7.10.0 Copyright (c) Silverfrost Ltd 1993-2014]
           ....
0002) b=a*c
WARNING - Variable C has been used without being given an initial value
    NO ERRORS, 1 WARNING  [<main program> FTN95/Win32 v7.10.0]
Creating executable: aaa.EXE

and generates executable aaa.EXE. Executing aaa.EXE from within the command prompt results in a runtime error and displays an 'Exception window' containing the information 'Error 112, reference to undefined variable ...'. This is the case because of the /undef option. You may invoke the debugger (sdbg) by the second command Dan mentioned:

SDBG AAA.EXE

Typing F8 twice will result in the same error message (Error 122 ...).

Compiler option 'implicit none' forces ftn95 to produce an error if a variable has not been explicitly defined. You might want to compile program aaa1.f95

implicit none
a=1
b=a*c
Print*, 'b=', b
END

and see what happens.

Regards Dietmar

Thanks for confirming that bug Mecej4.

Another change i became aware of last night was that the compiler no longer issues a portability warning related to FTN kind numbers, e.g.

complex(1) a, z     
real(2) b 

I'm near certain this used to result in a recommendation to use SELECTED_REAL_KIND(X,Y) etc.

Ken

Thank you for the bug report. A temporary work-around is to use

z = a*cmplx(b)

Quoted from PaulLaidler Ken

Thank you for the bug report. A temporary work-around is to use

z = a*cmplx(b)

Well the good news is I have managed to get the programme working by no longer specifying the VECT array as double precision, the multiplication now gives non zero (correct) values for GENG array (see earlier code posted). Spent ages trying to get to the bottom of the problem what is a complex programme, thanks to help have managed to finally do it.

What's frustrating is that the compiler did not flag up the problem, when there is plenty of trivial warnings about floating point, nothing about this more serious problem, oh well.

This bug has now been fixed for the next release of FTN95.

Quoted from PaulLaidler This bug has now been fixed for the next release of FTN95.

Brilliant, what a forum this is...