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 

Incorrect reported COMMON block size
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1574

PostPosted: Sun Nov 21, 2021 1:11 pm    Post subject: Incorrect reported COMMON block size Reply with quote

While building the medium size codes mbdfdae.f and mbdfddo.f at http://archimede.dm.uniba.it/~mazzia/ode/gam.html#code , I ran into an instance where a named common block had one integer variable added at the end in one subroutine. FTN95 helpfully points out the mismatched size, but the size itself is reported incorrectly at times. Changes to unrelated parts of the source code make the mismatch go unreported, as well.

Here is a cut-down, meaningless example (file mab.f90).

Code:
program mbdfdo
   implicit none     
   real*8 AX
   integer NQ,MX,JT
   common /blk/AX,NQ,MX,JT      ! 8 + 3*4 = 20 bytes
   MX = 100
   call ovdriv
end
subroutine ovdriv
   implicit none     
   real*8 AX
   integer NQ,MX,NS,NH
   common /blk/AX,NQ,MX         ! 8 + 2*4 = 16 bytes
   NS = 3
   if(NS.gt.MX) then
      print *, NS,MX
      return
   end if
   NH = NH + 1
   return
end subroutine ovdriv


With the most recent version of FTN95, I find:

Code:
R:\TOMS\MEBDF\Mazzia\tbed>ftn95 mab.f90
[FTN95/Win32 Ver. 8.82.0 Copyright (c) Silverfrost Ltd 1993-2021]
    NO ERRORS  [<MBDFDO> FTN95 v8.82.0]
    NO ERRORS  [<OVDRIV> FTN95 v8.82.0]

R:\TOMS\MEBDF\Mazzia\tbed>ftn95 /64 mab.f90
[FTN95/x64 Ver. 8.82.0 Copyright (c) Silverfrost Ltd 1993-2021]
    NO ERRORS  [<MBDFDO> FTN95 v8.82.0]
COMMENT - common block /BLK/ was declared of length 24, and is now declared of length 16
    NO ERRORS  [<OVDRIV> FTN95 v8.82.0]


I hope that you are able to reproduce the bug. Sometimes, the mismatched COMMON sizes are noticed only at link time:

Code:
R:\TOMS\MEBDF\Mazzia\tbed>ftn95 mab.f90 /link
[FTN95/Win32 Ver. 8.82.0 Copyright (c) Silverfrost Ltd 1993-2021]
    NO ERRORS  [<MBDFDO> FTN95 v8.82.0]
    NO ERRORS  [<OVDRIV> FTN95 v8.82.0]
WARNING - Common block "BLK/" was previously defined  as size 24 but is now defined as size 16
Creating executable: mab.EXE
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Nov 22, 2021 10:08 am    Post subject: Reply with quote

mecej4

Thanks for the feedback.

The comment or warning is provided by the linker which presumably calculates a size that is aligned to an 8-byte boundary.

Unfortunately this means that common block size miss-matches are not always reported. (As you will know, size matching is not required in the Fortran Standard.)

I will take a look at the 64 bit linker to see if the report can easily be corrected at least for 64 bit applications.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



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

PostPosted: Mon Nov 22, 2021 11:37 am    Post subject: Reply with quote

Mecej4:

I looked at the reference you gave, and one of the papers cited in it is by J. R. Cash. Now this wouldn't by any chance be the late Johnny (Ray) Cash, would it? My, that would make the man a real polymath!

Perhaps one has a lot of time on one's hands in Folsom Prison!

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



Joined: 31 Oct 2006
Posts: 1574

PostPosted: Mon Nov 22, 2021 11:55 am    Post subject: Reply with quote

Eddie, Professor Jeff Cash was a mathematician/numerical analysis expert at Imperial College (UK). His main contributions were in the area of methods for solving ordinary differential equations, including stiff sets.

An article about him from a year ago:

http://www.imperial.ac.uk/news/204753/mathematics-professors-legacy-continues-with-fund/

A book of which he is a co-author:

https://books.google.com/books/about/Solving_Differential_Equations_in_R.html?id=TkFZ7TBGdzIC

He contributed Algorithms 669, 703 and 927 to ACM TOMS:

https://calgo.acm.org

-----------------

Speaking of polymaths, you are probably aware that Theodore Kaczinski, better known as the Unabomber, was a mathematics prodigy. See http://www.math.utoronto.ca/007/unabom.html .


Last edited by mecej4 on Mon Nov 22, 2021 12:34 pm; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1574

PostPosted: Mon Nov 22, 2021 12:25 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:

The comment or warning is provided by the linker which presumably calculates a size that is aligned to an 8-byte boundary.


That's fine, but padding for alignment, if any, should be performed consistently across compilation units, otherwise the storage sequences will not match. I checked this by producing the cross-reference listing for the file, from which I find (with /64 /xref, Version 8.82) that the byte offsets of the variables relative to the beginning of the named common block are 0, 8, 12 and 16, which makes the length of the block 20 bytes in the main program rather than the 24 reported in the warning message.

Quote:
(As you will know, size matching is not required in the Fortran Standard.)


That is true only for blank common. For labelled common, Fortran 77 as well as Fortran 2008 require sizes to match. Here is the quote from Section 5.7.2.5 of F2008:

Quote:
Named common blocks of the same name shall be of the same size in all scoping units of a program in which they appear, but blank common blocks may be of different sizes.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Nov 22, 2021 1:13 pm    Post subject: Reply with quote

mecej4

Thanks for the future information.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



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

PostPosted: Mon Nov 22, 2021 2:47 pm    Post subject: Reply with quote

Mecej4,

He may well be a 'Johnny (Jeff?) come lately' at Imperial College, and I didn't overlap with him. When I was doing my PhD there, (in Civil Engineering) I used to bribe the car park attendant to let me park - usually in some absent Professor's spot. So even if he overlapped with me, I may have parked my Lotus in his place! Well, you have to do something to raise the tone of the dump.

You took me more seriously than I intended, noting that the middle initial matched. People with non-unique or amusing names always fascinate me*. There hasn't been anyone in the English-speaking world with my first forename and surname since a minor aristocrat in the 19th Century.**

I think (i,e. I am certain) that you are right about the named COMMON blocks, and FTN95 is better than the standard. I'd certainly not expect anything I wrote to work well, if at all, with different lengths for the same named COMMON block.

Eddie

* Especially where the names and initials make humorous or vulgar combinations, preferably both.

**At least, not perhaps until a few years ago. My late sister was a keen genealogist, and she was confident that it was so until she died and I lost my advisor. The aristocrat was an amateur mathematician, and a friend of Babbage, and also Green of Green's Functions.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1574

PostPosted: Mon Nov 22, 2021 4:25 pm    Post subject: Re: Reply with quote

LitusSaxonicum wrote:
There hasn't been anyone in the English-speaking world with my first forename and surname since a minor aristocrat in the 19th Century.**
...

** ... The aristocrat was an amateur mathematician, and a friend of Babbage, and also Green of Green's Functions.


Yes, here is a link to that connection:

https://epubs.siam.org/doi/abs/10.1137/1.9780898718102.ch5
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Nov 22, 2021 4:54 pm    Post subject: Reply with quote

mecej4

It turns out that there exists an undocumented FTN95 option /NO_COMMON_ALIGNMENT that does the trick.

Can you try it? I am not completely sure that the option is available outside of the developer team.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



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

PostPosted: Mon Nov 22, 2021 5:52 pm    Post subject: Reply with quote

Mecej4,

You've given me away! Well, I did give you a clue. And I'm not Ffrench, and I'd like to think that I'm not COMMON either!

You didn't get the Babbage connection: his son's middle name.

I'm puzzled about the 8-byte alignement. What difference does it make>?

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



Joined: 31 Oct 2006
Posts: 1574

PostPosted: Mon Nov 22, 2021 5:55 pm    Post subject: Reply with quote

Paul, this is what the compiler says with /NO_COMMON_ALIGNMENT:

Code:
R:\TOMS\MEBDF\Mazzia\tbed>ftn95 /64 /no_common_alignment mab.f90 /link
[FTN95/x64 Ver. 8.82.0 Copyright (c) Silverfrost Ltd 1993-2021]
*** /NO_COMMON_ALIGNMENT is not a valid option on the command line - use FTN95 /? for valid options
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2351
Location: Sydney

PostPosted: Tue Nov 23, 2021 1:23 am    Post subject: Reply with quote

I was not aware that FTN95 did "common alignment"
Was this introduced in FTN95 /64 ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Nov 23, 2021 8:42 am    Post subject: Reply with quote

The FTN95 option /NO_COMMON_ALIGNMENT will be included in the next release of FTN95.

The alignment is not new to 64 bits. It was probably provided in the earliest versions of FTN95.

The alignment is in fact provided by the compiler and passed on to the linker. The only apparent "problem" that arises as a result of the alignment is that miss-matched common block sizes are not always flagged (as illustrated in mecej4's sample program above). Apart from that the sizing and positioning are handled consistently across all linked objects.

FTN95 produces 64-bit object code in a manner that allows miss-matched sizes within a single file to be reported at compile time. 32-bit object code is handled differently and as a result a report does not appear until link time. Miss-matches across different files can only be reported at link time.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1574

PostPosted: Tue Nov 23, 2021 11:46 am    Post subject: Reply with quote

Paul,

Thanks.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Nov 23, 2021 12:25 pm    Post subject: Reply with quote

This issue is still open. Further improvements are being considered.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 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