Hi, here's an interface related bug I discovered which is not yet mentioned in PR 29670. % gfortran gfcbug46.f90 gfcbug46.f90:25.29: call random_number (t% x) 1 Error: There is no specific subroutine for the generic 'random_number' at (1) gfcbug46.f90:20.29: call random_seed (size=n) 1 Error: There is no specific subroutine for the generic 'random_seed' at (1) The code is standard-conforming and works with other compilers. See the attached code for details.
Created attachment 12752 [details] Interface bug demo code
Harald, I agree that other compilers handle this OK but is it valid? As far as I can tell, random_number and random_seed are specific intrinsics. What should the form be here? Thanks for keeping us on our toes! Paul
> I agree that other compilers handle this OK but is it valid? I think it is. Think of the form interface operator(=) module procedure myassign end interface here the "generic-spec" is not a "generic-name" but an "operator (defined operator)", but for this case it should be clear that one can add "myassign" to the generic interface which contains the intrinsic operator(=). Analogously, I don't see any reason why one shouldn't be able to enhance "random_number" by a procedure which takes different arguments. And now more formally "12.4.4 Resolving named procedure references" "(1) A procedure name is established to be generic in a scoping unit (a) if that scoping unit contains an interface block with that name;" Next step: "12.4.4.1 Resolving procedure references to names established to be generic" "(3) If (1) and (2) do not apply, if the scoping unit contains either an INTRINSIC attribute specification for that name" (If one adds to "random_vector(t)" an "Intrinsic random_number" it indeed works also with gfortran.) Ok, still not resolved, next try: "12.4.4.3 Resolving procedure references to names not established" "(2) If (1) does not apply, if the name is the name of an intrinsic procedure, and if there is agreement between the reference and the status of the intrinsic procedure as being a function or subroutine, the reference is to that intrinsic procedure." Uff, finally found something which resolves it.
Harald, As usual, you provide us with the good ones. This problem arises because the resolution of intrinsics, if there is no matching specific interface, has been restricted to generics only. The following effects a cure and regtests OK. I will submit it with a suitable rendition of your testscase, as soon as I am back home. Paul
Created attachment 12805 [details] A fix for the PR that regtests OK This is the patch referred to previously. Paul
Subject: Bug number PR30081 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/msg01147.html
Subject: Bug 30081 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
(In reply to comment #7) Paul, a personal thanks for taking care of this one. With this patch in place, I was now able proceed compiling a major software piece just to hit the next gfc_todo (PR 30273)... Anyway, a merry x-mas and a happy to year to all actively involved in fixing gfortran.
Subject: Bug 30081 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