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