Bug with NAMELIST in contained procedure

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:

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

      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:

_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?

Thank you. I have logged this for investigation. It runs OK with 64 bit FTN95 so that's really encouraging.

Quoted from John-Silver 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.

This has now been fixed for the next release.