The following code is accepted by gfortran while ifort rejects it with error messages as quoted below. $> cat foo.f90 MODULE class_foo_type TYPE :: foo INTEGER :: dummy END TYPE END MODULE MODULE class_foo USE class_foo_type, ONLY: foo INTERFACE foo_init MODULE PROCEDURE foo_init_default END INTERFACE INTERFACE SUBROUTINE foo_init_default(this) USE class_foo_type, ONLY: foo TYPE(foo), INTENT(out) :: this END SUBROUTINE END INTERFACE END MODULE $> gfortran-4.3 -g -Wall -pedantic -std=f95 -c foo.f90 && echo "ok" ok $> gfortran-4.3 -v version 4.3.0 20061116 (experimental) $> ifort -g -warn all -c foo.f90 fortcom: Error: foo.f90, line 15: The procedure name of the INTERFACE block conflicts with a name in the encompassing scoping unit. [FOO_INIT_DEFAULT] SUBROUTINE foo_init_default(this) -------------^ fortcom: Error: foo.f90, line 11: Unresolved MODULE PROCEDURE specification name. [FOO_INIT_DEFAULT] MODULE PROCEDURE foo_init_default -------------------^ compilation aborted for foo.f90 (code 1) The following is accepted likewise:
(report continued) $> cat foo2.f90 MODULE class_foo_type TYPE :: foo INTEGER :: dummy END TYPE END MODULE MODULE class_foo USE class_foo_type, ONLY: foo INTERFACE foo_init SUBROUTINE foo_init_default(this) USE class_foo_type, ONLY: foo TYPE(foo), INTENT(out) :: this END SUBROUTINE END INTERFACE END MODULE
Confirm. Currently, the two interfaces clash: MODULE PROCEDURE foo_init_default SUBROUTINE foo_init_default(this) The latter needs to be "contains"ed in the module not put into an interface. * * * Error message from NAG f95: SUBROUTINE foo_init_default(this) ^ "afdf.f90", Line = 15, Column = 14: ERROR: "FOO_INIT_DEFAULT" is a module-subprogram, therefore it must not be a subroutine in an interface block.
Created attachment 12806 [details] Patch for the problem that regtests OK Daniel, As our regular contributors of 'real' bugs, you have excelled on this one. Thanks! It turns out that we do not have any means to identify a 'module procedure'. The attribute PROC_MODULE defines any procedure defined in a module. I have added a proc_mod attribute that marks a specific procedure that is so declared to overcome this. If anybody has a nifty way around this, please let me know. The attached does the right thing, regtests OK and, in addition, prevents such interfaces from being use associated. Paul
Subject: Bug number PR29992 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01146.html
I must have cleared this but I do not recall so doing - consider it unfixed! Paul
Subject: Bug 29992 Author: pault Date: Wed Dec 20 13:48:06 2006 New Revision: 120072 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120072 Log: 2006-12-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/29992 * interface.c (check_sym_interfaces): Module procedures in a generic must be use associated or contained in the module. * decl.c (gfc_match_modproc): Set attribute mod_proc. * gfortran.h (symbol_attribute): Add mod_proc atribute. PR fortran/30081 * resolve.c (resolve_generic_f, resolve_generic_s): Use gfc_intrinsic_name to find out if the function is intrinsic because it does not have to be a generic intrinsic to be overloaded. 2006-12-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/29992 * gfortran.dg/generic_9.f90: New test. PR fortran/30081 * gfortran.dg/generic_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/generic_10.f90 trunk/gcc/testsuite/gfortran.dg/generic_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 29992 Author: pault Date: Sun Dec 31 15:00:18 2006 New Revision: 120298 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120298 Log: 2006-12-31 Paul Thomas <pault@gcc.gnu.org> BACKPORTS from 4.3 PR fortran/30202 * trans-array.c (gfc_conv_function_call): Use parmse.expr for the nullifying of intent(out) arguments rather than the backend declaration. PR fortran/30190 * trans-array.c (gfc_conv_array_ref): Remove gfc_evaluate_now from the -fbounds-check branch. PR fortran/29992 * interface.c (check_sym_interfaces): Module procedures in a generic must be use associated or contained in the module. * decl.c (gfc_match_modproc): Set attribute mod_proc. * gfortran.h (symbol_attribute): Add mod_proc atribute. PR fortran/30081 * resolve.c (resolve_generic_f, resolve_generic_s): Use gfc_intrinsic_name to find out if the function is intrinsic because it does not have to be a generic intrinsic to be overloaded. PR fortran/30236 * interface.c (compare_interfaces): Handle NULL symbols. (count_types_test): Count NULL symbols, which correspond to alternate returns. (check_interface1): Change final argument from int to bool in the function and all references. 2006-12-31 Paul Thomas <pault@gcc.gnu.org> BACKPORTS from 4.3 PR fortran/30202 * gfortran.dg/alloc_comp_basics_3.f90: New test. PR fortran/30190 * gfortran.dg/bounds_check_5.f90: New test. PR fortran/29992 * gfortran.dg/generic_9.f90: New test. PR fortran/30081 * gfortran.dg/generic_10.f90: New test. PR fortran/30236 * gfortran.dg/altreturn_3.f90: New test. * gfortran.dg/char_result_12.f90: Fix comment typos. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/alloc_comp_basics_3.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/bounds_check_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/generic_10.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/generic_9.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/decl.c branches/gcc-4_2-branch/gcc/fortran/gfortran.h branches/gcc-4_2-branch/gcc/fortran/interface.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-array.c branches/gcc-4_2-branch/gcc/fortran/trans-expr.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
Fixed on trunk and 4.2 Paul