Subroutine inside an interface inside another subroutine...

The following code works fine in 32bit but not in 64bit:

!ftn95$free

module test

contains
SUBROUTINE TESTOUTER(IWIN, IEVENT, C80)
  CHARACTER*(*)	:: C80


  interface
    subroutine TESTINNER(iwin, ievent, c80)
      character*(*)			:: c80
	end subroutine
  end interface
  	  
  SAVE

  CALL TESTINNER(iwin, ievent, c80)

END SUBROUTINE

subroutine TESTINNER(iwin, ievent, c80)
      character*(*)			:: c80
      PRINT*,iwin, ievent, c80
End subroutine

end module test

program main
   use test
   character*20	:: c80
 
   c80 = 'test'
   
  IWIN=1
  IEVENT = 10
  call TESTOUTER (IWIN, IEVENT, C80)
end program

In 32bit it works fine, but in 64bit:

**[SLINK64 v2.10, Copyright (c) Silverfrost Ltd. 2015-2018] Loading C:\wlib64s\test-interface2\main.obj Creating executable file main.exe The following symbols were not defined:

TESTINNER**

TESTINNER is implicitly EXTERNAL and does not need an INTERFACE.

The code does not compile with gFortran and, off hand, I don't know how an interface ought to be presented in this context.

For FTN95 the behaviour does differ between 32 and 64 bits and at the moment I don't know why. If you want to retain the interface then FTN95 allows you to present it in the header part (before the CONTAINS), and this works for both 32 and 64 bits. However, it is quite possible that this information is ignored.

The MAP file for linking gives a clue. For some reason TESTINNER has got 'mangled' as though it were internal.

In short, I think there is something here that we need to look at but at the same time I suspect that the code may not be right.

Paul, StamK,

to your information: the code also does not build with INTEL's ifort compiler and produces an analogous error message (i.e. unresolved external symbol TESTINNER ...).

Regards, Dietmar

The Fortran standard says (F2008, 12.4.3.1, Note 12.2; similarly in F95, 12.3.2, Note 12.3)

NOTE 12.2 An interface body cannot be used to describe the interface of an internal procedure, a module procedure that is not a separate module procedure, or an intrinsic procedure because the interfaces of such procedures are already explicit. However, the name of a procedure may appear in a PROCEDURE statement in an interface block (12.4.3.2).

Therefore, the presence of the interface block in the example code makes the code non-conforming.

The Fortran standard does not (with a few exceptions) specify what a compiler should do with non-conforming code. Ideally, a compiler should flag an attempt to provide an interface block for an internal procedure. However, after seeing the interface block, which appears prior to the declaration of the conflicting internal procedure, the compiler may decide to take the presence of the interface block as a hint to treat it as an interface to an external procedure. Luckily for us, there is no such external procedure, so we get a linker error (unsatisfied external). If this were not so, we would have had a more perplexing debugging problem at run time.

Regardless of what the compiler does with non-conforming code, users will be surprised when the 32- and 64-bit compilations produce entirely different error messages. I am inclined to think that it a more serious compiler bug when, given faulty source code, the compiler not only produces an EXE but the resulting program 'works fine' in the eye of the user.

Thanks for that. I have now moved it into the main interface block in the module (before contains) and it works fine.

My comment above was based on a misunderstanding. I thought that the interface was for an external routine whereas it is in fact internal to the module.

So such an interface is never needed and for some compilers is not permitted.

My recommendation is to leave it out.

Sometimes you just have to accept that a part of Fortran is a riddle wrapped in a mystery inside an enigma. Fortran is mainly a catalogue of blunders.

Eddie (channelling WSC)