Error: BIND(C) attribute at (1) can only be used for variables or common blocks

[andrew_4619]

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
bpatn_SUBS.f90:3:15:

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).

[andrew_4619]

Thanks @ff, I also think that is a bug, I installed a later version of gfortran in it fixes this problem and some other problems but finds a couple of new ones.... Still the exercise is throwing up one or two standards issues in my code that "compiles OK" in ifort. 

[FortranFan]

@andrew_4619 wrote:

.. I installed a later version of gfortran in it fixes this problem and some other problems but finds a couple of new ones.... Still the exercise is throwing up one or two standards issues in my code that "compiles OK" in ifort. 

@andrew_4619 ,

I strongly recommend you to try this Fortran Discourse site for such issues, especially because it may involve Fortran language matters generally and a separate processor (open-source gfortran) than Intel Fortran:

https://fortran-lang.discourse.group/

[Steve_Lionel]

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.

[jimdempseyatthecove]

>>the error is on the first non-comment line of code.

Try a discovery...

Insert, as a first non-comment line of code:

subroutine WillThisErrorOut()
   print *, "no"
end subroutine WillThisErrorOut

Then see if the error message occurs on the first non-comment line of code, or on the former first non-comment line of code.

If the error occurs on the new subroutine, then delete all that follow the new subroutine (keep a copy first).

Then, if the problem goes away, there is something funny in the ?comments? preceding the code.

If the problem exists, delete all the former code (leaving just the subroutine WillThisErrorOut)

If the problem exists, there may be something wrong with the build.

If the problem goes away, Hmmm???, does the build succeed with the original code by placing a "!" comment in front of BIND? (ignore the runtime issue of wrong interface, we are checking the compile error).

Note, your command line arguments indicate you are compiling using fixed form (132 character lines). Maybe you have non-conforming code that is throwing this error (by mistake).

Also, is the affected subroutine a CONTAINS procedure?

This would imply it is not the first line of code, other than via an INCLUDE elsewhere.

Jim Dempsey

[andrew_4619]

The problem is the gfortran version will not accept module procedures with bind(c) within a submodule but the error flags the submodule not the procedure. As Arjen suggests the later (devt?) version works it would seem.