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 

Bug with NAMELIST in contained procedure

 
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: 1886

PostPosted: Wed Jan 20, 2016 3:53 pm    Post subject: Bug with NAMELIST in contained procedure Reply with quote

When a namelist is declared in the main program or an external subroutine/function, the namelist is treated properly. However, when the namelist is declared, its members defined and the namelist printed in an internal procedure, the compiler outputs buggy code. Here is a reproducer:
Code:

program buggy
   implicit none
   call sub()

contains
   subroutine sub()
      integer i1,i2
      namelist /nml/i1,i2
      i1=23
      i2=32
      write(*,nml=nml)
      return
   end subroutine

end program

An access violation occurs at location program base+0030H. The exp-list obscures the bug by displaying only the symbol 'NML':
Code:

      00000000(3/1/1)            push      ebp
      00000001(4/1/1)            mov       ebp,esp
      00000003(5/1/1)            push      ebx
      00000004(6/1/1)            push      esi
      00000005(7/1/1)            push      edi
      00000006(8/1/1)            push      eax
      00000007(9/1/1)            lea       ecx,2
      0000000d(10/1/1)           push      ecx
      0000000e(11/1/1)           lea       esi,[ebp+8]       ; Get command line arguments
      00000011(12/1/1)           push      esi
      00000012(13/1/1)           call      __FTN95INIT1_
      00000017(14/1/1)           add       esp,=8
      0000001a(15/1/1)           sub       esp,=16           ; Adjusted later if temporaries allocated
      00000020(16/1/1)           sub       esp,=36           ; Grab space for NAMELIST block
      00000023(17/1/1)           mov       edi,esp
      00000025(18/1/1)           lea       esi,(/2,Z'4c4d4e04',Z'3149030e',1211906,1065,Z'030e0000',Z'03023249',Z'0451c389',0/)
      0000002b(19/1/1)           mov       ecx,=9
      00000030(20/1/1)           mov       NML,edi   ; <<=== BUG HERE!
      00000033(21/1/1)           rep
      00000034(22/1/1)           movs

Dumping the OBJ file with the MS Dumpbin utility gives:
Code:

_BUGGY:
  00000000: 55                 push        ebp
  00000001: 89 E5              mov         ebp,esp
  00000003: 53                 push        ebx
  00000004: 56                 push        esi
  00000005: 57                 push        edi
  00000006: 50                 push        eax
  00000007: 8D 0D 00 00 00 00  lea         ecx,[_BUGGY]; linker will provide address
  0000000D: 51                 push        ecx
  0000000E: 8D 75 08           lea         esi,[ebp+8]
  00000011: 56                 push        esi
  00000012: E8 00 00 00 00     call        00000017; linker will provide address
  00000017: 83 C4 08           add         esp,8
  0000001A: 81 EC 10 00 00 00  sub         esp,10h
  00000020: 83 EC 24           sub         esp,24h
  00000023: 89 E7              mov         edi,esp
  00000025: 8D 35 04 00 00 00  lea         esi,ds:[4]
  0000002B: B9 09 00 00 00     mov         ecx,9
  00000030: 89 7B F0           mov         dword ptr [ebx-10h],edi; <<== BUG HERE!
  00000033: F3 A5              rep movs    dword ptr [edi],dword ptr [esi]

At offset 0030, the contents of register EBX are undefined; this is the first instruction where the register is used at all in the program, not counting the PUSH at the main program entry. Secondly, is it not a bit odd that the namelist, which is local to the internal subroutine, is referred to in the caller?


Last edited by mecej4 on Wed Jan 20, 2016 4:06 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Jan 20, 2016 4:05 pm    Post subject: Reply with quote

Thank you. I have logged this for investigation.
It runs OK with 64 bit FTN95 so that's really encouraging.
Back to top
View user's profile Send private message AIM Address
John-Silver



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

PostPosted: Mon Jan 25, 2016 10:15 am    Post subject: Reply with quote

just an observation, is it a good idea to name the NAMELIST nml when the keyword is NML/nml ???
doesn't affect the problem which persists but a question of good coding practice I'd have thought.
Come to think of it, shouldn't it be flagged via the compiler, at least as a Warning ?


Secondly, congratulations on FTN95 64bit having been conceived to be the first compiler in the world with the foresight to predict and solve bugs !!! Wink Wink
Dan will be pleased Wink, LOL, all that devilry obliterated in an instant !
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1886

PostPosted: Tue Jan 26, 2016 2:29 am    Post subject: Re: Reply with quote

John-Silver wrote:
just an observation, is it a good idea to name the NAMELIST nml when the keyword is NML/nml ??? doesn't affect the problem which persists but a question of good coding practice I'd have thought.
Come to think of it, shouldn't it be flagged via the compiler, at least as a Warning ?

Among programming languages, Fortran is the long-suffering burro -- see the concluding paragraph of https://www.computer.org/csdl/proceedings/afips/1982/5089/00/50890817.pdf . Fortran has no reserved words.

Consider this Fortran-90 quine: http://wwwep.stewartsplace.org.uk/quines/f90.html . If you rename variables and/or reformat the source code to make it comely in your view, it will probably be neither a quine nor equine.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Jun 08, 2016 7:44 am    Post subject: Reply with quote

This has now been fixed for the next release.
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
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