Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Interoperable global data in submodule error

rudi-gaelzer
New Contributor I
612 Views

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.

0 Kudos
5 Replies
FortranFan
Honored Contributor II
612 Views

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

0 Kudos
rudi-gaelzer
New Contributor I
612 Views

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?

0 Kudos
FortranFan
Honored Contributor II
612 Views

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

0 Kudos
rudi-gaelzer
New Contributor I
612 Views

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

0 Kudos
FortranFan
Honored Contributor II
612 Views

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.

0 Kudos
Reply