This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/33897] [4.1/4.2/4.3 Regression] Entries and modules



------- Comment #3 from pault at gcc dot gnu dot org  2007-10-26 09:10 -------
(In reply to comment #2)
> this works with gcc_4_0_branch, which makes this a regression.

Michael and Joost,

Are you sure that anything is wrong with gfortran, here?  If there is, I would
agree that this is a regression.  When Michael first posted PRs on ENTRY
statements in modules, I was a bit startled because ENTRY statements are a bit
contrary to the spirit of modules.  That said, there is nothing wrong with it
and..... according to the standard:

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.

Therefore, there is nothing wrong with having a module procedure with an entry
and this note says that gfortran is right on first testscase, since setbd is
made available by 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 it to mean that the ENTRY in the examples given is also made available
by use association.

Given these two bits of guidance from the standard, I believe that gfortran's
behaviour is consistent and correct, until the additional function setbd is
introduced. There, the complaint Global name 'setbd' at (1) is already being
used as a FUNCTION at (2), which does not happen if the new function is called
'binden' says that there is indeed something wrong - the module entry is being
promoted to a global symbol, which is not correct.

The examples of #1 are indeed bugs but not really a regression - entry in
modules did not work at all!

Cheers

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33897


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]