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 

Initialisation problem related to a special module situation

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Wed Apr 10, 2019 12:30 pm    Post subject: Initialisation problem related to a special module situation Reply with quote

When porting a 32 bit application to 64 bit using Salford ftn95 8.40, we ran into a problem in context with a special module situation.

We have a fortran file consisting only of a module definition defining and initialising 2 variables. The module is used in a second (main) source which displays both variables of the module. It depends on the way we build the stuff if the output values are corect or not. Especially we cannot build a library consisting only of the object file built from the module file.

Module source file (mod_def.for):
Code:

      MODULE MYMOD
      REAL*8 :: VAR1 = 10D0
      REAL*8 :: VAR2 = 20D0
      END MODULE

Main source (mymodules1.for):
Code:

      use mymod
     
      write(*,*) 'VAR1=',VAR1
      write(*,*) 'VAR2=',VAR2
     
      end

Using link file mod_def.lnk
Code:

lo mod_def.obj
;lo mymodules2.obj
file mod_def.lib

causes an access violation when trying to create library mod_def.lib. Adding/decommenting loading file mymodules2.obj in the link file makes the library be generated as expected. Here mymodules2.for contains a function not used in the main program.

The main executable is created using link file
Code:

lo mymodules1
;lo mod_def.obj
lo mod_def.lib
file mymodules1.exe

Now executing mymodules1.exe results in the values 0.00000000000 for both VAR1 and VAR2. If I load object file mod_def.obj instead of mod_def.lib when linking mymodules1.exe and execute mymodules1.exe, then the proper output
Code:

 VAR1=          10.0000000000
 VAR2=          20.0000000000

is displayed.

This is not a serious problem for we can use the module object file in the context of our port mentioned above. However, originally we intended to use an analogon to the module file situation above where the module object file was contained in a library and this caused the wrong initialisation.

Regard,
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Apr 11, 2019 7:45 am    Post subject: Reply with quote

I have made a note that this needs investigation.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Tue Apr 16, 2019 9:29 am    Post subject: Reply with quote

Dietmar

The access violation has now been fixed but not in time for the next full release of FTN95. I can let you have a patched SLINK64 that includes this fix after the next full release.

This is not all good news. The outcome for the setup that you describe will not be what you currently experience for 32 bits. To be precise, the variables will be initialise to zero unless the module also contains a subprogram that is required when linking.

The natural behaviour of the linker is to scan any offered libraries in order to located missing subprograms. This is clear and simple. But there is no obvious strategy for handling module variables that could potentially be scattered as a result of module subprograms appearing in separate object blocks.

For the moment we have decided to reserve our position regarding the linking of module variables via a static library. This will mean that SLINK64 will initially behave differently from SLINK in this context and that the behaviour of SLINK64 may change in future in this regard.

If this approach is important to you then I suggest that you keep the relevant variables in a dedicated .obj file (var.obj say) rather than archiving them into a static library. This will require you to link with var.obj for the variables whilst (optionally) using a separate static library for any subprograms (including module subprograms).

Another approach (which to me is simpler and more robust) is to avoid this kind of module data initialisation and to write and call a module subroutine that does the initialising at run time.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Tue Apr 16, 2019 2:12 pm    Post subject: Reply with quote

Dietmar,

You are obviously far more sophisticated in your programming style than I am (from the discussion in your post), but can I reiterate Paul's observation that you are better off doing all the variable initialisation in a named subprogram called early in program execution? There is a benefit from doing the initialisation explicitly with assignment statements, and that is because you can call the subprogram to re-initialise the values. This corresponds to 'New' in the 'File' menu. Named subprograms will always be reported as missing if they aren't found when the linker does a 'roll call'.

If you initialise with DATA statements and/or the newer facilities in later versions of Fortran, you can only reinitialise with assignment statements anyway. There is also the problem of things missed out from the link stage. This is analogous to missing out a BLOCK DATA routine in old-style Fortran. I'm lucky that I never got into BLOCK DATA because several compilers I used didn't have it, but there were tricks (such as using named BLOCK DATA and mentioning the name in an EXTERNAL statement) that worked much of the time.

Eddie
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Apr 16, 2019 4:27 pm    Post subject: Reply with quote

Eddie, Paul,

thanks for your infos.

I am fine with putting the relevant variables in a dedicated .obj file. I think I mentioned that in my post.

And I'm fine with Paul's suggestions.

I also agree with Eddie that it might be a good strategy putting initialisation stuff into a subprogram.

However, I was porting a 32 bit program to 64 bit and for 32 bit everything worked fine. So I did not want to change the source code if not neccessary. And as the module object file was put into a static library for the 32 bit build I tried to do the same in the 64 bit build.

As this did not work I tried to find out why not and made the observations mentioned above.

Regards,
Dietmar
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed May 01, 2019 12:48 am    Post subject: Reply with quote

Pul wrote:
Quote:
"To be precise, the variables will be initialise to zero unless the ..."

Far from being problematic, I'd have thought this was excellent good practice.
I ws always taught to initialize all variables to zero from the offset.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
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 -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
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