Paul van Delst reports at https://groups.google.com/forum/#!topic/comp.lang.fortran/MzOnH6_yvPU the following issue. Compiles with GCC 4.4.6, 4.6, 4.7.3, ifort v12.4 and PGI v11. Fails with GCC 4.8 and 4.9 with: iargc_8=iargc() 1 Error: Function 'iargc_8' at (1) cannot be called recursively, as it is not RECURSIVE Conclusion of Robert Corbett and Richard Maine was that the code is ugly but valid. module args_mod interface iargc module procedure iargc_8 end interface interface getarg subroutine getarg(k,c) integer(4) k character*(*) c end subroutine getarg module procedure getarg_8 end interface contains integer(8) function iargc_8() integer(4) iargc iargc_8=iargc() end function iargc_8 subroutine getarg_8(k,c) integer(8) k character*(*) c integer(4) k4 k4=k call getarg(k4,c) end subroutine getarg_8 end module args_mod
Reduced test case: module args_mod interface iargc module procedure iargc_8 end interface contains integer(8) function iargc_8() integer(4) iargc iargc_8=iargc() end function end module (The getarg parts are not relevant for the bug.)
The changed appeared between r185913 (2012-03-28, no error) and r186417 (2012-04-13, error).
According to the c.l.f. discussion, the 'iargc' reference inside the function 'iargc_8' does not refer to the generic interface, but to an external function.
(In reply to Dominique d'Humieres from comment #2) > The changed appeared between r185913 (2012-03-28, no error) and r186417 > (2012-04-13, error). The most suspicious commit I can see in that range is r186318, which was Tobias' fix for PR52729.
(In reply to janus from comment #4) > The most suspicious commit I can see in that range is r186318, which was > Tobias' fix for PR52729. Indeed reverting this commit makes the error go away for comment 0 and 1.
(In reply to Dominique d'Humieres from comment #2) > The changed appeared between r185913 (2012-03-28, no error) and r186417 > (2012-04-13, error). Thanks for narrowing it down so sharply, Dominique. That was very helpful.
I propose the following patch: Index: gcc/fortran/resolve.c =================================================================== --- gcc/fortran/resolve.c (revision 206231) +++ gcc/fortran/resolve.c (working copy) @@ -12732,7 +12732,8 @@ resolve_symbol (gfc_symbol *sym) if (sym->attr.flavor == FL_UNKNOWN || (sym->attr.flavor == FL_PROCEDURE && !sym->attr.intrinsic && !sym->attr.generic && !sym->attr.external - && sym->attr.if_source == IFSRC_UNKNOWN)) + && sym->attr.if_source == IFSRC_UNKNOWN + && sym->ts.type == BT_UNKNOWN)) { /* If we find that a flavorless symbol is an interface in one of the
(In reply to janus from comment #7) > I propose the following patch: ... which regtests cleanly.
Author: janus Date: Mon Dec 30 17:33:21 2013 New Revision: 206249 URL: http://gcc.gnu.org/viewcvs?rev=206249&root=gcc&view=rev Log: 2013-12-30 Janus Weil <janus@gcc.gnu.org> PR fortran/58998 * resolve.c (resolve_symbol): Check that symbol is not only flavorless but also untyped. 2013-12-30 Janus Weil <janus@gcc.gnu.org> PR fortran/58998 * gfortran.dg/generic_28.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/generic_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Author: janus Date: Tue Dec 31 14:02:04 2013 New Revision: 206266 URL: http://gcc.gnu.org/viewcvs?rev=206266&root=gcc&view=rev Log: 2013-12-31 Janus Weil <janus@gcc.gnu.org> Backport from mainline 2013-12-30 Janus Weil <janus@gcc.gnu.org> PR fortran/58998 * resolve.c (resolve_symbol): Check that symbol is not only flavorless but also untyped. 2013-12-31 Janus Weil <janus@gcc.gnu.org> Backport from mainline 2013-12-30 Janus Weil <janus@gcc.gnu.org> PR fortran/58998 * gfortran.dg/generic_28.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/generic_28.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/resolve.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
Fixed for 4.9.0 and 4.8.3. Closing.