forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

New compilation - array problems
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
colt1954



Joined: 21 Dec 2010
Posts: 81

PostPosted: Mon Jul 13, 2020 10:28 am    Post subject: Re: Reply with quote

DanRRight wrote:
Suppose you have the program aaa.f95
Code:
a=1
b=a*c
Print*, 'b=', b
END

You compile it
Code:
FTN95 aaa.f95 /link /debug /undef

You can just run the program as usual and get error report in the form of crash but better run it via debugger and see all the variables
Code:
SDBG AAA.EXE

Use F7 and F6 keys to see the execution step by step or just run to the error.

/undef and /full_undef are the most powerful debugging options

Inside debugger there exist prompts how to set debugger to stop on first use of any variable (or similarly stop on any change by the code of specific variable). Point with mouse on any variable and use right mouse button for that. All that is intuitive and does not need any guide, just try and see


Hi Dan but where do you type: FTN95 aaa.f95 /link /debug /undef

i use the rebuild option not sure how you invike the above are you suggeting you do it in command mode?
Back to top
View user's profile Send private message
colt1954



Joined: 21 Dec 2010
Posts: 81

PostPosted: Mon Jul 13, 2020 10:42 am    Post subject: More on compilation problem Reply with quote

Guys you have been so helpful.

I have found something with my code its not a zero array problem per se. lets explain: Its a rigid engine vibration program and it appears that the rotational responses are zero - ie the 'rotation variables are zero' and i am now looking at this - it is only working for one translation response e.g. Z direction...but the point is I have not knowingly changed any of the code, only re-compiled hence this problem now!

Couple of ideas:

1) Can you un-compile to get back to the original source of the one that does not work?

2) If so is there a way to compare codes side by side in an automated way without trawling through what is a very large programme.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Jul 13, 2020 10:51 am    Post subject: Reply with quote

colt1954

No you can't "un-compile".
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Jul 13, 2020 11:05 am    Post subject: Re: More on compilation problem Reply with quote

colt1954 wrote:
Can you un-compile to get back to the original source of the one that does not work?


That would be a great question to ask the candidate in a job interview. If the candidate answers "Yes", [s]he will enjoy many more such interviews.

colt1954 wrote:
...is there a way to compare codes side by side in an automated way without trawling through what is a very large programme


Many text editors, including Plato, provide a file-comparison feature. There are also specialised utilities such as Beyond Compare, http://scootersoftware.com for comparing files.
Back to top
View user's profile Send private message
colt1954



Joined: 21 Dec 2010
Posts: 81

PostPosted: Mon Jul 13, 2020 7:06 pm    Post subject: More on my array/compilation problem Reply with quote

Further to my previous posts regards problem with certain arrays returning unexpected zero’s this a simplified program cut and pasted from part of my program (below) it returns expected none zero’s for GENG(I,J) as I want!

Program Loop
DIMENSION VEC(12)
COMPLEX GENG(50,50),ENG(50,50)
NPT=5
DO I=1,12
VEC(I)=I*0.5
ENDDO
ENG(1,1)=(1,1)
DO I=33,35
DO J=1,NPT
GENG(I,J)=(0.0,0.0)
DO K=1,3
GENG(I,J)=GENG(I,J)+ENG(1,1)*VEC((I-33)*3+K)
print *, I,J,GENG(I,J),VEC((I-33)*3+K)
ENDDO
ENDDO
ENDDO
END

Here is the code from the program that returns zero values for GENG(I,J) array even though the VEC and GENG (3+K,J) arrays return values....bizarre, i include the VEC definition so could it be the double precision definition that’s screwing it up

!CALCULATE ACCELERATIONS

SUBROUTINE ACCL(NPT)
COMPLEX GENG(58,721)
DOUBLE PRECISION VEC(9)
COMMON /REAL2/ COG(3),EM,SM(6)
COMMON /COMP1/ GENG

Here is the almost exact routine as per the first listing except for the array

Double Precision VEC array definition difference.. I used this DP definition because another subroutine i adopted called for it. This gives zero for GENG(I,J) though GENG(3+K,J) and the VEC arrays return non zero believable values

!CALCULATE ANGULAR ACCELERATIONS

DO I=33,35
DO J=1,NPT
GENG(I,J)=(0.0,0.0)
DO K=1,3
GENG(I,J)=GENG(I,J)+GENG(3+K,J)*VEC((I-33)*3+K)

print *, I,J,GENG(I,J),GENG(3+K,J),VEC((I-33)*3+K)
ENDDO
ENDDO
ENDDO
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Jul 13, 2020 8:31 pm    Post subject: Reply with quote

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.
Code:
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
Back to top
View user's profile Send private message Visit poster's website
colt1954



Joined: 21 Dec 2010
Posts: 81

PostPosted: Mon Jul 13, 2020 10:29 pm    Post subject: Re: Reply with quote

Kenneth_Smith wrote:
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.
Code:
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...?
Back to top
View user's profile Send private message
colt1954



Joined: 21 Dec 2010
Posts: 81

PostPosted: Tue Jul 14, 2020 10:30 am    Post subject: Re: Reply with quote

colt1954 wrote:
Kenneth_Smith wrote:
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.
Code:
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??
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Jul 14, 2020 12:40 pm    Post subject: Reply with quote

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:

Code:
   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.
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jul 14, 2020 1:30 pm    Post subject: Reply with quote

colt1954,

I am not sure but I guess from your remark
Quote:
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
Code:
FTN95 aaa.f95 /link /debug /undef

produces the lines
Code:

[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:
Code:
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
Code:
implicit none
a=1
b=a*c
Print*, 'b=', b
END

and see what happens.

Regards
Dietmar
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Tue Jul 14, 2020 3:05 pm    Post subject: Reply with quote

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.

Code:
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.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Jul 14, 2020 3:27 pm    Post subject: Reply with quote

Ken

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

z = a*cmplx(b)
Back to top
View user's profile Send private message AIM Address
colt1954



Joined: 21 Dec 2010
Posts: 81

PostPosted: Tue Jul 14, 2020 5:07 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:
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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Jul 15, 2020 11:21 am    Post subject: Reply with quote

This bug has now been fixed for the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
colt1954



Joined: 21 Dec 2010
Posts: 81

PostPosted: Wed Jul 15, 2020 12:57 pm    Post subject: Re: Reply with quote

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


Brilliant, what a forum this is...
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group