| View previous topic :: View next topic |
| Author |
Message |
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
 Posted: Tue Mar 05, 2024 2:09 am Post subject: Initialization |
 |
|
I got stung by the "/ZEROISE" assumption that worked in the 32-bit implementation. And also, something else.
I did a specific initialization of a variable, and it did not work. The value (of a R*8 floating point) was x'2020202020202020'. Even though I initialized it to 0.0d0. I had to put code into the routine to specifically initialize it to 0.0d0 so the routine I was exercising would work (sort of).
The value of d_scale was incorrect.
The code read:
| Code: | REAL*8:: PWIDTH=0.0d0,d_scale=0.0d0!,temp8
|
and yielded "20202020' when printed in hex (first 4 bytes).
However, when I added the statement:
| Code: |
data d_scale /0.0d0/
|
it all works! The initialization via a data statement works fine.
I cannot duplicate it in a smaller routine, so I'm asking what would be helpful to supply.
The reason I ask is that I am seeing things like this as I am starting to test the FORTRAN code after getting all the "C" support routines fully compiled. If I need to use data statements and/or specific initializations for every routine instead of the other syntax, so be it, and it will take a very long time to correct all these instances. I have almost 500 functions/subroutines.
Bill |
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7927
Location: Salford, UK
|
| Posted: Tue Mar 05, 2024 7:50 am Post subject: |
|
|
Bill
If the routine can be compiled on its own then you could send me the whole routine via DropBox say. |
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
| Posted: Tue Mar 05, 2024 2:39 pm Post subject: |
|
|
Unfortunately, it has many included files defining common blocks.
I will see what I can do to provide this via dropbox and a private message. |
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
| Posted: Tue Mar 05, 2024 3:26 pm Post subject: |
|
|
I was able to create a PLATO project with the barest minimum of code that duplicated the problem. Line 180 is the declaration (d_scale) and line 258 is the debugging statements that show it has been initlailized to blanks.
This is the PLATO project.
https://www.dropbox.com/scl/fo/fkekbjhedlh7mbs97vfpm/h?rlkey=mgq4kuw1fcjzar1m95h5p0hh1&dl=0
One interesting occurrence on my machine. I build, fresh, after a reboot/restart. If I run the program, then try to rebuild it, I'll get an error stating that the executable may be in use. I run TASK MANAGER, but nothing shows (that I can see). I have to log out or restart to be able to compile again.
Just an FYI.
Bill
Last edited by wahorger on Wed Mar 06, 2024 12:12 am; edited 1 time in total |
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
| Posted: Tue Mar 05, 2024 10:27 pm Post subject: |
|
|
| I think I tracked the issue with the executable to a DropBox interaction. Creating an executable in a shared folder like that apparently causes DropBox to mark the executable as "in use", preventing someone from running it (or deleting, modifying, ...). |
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7927
Location: Salford, UK
|
| Posted: Wed Mar 06, 2024 8:42 am Post subject: |
|
|
Bill
The INCLUDE files appear to be missing. |
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
| Posted: Wed Mar 06, 2024 2:41 pm Post subject: |
|
|
Paul, sorry for the mistake. I got got confused by two folders with similar names and dropped the "INCLUDED FILES" folder in the wrong place, then linked to it. The files are in place now.
For some unknown reason, I'm now getting when I try to compile the project. It seems related to conditional compilation (#ifdef) but I cannot be sure. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7927
Location: Salford, UK
|
| Posted: Wed Mar 06, 2024 4:05 pm Post subject: |
|
|
Bill
As you say, the project does not compile as it is. I am willing to try to fix the compiler (if necessary) but I need a working project to start with. |
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
| Posted: Wed Mar 06, 2024 4:13 pm Post subject: |
|
|
| I uncovered an aberrant double-quote in the project properties for plato. I have fixed that and now it compiles, runs, and displays the x'20202020'. |
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
| Posted: Thu Mar 07, 2024 12:46 am Post subject: |
|
|
As an FYI, if I add /UNDEF (even though it is /RELEASE), the initialization on the declaration line will occur. I verified by changing the code to
| Code: | REAL*8:: PWIDTH=0.0d0,d_scale=123.0d0
|
and verifying it when run. The hex output is still (00000000) as expected for a whole number r*8.
While this can work as a stop-gap measure, the performance penalty would preclude me from just using this in the production version. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7927
Location: Salford, UK
|
| Posted: Thu Mar 07, 2024 11:38 am Post subject: |
|
|
Here is a demonstrator for the current x64 failure. It relates to the initialisation of a user type member via a DATA statement.
I have logged this for investigation.
| Code: | integer function logplt_windows(prject)
logical prject
type extract_log_lv
integer num_extracted_records
logical first_time
end type
type(extract_log_lv)::struct_lv
data struct_lv%first_time /.true./
real*8::d_scale=0.0d0
write(*,'(Z16)') transfer(d_scale,1_4)
logplt_windows = 1
end function
program main
integer:: i,logplt_windows
i = logplt_windows(.true.)
end program main
|
|
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
| Posted: Thu Mar 07, 2024 3:06 pm Post subject: |
|
|
I did a bit of experimenting with my original code and discovered that if both the declaration of the type AND initialization of the TYPE element occurs AFTER all of the other declarations, then the prior occurrences of initialization within the item declaration using "=" appears to work.
Initialization of PARAMETERS appears to be unaffected. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
