I have been testing building "large" program in gfortran. The project is one I routinely work on in ifort. It has thrown up one or two interesting standards issues but that is by the bye. I am getting this error tagged on a submodule statement. I have tried various things but it has me baffled. Any ideas anyone? The submodule does contain a BIND(C) routine among other things.
C:\test>gfortran -c bpatn_SUBS.f90
3 | submodule (patn) patn_SUBS
Error: BIND(C) attribute at (1) can only be used for variables or common blocks
The 1 is under the n in (patn).
An ongoing issue with gfortran is that there are at most 2 or 3 developers working on it., and they are swamped. A couple of major contributors called it quits in the past year, and pleas for people to step up and work on it (just offering money is not enough) have gone unheeded. (It's not something one can just pick up casually.) Meanwhile there is a competing open-source Fortran compiler project, variously called flang or f18, that is getting all the attention and funding from various interests. (An initial version of this was based on the PGI Fortran front-end, but that has been abandoned for good reason.)
My expectation is that gfortran will eventually become abandonware, as g95 has.
To elaborate a bit on Cygwin and MinGW (note: this is my understanding of the nature of these two environments):
EXEs and DLLs built using Cygwin compilers, as well as the Cygwin versions of Linux commands, will run fine in any CMD window provided the key DLL cygwin1.dll is accessible through PATH.
Well, sofar my understanding :). I had the (wrong) impression that the Cygwin environment did more than just that, hence the incompatibility with an ordinary command prompt/DOS box I assumed.
A little sad that the gfortran project is having some trouble. I used one of the binaries that mecej4 suggested and built in a CMD window under Windows 10. The main thrust was not to switch the gfortran but to make my code compiler "independent":
1) By using a different compiler a few small things got thrown up. One such was C_LOC of things where target attribute was not specified. Ifort does not complain about that even with /STAND. Another was use if C_LOC when C_FUNLOC should have been used....
2) removal of compiler specific code. Given I only want windows builds I made a few new wrappers for the windows SDK routines to get rid of some IFPORT routines.
3) use my own bindings using binc(c) for the subset of IFWIN that I actually use. easier said than done but nearly complete.