topic Re: Error: BIND(C) attribute at (1) can only be used for variables or common blocks in Intel® Fortran Compiler

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

andrew_4619 — Fri, 20 Nov 2020 09:14:07 GMT

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

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

Arjen_Markus — Fri, 20 Nov 2020 09:22:26 GMT

Without seeing the code, I would say the error message is wrongly placed or wrongly formulated. Is the BIND(C) routine private to the submodule or is it public? And does the declaration in the main module have the BIND(C) attribute as well? Mostly thinking out loud here, I am afraid.

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

andrew_4619 — Fri, 20 Nov 2020 09:39:15 GMT

Thanks for the Reply Argen. The binc(c) is public and the declarations match. Those would both have thrown errors in Ifort. The thought about misplaced message is an interesting one because the error is on the first non-comment line of code. Does gfortran have history on that? I am a fortranner back to the early 80s but a gfortran newbie. My my next step is to take copies and remove things step by step to see if the error goes away at some step.

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

Arjen_Markus — Fri, 20 Nov 2020 09:46:26 GMT

I can have a look with gfortran - one caveat: thsi morning, I had to circumvent a different problem with submodules in gfortran myself :). You have some code I could try on it? (gfortran 10)

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

andrew_4619 — Fri, 20 Nov 2020 10:54:39 GMT

It seems to be I cannot have a routine with bind(c,name=...) in a submodule with gfortran? I attached a small reproducer.

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

Arjen_Markus — Fri, 20 Nov 2020 11:04:44 GMT

I just tried the small sample code with Intel Fortran 18.0 and gfortran 10.2 and both accept the code with no error messages whatsoever (for gfortran I had to create a dummy ifwin module, but that was all). I don't have a newer version of Intel Fortran installed here.

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

andrew_4619 — Fri, 20 Nov 2020 11:10:33 GMT

OK I will try a later gfortan binary I was using GNU Fortran (MinGW.org GCC Build-2) 9.2.0

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

andrew_4619 — Fri, 20 Nov 2020 11:18:13 GMT

Is i now not possible to edit a post? also the source markup tags for Fortran and plain text seem to have fallen off.

Anyway a can't find and gfortran 10.xxxxx for windows any clues on location?

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

Arjen_Markus — Fri, 20 Nov 2020 11:41:01 GMT

I have it installed under Cygwin and MinGW-w64/MSYS2, though for the latter I needed a completely new installation.

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

andrew_4619 — Fri, 20 Nov 2020 11:49:28 GMT

Thanks for the help Arjen, I think for now I will put this project on hold for a while and take stock of matters.

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

jimdempseyatthecove — Fri, 20 Nov 2020 13:42:40 GMT

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

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

andrew_4619 — Fri, 20 Nov 2020 14:02:27 GMT

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.

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

mecej4 — Fri, 20 Nov 2020 14:08:06 GMT

Andrew, for use with gFortran 9.3 (Cygwin Win10 x64), I created a fake ifwin.f90 with the content

MODULE IFWIN integer, parameter :: POINTER_LEN = 8 integer, parameter :: INT_PTR = POINTER_LEN integer, parameter :: HANDLE = 8 integer, parameter :: UINT = 4 integer, parameter :: UINT_PTR = POINTER_LEN integer, parameter :: LONG_PTR = POINTER_LEN integer, parameter :: fLPARAM = LONG_PTR integer, parameter :: fWPARAM = UINT_PTR END MODULE

and compiled with the command

gfortran -c mywinty.f90 bpatn_IF.f90 bpatn_SUBS.f90

The compilation did not cause any messages to be issued. HTH

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

andrew_4619 — Fri, 20 Nov 2020 16:37:59 GMT

Thanks for that. It would have been kinder if I had removed the Kinds. Thanks for that, it seems it is just a bug in the version I am running. I am not familiar with Cygwin that is a linux like environment for windows I think yes? would I be able to get a binary from somewhere for the compiler that I can run in a Windows command prompt? I had a look around but failed so far.

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

FortranFan — Fri, 20 Nov 2020 17:06:50 GMT

OK I will try a later gfortan binary I was using GNU Fortran (MinGW.org GCC Build-2) 9.2.0

@andrew_4619 ,

I'm curious: can you try this simple case with your version of gfortran and see if it compiles without errors.

module m interface module subroutine sub() bind(C, name="sub") end subroutine end interface end module submodule(m) sm contains module subroutine sub() bind(C, name="sub") end subroutine end submodule

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

mecej4 — Fri, 20 Nov 2020 17:28:54 GMT

Cygwin and Cygwin64 is a nice Linux-like environment that runs inside Windows. However, it is probably overkill to install it (1 to 2 GB) just to obtain gFortran. You can obtain various versions of Mingw GCC from a number of sites, including equation.com.

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

andrew_4619 — Fri, 20 Nov 2020 22:37:19 GMT

8 | submodule(m) sm
| 1
Error: BIND(C) attribute at (1) can only be used for variables or common blocks

To the small reproducer.

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

FortranFan — Sat, 21 Nov 2020 02:28:12 GMT

@andrew_4619 wrote: 8 | submodule(m) sm | 1 Error: BIND(C) attribute at (1) can only be used for variables or common blocks To the small reproducer.

That suggests to me the version of gfortran you are using is BUGGY.

I can't find anything in the standard that makes that small reproducer non-conforming.

In addition, a later version of gfortran as well as the latest Intel Fortran compiler processes the small reproducer code with no errors or warnings:

C:\Temp>type m.f90 module m interface module subroutine sub() bind(C, name="sub") end subroutine end interface end module submodule(m) sm contains module subroutine sub() bind(C, name="sub") end subroutine end submodule C:\Temp>gfortran --version -c -Wall -std=f2018 m.f90 GNU Fortran (GCC) 10.0.1 20200209 (experimental) Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\Temp>ifort /c /standard-semantics /warn:all /stand:f18 m.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.3.311 Build 20201010_000000 Copyright (C) 1985-2020 Intel Corporation. All rights reserved. C:\Temp>

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

andrew_4619 — Sat, 21 Nov 2020 09:09:33 GMT

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.

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

FortranFan — Sat, 21 Nov 2020 15:59:29 GMT

@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/