Mixing Silverfrost Fortran and Intel Fortran

[David_Mccabe]

Hi, I am encountering problems when I calldllsubroutines (compiled under intel fortran) in a fortran program(compiled using silverfrost).

Mysilverfrostprogram simply calls a dll subroutine with no arguments:

[fortran]program ftn95_prog

stdcall intelSimple "intelSimple" 

call intelSimple() ! Call a simple intel fortran function (no args)

write(*,*) "hit return to terminate..." 

read(*,*)

end program ftn95_prog
[/fortran]

My Intel .dll is composed of 3 external functions:

[fortran]subroutine intelSimple()
!DEC$ ATTRIBUTES DLLEXPORT, STDCALL, DECORATE, ALIAS:'intelSimple' :: intelSimple
    
    interface
        subroutine subA()
        end subroutine subA
    end interface
    
    write(*,*) "simple intel subroutine called" 
    
    call subA()

end subroutine intelSimple


subroutine subA()
!subroutine for calling "subB" with an array argument

    integer,dimension(3,3) :: array
    
    interface
        subroutine subB(array)
            integer,intent(inout),dimension(:,:) :: array
        end subroutine subB
    end interface
    
    array=1
    call subB(array)
    
end subroutine subA


subroutine subB(array)
    
    integer,intent(inout),dimension(:,:) :: array
    
    array=2

end subroutine subB[/fortran]

When running this program I expect an array argument with shape = (3,3) to be passed into "subB", instead I find it has shape = (19241...,1,1,0)

Everything apears fine until I step into subroutine subB.

Please could somebody point out where I am going wrong here?

Thanks

[bmchenry]

FTN95 (Silverfrost) has two options: to build .NET or to build 'regular Windows' which i believe is Win32.
you might check/verify that you are using the 'regular Windows'
(i'm guessing you are since i think it would throw other errors)
next question is: from where are you 'stepping'? Intel fortran?
(again, i'm guessing you are)
and then last, you need to set a 'default' value forthe elements of array since until you do i believe it is undefined.
that's my 2 bits

[David_Mccabe]

Thanks for the reply.

I am using visual studio 2010 which builds a regular windows Win32. The solution contains an ftn95 project and anIntel Visual Fortran project. Ican step through the intel codeby setting the intel project as the startup project.

I suspect that there is a mismatch between the dll call and theexported procedure,therefore the problem is a symptom of a corrupted stack?

I am still unable to fix this problem.

[bmchenry]

You probably should keep management of the projectsseparate (so no confusion on dlls, etc)
manage the FTN95 project with another environment (the silverfrost environemnt?).
Then in the VS2010 simply have it call the FTN95 EXE program in the Command for the Intel DLLS.
It will startup and call your dlls and you can debug cleanly that way.

unless or until you are trying to pass things between FTN95 and INTEL then FTN95 is simply a calling routine forthe INTEL dlls.
no need to confuse things with having it a part of the solution.

[David_Mccabe]

thank you onceagain for your quick response.

I am still unable to resolve these types of corrupted memory issues, and will nowtry toavoid mixing silverfrost with intel fortran.

I have attached a vs2010 solutionwith my attempts so far.

I would be greatful to hear more helpfulsuggestions if anybody has any.

[David_Mccabe]

thank you onceagain for your quick response.

I am still unable to resolve these types of corrupted memory issues, and will nowtry toavoid mixing silverfrost with intel fortran.

I have attached a vs2010 solutionwith my attempts so far.

I would be greatful to hear more helpfulsuggestions if anybody has any.

[IanH]

Your original example works for me from the command line. I'm not at all familiar with the FTN95 product (and I don't have the silverfrost integration installed) so I can't comment on its project settings.

[plain]U:projectsFortranMisc2011-12-15 silverfrost>ifort /check:all /warn:all /standard-semantics /dll /MD intel.f90
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 12.1.1.258 Build 20111011
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

Microsoft  Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:intel.dll
-dll
-implib:intel.lib
intel.obj
   Creating library intel.lib and object intel.exp

U:projectsFortranMisc2011-12-15 silverfrost>ftn95 main.f90 /link /library intel.dll
[FTN95/Win32 Ver. 6.10.0 Copyright (c) Silverfrost Ltd 1993-2011]
    NO ERRORS  [ FTN95/Win32 v6.10.0]
Creating executable: main.EXE

U:projectsFortranMisc2011-12-15 silverfrost>main
 simple intel subroutine called
 hit return to terminate...[/plain]

Note that your vfproj specifies stdcall as the default calling convention for the intel DLL in debug mode, but not in release mode. What was your intent?

If I was forced to mix compilers in this way I would use the C interoperability feature of the standard Fortran language to set calling conventions. There may still be pitfalls, but if the companion C processor is common then at least some of the potential inconsistencies are eliminated. I don't know if C interoperability is supported by FTN95 - C interoperability was introduced with the Fortran 2003 standard.

[David_Mccabe]

Just revisited this issue this morning.

sorry there are many other procedures in the files i have posted, the calls to which need to be uncommented.

The program and the .dll both work fine, most of the calls to the .dll in the example do work perfectly.
The stack only gets corrupted when a procedure with automatic or assumed length arguments gets called.
I believe automatic arguments and assumed arguments are kind of the same thing (the latter using hidden length/size arguments)

My guess is that there is a difference in the way ftn95 and ifort handle automatic objects differently.
(I would like to know about this)

Onework around would be to pass the argument lengths first in a separate procedure:
very cumbersome and untidy but should do the trick

[David_Mccabe]

Got it all working except for the assumed shape arrays.

The trick is to not use interfaces and addany hidden arguments in manually.

Could anybody tell me what hidden arguments get passed with an assumed shape array?

cheers

[David_Mccabe]

here are the files:

[Andrew_Smith]

The hidden descriptors for assumed shapearrays are not part ofanystandard so passing from Silvefrost to Intel Fortran is unlikely to succeed. Stick to passing arrays with a seperate, non-hiden integer specifying the size, such as your intelAdjustableArrayIn