'include ***.f' makefile error with MINGW in Windows 10 64 system

Thanks for your reply, Jeff!This interpretation of "errors" makes sense, as the example code is compiled successfully and gives right results.
      However, as what's found earlier this morning, I was suspecting the correct installation of the library itself. The installation note writes:

    Obviously, it's speaking to users who are in Unix system (correct me if I'm wrong). After digesting a little bit with the make file I previously got, I put the nlopt.f and nlopt.h files into

 C:\Program Files (x86)\Simply Fortran\mingw-w64\x86_64-w64-mingw32\include 

     and changed compiler locations to those under (resource compiler location wasn't changed as I didn't find windres.exe in the following folder)
   

 C:\Program Files (x86)\Simply Fortran\mingw-w64\x86_64-w64-mingw32\bin\ 

   
     while the default is

 C:\Program Files (x86)\Simply Fortran\mingw-w64\bin\ 

     Now the punch line question is: if make file "errors" are not true ones, am I installing the library in a correct way from their instructions?

In Project Options in version 1.45, you can add the flag:

-fcheck=all

in the "Fortran" field under Flags to enable runtime diagnostics.  It can be helpful in determining if array bounds have been exceeded.

One thing you need to remember is that the compiler will not produce an executable if either a) it can't find a specified include file (nlopt.f in this case) or b) it can't find the library for linking.  Regardless of whether you've installed the library per their directions, you wouldn't end up with an executable if the compiler couldn't find either the library or the include file.  Additionally, the fact that the example works fine suggests that the problem is not related to the library itself.  I wouldn't worry about the "correct" directories since the compiler seems to be finding the files it needs properly.  Their location would not affect runtime results.

For debugging, when the debugger "stops" at the seemingly random address, open the "Stack" view to see what calls led to that address.  It is quite likely that some illegal input passed into the Fortran runtime library is causing the program to halt in the debugger.  The debugger isn't perfect, though, so I urge you to try the compiler flag I suggested earlier.

I would guess that your suppressing SIGSEGV errors are indeed causing the stopping at seemingly random addresses.  Usually SIGSEGV means something has crashed completely due to memory violations.  The link you provided does not work, so I can't comment on whether or not the problem you're seeing is related.  However, it is rare that a SIGSEGV message is not critical.   

If you do not supress SIGSEGV, you should be able to determine where the crash in your code is occurring.  The question marks in the stack window are only indicative of confusion on the part of the debugger concerning where your code is crashing.  The "illegal input passed into the Fortran runtime library" terminology was trying to imply that perhaps you're asking the Fortran runtime library to print the 200th element of a 100 element array or something similar. 

When you added the "-fcheck=all" flag and ran your program outside the debugger, you didn't receive any diagnostic messages?

Hi Jeff,

    I figured out why there are SIGSEGV error message. Basically I'm calling a subroutine
   

 subroutine trans(v,a,b) 
             real(8), intent(out):: v(5) 
              ....... 
 end subroutine trans  

    In my main program, I did something like this
   

 real(8) :: m(10,5) 
             integer :: i
            do i=1,10 
                call trans(m(i,:), a,b)
            end do 

    This seems to be conflict with Fortran's rule of storing arrays by column and causes a runtime error, after I have the -fcheck=all in compiler flag.  If m(10,5) is changed into m(5,10), the problem disappears and the debugger is working as it should be.