- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Using (ifort -V):
ntel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.3.222 Build 20180410
Copyright (C) 1985-2018 Intel Corporation. All rights reserved.
The following code:
module bind_mod implicit none interface module function do_nothing() real :: do_nothing end function do_nothing end interface end module bind_mod submodule(bind_mod) bind_smod use, intrinsic :: iso_c_binding, only: c_int implicit none integer(c_int), bind(c) :: nts contains function do_nothing() real :: do_nothing return end function do_nothing end submodule bind_smod
Generates the following error message:
ifort -c tes_bind_smod.f90 tes_bind_smod.f90(13): error #8067: If any bind-entity in a bind-stmt is an entity-name, the bind-stmt shall appear in the specification part of a module. [NTS] integer(c_int), bind(c) :: nts ---------------------------^ tes_bind_smod.f90(15): error #6645: The name of the module procedure conflicts with a name in the encompassing scoping unit. [DO_NOTHING] function do_nothing() ------------^ tes_bind_smod.f90(15): warning #6178: The return value of this FUNCTION has not been defined. [DO_NOTHING] function do_nothing() ------------^ compilation aborted for tes_bind_smod.f90 (code 1)
The same module/submodule are compiled with gfortran without errors and I think that's correct; I don't think the code violates the standard.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think the code is non-conforming and so is gfortran.
Constraint C519 in the current Fortran standard requires a variable with BIND attribute to be in the specification part of a module.
(Edit: change C818 to C519 since Fortran 2008 is still the official standard.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FortranFan wrote:
I think the code is non-conforming and so is gfortran.
Constraint C818 in the current Fortran standard requires a variable with BIND attribute to be in the specification part of a module.
OK, thanks. Found in ISO/IEC 1539-1 of F2018. The same rule is in C518 of J3/10-007r1 of F2008.
Do you think it's worth to mention this in comp.lang.fortran?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
rudi-gaelzer wrote:
.. The same rule is in C518 of J3/10-007r1 of F2008.
Do you think it's worth to mention this in comp.lang.fortran?
Re: gfortran, you may want to submit the issue at the GCC reporting site - if you don't have an account there or can't get one easily, posting the issue at comp.lang.fortran may help some GCC volunteer to pick it up.
(Edit: removed my erroneous comment about the constraint being C818 in both Fortran 2008 and (Committee Draft) Fortran 2018 standard documents.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FortranFan wrote:
Quote:
rudi-gaelzer wrote:
.. The same rule is in C518 of J3/10-007r1 of F2008.
Do you think it's worth to mention this in comp.lang.fortran?
Note it's the same named constraint - C818 - in both documents you mention, surprisingly!
Re: gfortran, you may want to submit the issue at the GCC reporting site - if you don't have an account there or can't get one easily, posting the issue at comp.lang.fortran may help some GCC volunteer to pick it up.
Errmm... are we talking the same thing here? In WD 1539-1 (version 2010-11-24), C818 reads:
C818
(R830) A do-term-shared-stmt shall not be an arithmetic-if-stmt, cycle-stmt, end-function-stmt, end-
program-stmt, end-mp-subprogram-stmt, end-subroutine-stmt, error-stop-stmt, exit-stmt, goto-stmt, return-
stmt, or stop-stmt.
BTW, it's C519 that refers to module. C518 is:
C518 An entity with the BIND attribute shall be a common block, variable, type, or procedure.
C519 A variable with the BIND attribute shall be declared in the specification part of a module.
Anyway, thanks again. Will post this at comp.lang.fortran
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
rudi-gaelzer wrote:
.. Errmm... are we talking the same thing here? ..
My bad.. I had 16-007r1 (an early draft of Fortran 2018) document open and mistakenly thinking it was 10-007r1 toward Fortran 2008.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page