- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems to be I cannot have a routine with bind(c,name=...) in a submodule with gfortran? I attached a small reproducer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK I will try a later gfortan binary I was using GNU Fortran (MinGW.org GCC Build-2) 9.2.0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have it installed under Cygwin and MinGW-w64/MSYS2, though for the latter I needed a completely new installation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the help Arjen, I think for now I will put this project on hold for a while and take stock of matters.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To elaborate a bit on Cygwin and MinGW (note: this is my understanding of the nature of these two environments):
- Cygwin is a Linux-like environment on Windows, which comes with all the commands from that platform. A program built under Cygwin with the Cygwin-version of the compilers runs in a Cygwin console, but not in an ordinary DOS box.
- MinGW can be regarded as a light version of Cygwin and the most important difference is that programs built with the MinGW-version of the compilers can indeed run in an ordinary DOS box, which makes distributing them a bit easier. (They do depend on some MinGW-specific DLLs, but that is not an uncommon phenomenon - Cygwin is more intrusive)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There's also WSL (Windows Subsystem for Linux), essentially Ubuntu running under Windows. I have built gfortran from source in this environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK I will try a later gfortan binary I was using GNU Fortran (MinGW.org GCC Build-2) 9.2.0
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
8 | submodule(m) sm
| 1
Error: BIND(C) attribute at (1) can only be used for variables or common blocks
To the small reproducer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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>
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page