Error using mex, building with 'MinGW64 Compiler (FORTRAN)'

I am excited for the recent/native support of 'MinGW64 Compiler (FORTRAN)'. I successfully compiled the (fixed format) example, timestwo.F.

However, when I try to compile my (free format) program (which previously compile fine with the Intel compiler), I get the following error:

Error using mex
f951.exe: Warning: Nonexistent include directory 'C:\Program
Files\MATLAB\R2024a/simulink/include' [-Wmissing-include-dirs]
\MATLAB\toolbox\Fallterp111.f90:1:2:
#include "fintrf.h"
1
Warning: Illegal preprocessor directive

That is despite this being the identical first line of timestwo.F. I suspected that the /fixed flag might still be an issue, but I do not see it in \bin\win64\mexopts\mingw64_gfortran.xml, so I cannot delete it.

Any idea what is happening?

Here is the complete fortran program that gets the above error (note: I removed a couple calls to other subroutines to shorten this):

#include "fintrf.h"
subroutine mexFunction(nlhs, plhs, nrhs, prhs)
! Declarations
implicit none

! mexFunction argument
mwPointer plhs(*), prhs(*)    
integer*4 nlhs, nrhs

! Function declarations
mwSize mxGetM,mxGetN  
mwpointer mxGetPr, mxCreateNumericArray, mxGetDimensions 
double precision mxGetScalar  
integer*4 mxClassIDFromClassName 

! Pointers to input/output mxArrays
mwpointer x1_pr
mwpointer x1i_pr
mwpointer pf1_pr
mwpointer o1_pr

! Array information
mwSize nx1,nodes,e1
integer*4 myclassid
double precision, allocatable, dimension(:) :: x1,x1i
double precision, allocatable, dimension(:) :: pf1
double precision, allocatable, dimension(:) :: o1

! Load Inputs
! Grids
nx1 = mxGetN(prhs(1))
nodes = nx1
allocate(x1(nx1))
x1_pr = mxGetPr(prhs(1))
call mxCopyPtrToReal8(x1_pr,x1,nx1)

! Point to evaluate
e1 = mxGetM(prhs(2))
allocate(x1i(e1))
x1i_pr = mxGetPr(prhs(2))
call mxCopyPtrToReal8(x1i_pr,x1i,e1)

! Rules
allocate(pf1(nx1))
pf1_pr = mxGetPr(prhs(3))
call mxCopyPtrToReal8(pf1_pr,pf1,nodes)

!Create array for return argument
myclassid = mxClassIDFromClassName('double')
allocate(o1(e1)) 
plhs(1) = mxCreateNumericArray(1,e1,myclassid,0)
o1_pr = mxGetPr(plhs(1))

! Deallocate arrays
deallocate(x1)
deallocate(x1i)
deallocate(pf1)   
deallocate(o1)

end subroutine mexFunction

Answer 1

[Nathaniel Throckmorton]

I changed the filename from *.f90 to *.F90, and it compiles now. I still get a few errors from f951.exe, but they don't seem to be catastrophic. I tested the function and it seems to work as intented.

Building with 'MinGW64 Compiler (FORTRAN)'.
f951.exe: Warning: Nonexistent include directory 'C:\Program Files\MATLAB\R2024a/simulink/include' [-Wmissing-include-dirs]

f951.exe: Warning: Nonexistent include directory 'C:\Program Files\MATLAB\R2024a/simulink/include' [-Wmissing-include-dirs]

f951.exe: Warning: Nonexistent include directory 'C:\Program Files\MATLAB\R2024a/simulink/include' [-Wmissing-include-dirs]

MEX completed successfully.

Answer 2

[James Tursa]

FYI, you should never use literal constants in a Fortran API call, because you can't be sure whether the literal integer(4) or integer(8) will match up with the API function signature correctly. You can get away with this in a pass-by-value environment such as C/C++ where values automatically get promoted to the correct type, but you can't get away with this in a pass-by-reference environment such as Fortran using an implicit interface. Always create variables for passing API stuff in Fortran. E.g., since the signature for mxCreateNumericArray( ) is this:

mwPointer mxCreateNumericArray(ndim, dims, classid, ComplexFlag)
mwSize ndim
mwSize dims(ndim)
integer*4 classid, ComplexFlag

Your code should look something like this instead:

mwSize :: ndim = 1
integer*4 :: ComplexFlag = 0
:
plhs(1) = mxCreateNumericArray(ndim,e1,myclassid,ComplexFlag)

Sounds like TMW finally removed the silly /fixed option from the compiler flags, so that is good.

[Nathaniel Throckmorton]

Thanks for the feedback; I'll do that! I haven't updated my fortran functions in about 10 years. And when I first adopted mex and fortran you were my primary resource back then (and you are the main reason I eventually got everything working fast enough to finish my dissertation). I really appreciated your timely and accurate instruction back then, and I'm glad you're still strong in the game now!

[James Tursa]

You're very welcome ... and congrats on the dissertation!