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:

	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:

	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

Bill

If the routine can be compiled on its own then you could send me the whole routine via DropBox say.

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.

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

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, ...).

Wrong link! Thanks to John for pointing that out. Here's the correct link, and I've edited the original post with the wrong one!

Bill

https://www.dropbox.com/scl/fo/fkekbjhedlh7mbs97vfpm/h?rlkey=mgq4kuw1fcjzar1m95h5p0hh1&dl=0

Bill

The INCLUDE files appear to be missing.

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.

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.

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'.

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

	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.

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.

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

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.

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

Thanks, Paul!