I am trying to create a mex file for FORTRAN90 code. I get an error because of '&' and long sentences in the FORTRAN90 code

The FORTRAN90 code I am trying to mex has a main code with several modules. I am working with MATLAB 2017 and Intel Parallel Studio XE 2017 for fortran compiler. I have been able to mex some of the modules using

mex -c modulename.f90.

I got stuck with an error in a module that has '&' and some parts of the code that have long sentences. For example in this code:

          if( .NOT. allocated(x) ) then
            allocate( dset(n), aset(n), x0(n), g(n), g0(n), gF(n), &
              & v(m+1), q(m+1), w(m+1), p(n), s(m+1), y(m+1), &
              & B(n,m+1), B0(n,m+1), BB(m+1,m+1), T(m+1,m+1), R(m+1,m+1), F(n), &
              & F0(n), tempM1(m+1), tempM2(m+1), brow(m+1), rrow(m+1), &
              & trow(m+1), zrow(m+1), tempN1(n), tempN2(n) )
          end if
          real(rp), public :: tol1, tol2, tol3, tol4, tol5, wparam, fx, fx0, sigma

I get ' error #5082: Syntax error, found '&' when expecting one of: [ IDENTIFIER allocate( dset(n), aset(n), x0(n), g(n), g0(n), gF(n), &'. The same error appears wherever & is present.

Another error I get is 'error #6418: This name has already been assigned a data type. [FX] real(rp), public :: tol1, tol2, tol3, tol4, tol5, wparam, fx, fx'.

How can I get rid of these errors? Any help is appreciated.

[dpb]

This is the result of the compiler using fixed form source rules for code written for F90 free form.

Fortran mex compilation is the red-haired stepchild and TMW hasn't kept up with the advances in Fortran with their compilation scripts.

You'll need to fixup the switches for the specific compiler you use to ensure it recognizes the F90 freeform source; generally the file extension of .F90 is sufficient to trigger that unless it is being overwritten by the script to set fixed form irregardless because the necessary mex include files aren't compatible, maybe.

Use the "verbose" switch on the compilation to echo to the screen what's actually begin given to the compiler to find what you need to fix.

Try to compile outside the mex batch file directly and see if there are issues with TMW-supplied files.

[Shubham Baisthakur]

I am facing the similar issue. Where can I find the mexopt files to change the COMPFLAG?

PS: I am using MATLAB R2020a

[James Tursa]

E.g., in Win64

C:\Program Files\MATLAB\R2020a\bin\win64\mexopts

Answer 1

[James Tursa]

This is usually caused by TMW including a compiler option in the mex option files to force fixed field source even if the file has a .f90 extension. Normally, files ending in .f or .for are compiled as fixed field and files ending in .f90 are compiled as free field. But TMW has an option in their compiler flags to override that. I have no idea why they continue to do this. To fix it, edit the appropriate mexopts file(s) on your system. E.g., on my system there are these files:

intelf11msvs2008engmatopts.bat
intelf11msvs2008opts.bat
    :
intelf11msvs2008shellengmatopts.bat
intelf11msvs2008shellopts.bat
    :
   etc

In these files you will see a COMPFLAGS line like this:

set COMPFLAGS=/fpp /Qprec /I"%MATLAB%/extern/include" /c /nologo /fixed /fp:source /MD /assume:bscc

See that /fixed option? GET RID OF IT!!! It should never have been there in the first place and I have been unsuccessful in getting TMW to remove it. E.g., I typically do this just so that it is documented what was there originally in a rem statement:

rem set COMPFLAGS=/fpp /Qprec /I"%MATLAB%/extern/include" /c /nologo /fixed /fp:source /MD /assume:bscc
set COMPFLAGS=/fpp /Qprec /I"%MATLAB%/extern/include" /c /nologo /fp:source /MD /assume:bscc

[Abhishek Subramanian]

I forgot to mention earlier. I already edited all the mexopts file in my system. They were all xml documents of the form 'intel_fortran_15_vs2012', there were about 15 files with similar names. I removed the '/fixed' and changed them all to have :

COMPFLAGS="/nologo /fpp /Qprec /MD /fp:source

Before removing the '/fixed' I couldn't even compile any of the files that did not have '&' or long lines in the code.

[James Tursa]

Try moving all of your declaration statements above your executable statements. E.g., put the real(rp) stuff ahead of the allocate stuff:

          real(rp), public :: tol1, tol2, tol3, tol4, tol5, wparam, fx, fx0, sigma
          if( .NOT. allocated(x) ) then
            allocate( dset(n), aset(n), x0(n), g(n), g0(n), gF(n), &
              & v(m+1), q(m+1), w(m+1), p(n), s(m+1), y(m+1), &
              & B(n,m+1), B0(n,m+1), BB(m+1,m+1), T(m+1,m+1), R(m+1,m+1), F(n), &
              & F0(n), tempM1(m+1), tempM2(m+1), brow(m+1), rrow(m+1), &
              & trow(m+1), zrow(m+1), tempN1(n), tempN2(n) )
          end if

[Abhishek Subramanian]

I still get an error because of '&' sign present in the code. I try to compile varsModule.f90 using:

   mex -c varModule.f90

This is the full error:

C:\Users\User\Desktop\masters thesis\mex\L-BFGS-B-SNOPT-master/varsModule.f90(77): error #5082: Syntax error, found '&' when expecting one of: [
<IDENTIFIER>
          allocate( dset(n), aset(n), x0(n), g(n), g0(n), gF(n), &
-------------------------------------------------------------------^

[James Tursa]

As a side note, one trick you can use with the double ampersand use to get things to compile in either a fixed or free format, put the ending ampersand in column 73 or greater, and put the beginning ampersand on the next line in column 6. That way if you have code that ends up being included in a fixed format file (rather than compiled separately) it will still compile. This probably doesn't apply to what you are currently doing, but I thought I would throw it out there for future reference.

Try this trick with that one section of code and see what happens. It sure looks like the code is still being compiled in fixed format for some reason.

And compile with the -v option to make sure you don't see the /fixed option anywhere.

[dpb]

Oh, and following up on James' remarks about spacing to locate the ampersands in correct columns (and that's why there are two in the source file is so it will work either way, btw, free form only needs one but will accept two but fixed form will not accept a continuation except as a character in column 6) ensure your source file doesn't have tabs but spaces so that there's no question regarding where the continuation column is. Some compilers (notably old DEC and now Intel that inherited the DEC compiler group) accept tabs as an extension but that is not Standard-compliant so a compiler that doesn't is still not the fault of the compiler but the programmer in the sense of being "correct".

[Abhishek Subramanian]

I removed the '&' sign at the end of each line and put one on the 6th column on whichever line it preceded the code and it compiled! It was just for a single module. I will try for all other and post the result here.

[James Tursa]

That would indicate, as I suspected, that the source code is still being compiled as a fixed format file for some reason. You might use the -v option to see where that might be coming from.

[Abhishek Subramanian]

Ahh yes, I forgot to look at that. I just did. There was a /fixed in a file named 'C:\Users\User\AppData\Roaming\MathWorks\MATLAB\R2017a\mex_FORTRAN_win64'. I removed that and it now works on fortran90 files with & as shown in the original question. Thanks!