Host association of module ENTRYs

[paul.rich...@gmail.com]

Dear All,

gfortran and Digital 5.0 link the following without error, whereas
Compaq Fortran, Lahey Fortran, and g95 say that setbd is an unresolved
external.

MODULE ksbin1_aux_mod
CONTAINS
SUBROUTINE nxtstg()
INTEGER :: i
INTEGER :: setbd
i = setbd()
END SUBROUTINE nxtstg
FUNCTION binden()
INTEGER :: binden
INTEGER :: setbd
binden = 0
ENTRY setbd()
setbd = 0
END FUNCTION binden
END MODULE ksbin1_aux_mod
PROGRAM test
END PROGRAM test

All of the compilers that fail the above allow 'setbd' to be use
associated, however. (gfortran has a problem with this when there is
an external function 'setbd', for which a fix has been identified.) .
Is it not odd that the ENTRY should be available by use association
but not host associated within the module?

The standard says:-

NOTE 11.3
Although statement function definitions, ENTRY statements, and FORMAT
statements shall not appear in the specification part of a module,
they may appear in the specification part of a module subprogram in
the module. A module is host to any module subprograms (12.1.2.2) it
contains, and the entities in the module are therefore accessible in
the module subprograms
through host association.

>From 12.5.2.5, we have:

Because an ENTRY statement defines an additional function or an
additional subroutine, it is referenced in the same manner as any
other function or subroutine (12.4).

I take both of these to mean that the host association of ENTRYs
within a module is OK.

I would be grateful for opinions.

This is gcc PR33897.

Cheers

Paul

[Steve Lionel]

On Oct 26, 9:51 am, paul.richard.tho...@gmail.com wrote:

> gfortran and Digital 5.0 link the following without error, whereas
> Compaq Fortran, Lahey Fortran, and g95 say that setbd is an unresolved
> external.

I don't know what version of Compaq Fortran you tested, but CVF 6.6C
has no problem with your example, nor does Intel Fortran 10.0.
Offhand, I think the usage is valid.

Steve

[Ron Shepard]

In article <1193406667.9...@57g2000hsv.googlegroups.com>,
paul.rich...@gmail.com wrote:

> MODULE ksbin1_aux_mod
> CONTAINS
> SUBROUTINE nxtstg()
> INTEGER :: i
> INTEGER :: setbd
> i = setbd()
> END SUBROUTINE nxtstg
> FUNCTION binden()
> INTEGER :: binden
> INTEGER :: setbd
> binden = 0
> ENTRY setbd()
> setbd = 0
> END FUNCTION binden
> END MODULE ksbin1_aux_mod
> PROGRAM test
> END PROGRAM test

My version of gfortran compiles this alright, but the suspicious
thing is the integer declaration of setbd in subroutine nxtstg. It
seems that this is either redundant or that it should cause the
subsequent reference to be interpreted as an external function
rather than the module entry point. What happens if you remove that
declaration?

$.02 -Ron Shepard

[Joost]

> My version of gfortran compiles this alright, but the suspicious
> thing is the integer declaration of setbd in subroutine nxtstg. It
> seems that this is either redundant or that it should cause the
> subsequent reference to be interpreted as an external function
> rather than the module entry point. What happens if you remove that
> declaration?

This is of course spot on.... this means setbd is indeed an external
function which implies that setbd from the host is not available.

Joost

[paul.rich...@gmail.com]

Steve and Ron,

> I don't know what version of Compaq Fortran you tested, but
> CVF 6.6C has no problem with your example, nor does Intel
> Fortran 10.0.

The reporter does not say. I thought it odd because I found that it
worked fine with Intel too! It seemed a bit unlikely that you would
deviate between the two but stranger things have been known.

> Offhand, I think the usage is valid.

Good - thanks for the opinion.

> My version of gfortran compiles this alright,

gcc-4.2 onwards do the right thing.

> but the suspicious thing is the integer declaration of setbd
> in subroutine nxtstg. It seems that this is either redundant

It is redundant but is allowed because it reconfirms the
characteristic.

> What happens if you remove that declaration?

Nothing changes.

Cheers

Paul

[paul.rich...@gmail.com]

Joost and Ron,

> This is of course spot on.... this means setbd is indeed an
> external function which implies that setbd from the host is
> not available.

Ahhhh! So I was wrong about it being a permitted confirmation of the
type?

Paul

[Dick Hendrickson]

I'm not sure this is correct. Note 11.4 (page 250 in F2003)
says that modules are hosts to module subprograms and
entities in the module are accessible to the subprograms by
host association. I'd be surer about this if I could find the
normative text.

In 16.4.1.3 bullet (2) says that objects in a type declaration
become local names and block the host associated thing from the
scoping unit. I think that means that the INTEGER statement
declares an external, not a module, function.

It's always been my understanding that you can't declare anything
(other than volatile or asynchronous) about things accessed by
either host or use association. This prohibition includes
reconfirming attributes.

Dick Hendrickson

[Steve Lionel]

Indeed, and the closer I look at this case, the more troubled I am.

The Intel compiler appears to completely ignore the "local"
declaration of setbd, even if it conflicts with the declaration of the
ENTRY. C521 says that function-name (in a type declaration) "shall be
the name of an external function, an intrinsic function, a function
dummy procedure, or a statement function."

I now think the Intel compiler is incorrect and that the INTEGER ::
setbd establishes setbd as an external procedure.

Steve

[paul.rich...@gmail.com]

Steve,

> I now think the Intel compiler is incorrect and that the
> INTEGER :: setbd establishes setbd as an external procedure.

If it's any consolation, Intel and gcc both do the same, wrong thing.

Many thanks to you all for chipping in.

Now to fix it......

Paul

[gary.l...@lmco.com]

I think that would be precisely how I'd want to use ENTRY so I'd like
it to work as implied by the original code.

[Ron Shepard]

In article <1193410523.0...@v3g2000hsg.googlegroups.com>,
paul.rich...@gmail.com wrote:

> > My version of gfortran compiles this alright,
>
> gcc-4.2 onwards do the right thing.
>
> > but the suspicious thing is the integer declaration of setbd
> > in subroutine nxtstg. It seems that this is either redundant
>
> It is redundant but is allowed because it reconfirms the
> characteristic.

This is not the way host association works in other situations. In
many other situations, the declaration, which might intended to be
redundant, actually declares a new entity.

> > What happens if you remove that declaration?
>
> Nothing changes.

Consider the following modification to your code:

MODULE ksbin1_aux_mod
CONTAINS
SUBROUTINE nxtstg(i)
INTEGER :: i
! INTEGER :: setbd ! <--- Toggle this line

i = setbd()
END SUBROUTINE nxtstg
FUNCTION binden()
INTEGER :: binden
INTEGER :: setbd
binden = 0
ENTRY setbd()

write(*,*) 'module procedure invoked'

setbd = 0
END FUNCTION binden
END MODULE ksbin1_aux_mod
PROGRAM test

use ksbin1_aux_mod
call nxtstg(i)
write(*,*) 'i=', i
END PROGRAM test
integer function setbd()
write(*,*) 'external procedure invoked'
setbd = 1
end function

I think this is a legal program either with or without the integer
declaration in subroutine nxtstg. However, it prints different
values in the two cases. That declaration is what determines
whether the external function or the module function is invoked.

I think your situation is similar. However, in some of the the
cases where the external function is invoked, the reference is
eliminated because it is in dead code (the module is never used in
the executable). Note that your error was not a compiler error, it
was a linker error.

$.02 -Ron Shepard