Examples taken from the Fortran 2003 standard, Section C.11.2. They are not recognized as invalid. * * * INTERFACE BAD8 ! this interface is invalid ! ! despite the fact that it is unambiguous ! SUBROUTINE S8A(X,Y,Z) REAL,OPTIONAL :: X INTEGER :: Y REAL :: Z END SUBROUTINE S8A SUBROUTINE S8B(X,Z,Y) INTEGER,OPTIONAL :: X INTEGER :: Z REAL :: Y END SUBROUTINE S8B END INTERFACE BAD8 This interface fails rule (3) because there are no required arguments that can be distinguished from the positionally corresponding argument, but in order for the mismatch of the optional arguments not to be relevant, the later arguments must be specified as keyword arguments, so distinguishing by name does the trick. This interface is nevertheless invalid so a standard-conforming Fortran processor is not required to do such reasoning. The rules to cover all cases are too complicated to be useful. * * * module x INTERFACE BAD9 ! this interface is invalid ! ! despite the fact that it is unambiguous ! SUBROUTINE S9A(X) REAL :: X END SUBROUTINE S9A SUBROUTINE S9B(X) INTERFACE FUNCTION X(A) REAL :: X,A END FUNCTION X END INTERFACE END SUBROUTINE S9B SUBROUTINE S9C(X) INTERFACE FUNCTION X(A) REAL :: X INTEGER :: A END FUNCTION X END INTERFACE END SUBROUTINE S9C END INTERFACE BAD9 end module x The real data objects that would be valid arguments for S9A are entirely disjoint from procedures that are valid arguments to S9B and S9C, and the procedures that valid arguments for S9B are disjoint from the procedures that are valid arguments to S9C because the former are required to accept real arguments and the latter integer arguments. Again, this interface is invalid, so a standard-conforming Fortran processor need not examine such properties when deciding whether a generic collection is valid. Again, the rules to cover all cases are too complicated to be useful.
(In reply to comment #0) > Examples taken from the Fortran 2003 standard, Section C.11.2. > They are not recognized as invalid. BAD8 is, as of this evening's tree - I had to put an 'END' after the module so as not to surprise the compiler with an unexpected EOF. It then throws on the ambiguity between s8a and s8b. Right now, I cannot see why BAD9 does not throw an error - the code in interface.c looks OK. Paul
> Right now, I cannot see why BAD9 does not throw an error - the code in > interface.c looks OK. Ahhh, yes I can. gfc recurses through the formal interfaces of dummy procedures - it actually does it correctly too! Index: gcc/fortran/interface.c =================================================================== *** gcc/fortran/interface.c (revision 119554) --- gcc/fortran/interface.c (working copy) *************** compare_type_rank_if (gfc_symbol * s1, g *** 462,468 **** if (s1->attr.function && compare_type_rank (s1, s2) == 0) return 0; ! return compare_interfaces (s1, s2, 0); /* Recurse! */ } --- 462,468 ---- if (s1->attr.function && compare_type_rank (s1, s2) == 0) return 0; ! return 1; /* Recurse! */ } Fixes the problem and regtests OK. Paul
Sorry, cancel the previous comments - I had a screwed up tree. What I said was not correct. BADx remains undetected by gfc.... Paul
That the ambiguity in BAD8 is not detected is a regression; with 4.1 and yesterday's 4.2 I get: Error: Ambiguous interfaces 's8b' and 's8a' in generic interface 'bad8' at (1) I didn't check whether this is due to your just submitted patch, which I have applied locally, or is something older.
Created attachment 12760 [details] Fix and testcases. This regtests on Cygwin_NT/amd64. It is there, up to some adjustments to interpretation of the standard.
> Created an attachment (id=12760) [edit] > Fix and testcases. Thanks. > It is there, up to some adjustments to interpretation of the standard. Ok, I did some reading and got an email with a quote by Malcolm Cohen and a reply to that quote by Richard Main. See: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/44aa13e0102ec83d/) The relevant part of the standard is as follows (and no, I don't want to discuss the meaning of the word "is" [cf. c.l.fortran]) -- Fortran 2003, Section 11.2.1; F95, Sec 11.3.2: "Two or more accessible entities, other than generic interfaces or defined operators, may have the same identifier only if the identifier is not used to refer to an entity in the scoping unit. Generic interfaces and defined operators are handled as described in section 16.2.3. Except for these cases, the local identifier of any entity given accessibility by a USE statement shall differ from the local identifiers of all other entities accessible to the scoping unit through USE statements and otherwise." [plus some other places for some of the following remarks] That means (if I understand it correctly): a) Using an ambigious symbol in a program, module, procedure twice, which is ambious is forbidden. This makes the BAD8 and BAD9 of the Fortran standard invalid, if they are put in one "module foo ... end module" or "program bar ... end program" or "subroutine func ... end subroutine" block. Or when one is locally declared, which is imported ("use") from a module. b) Importing a symbol (subroutine, variable) from two module, which are ambiguous is ok as long as they are not referred. ",only:" is enough to count as referred to. c) For generic interfaces and operators the standard is ambiguous. Richard Main thinks that they are treated alike (b), Malcolm Cohn thinks they should be treated more strictly, which already makes "use mod1; use mod2" of my example invalid. d) Having e.g. a variable in module and an interface/procedure in another routine is always invalid. Assuming my understanding is correct, the following cases are not correctly treated: a) BAD8 and BAD9 as already the module ("module x" in the patch) shouldn't compile - or give a warning. [I would go for the warning as the intel compiler does] b) May "use mod1; use mod2" should also produce a warning even without ", only:" as there the generic interface "generic" is ambigious. Or not. NAG f95 (future version) produces an error, following Malcolm Cohen of NAG which is what sunf95 and g95 are doing as well; ifort accepts it without any warning and Richard Main thinks it is ok. Do either one. [Maybe a warning is not bad - it is between error (some compilers) and silence (other compilers) and we don't take sides ;-) ] c) Gfortran is a bit inconsequent with regards to ", only:" use mod1 use mod2,only: foo compiles without an error/warning whereas for use mod1,only: foo use mod2 it gives a warning. ifort is consequent in this regard and warns in both cases (for generic interfaces) - or in none (see d). d) Interestingly, if I have module mod1; contains; subroutine foo(); end subroutine foo; end module module mod2; contains; subroutine foo(); end subroutine foo; end module program use mod1, only: foo use mod2 end program Neither ifort nor sunf95 give error or warnings. (For generic interfaces they give a warning (ifort) or an error (sunf95).) (g95 and f95 don't count since they give currently either always an error nor never.) I don't see a reason why generic interfaces should be treated more strictly and thus go with this patch [gfortran gives then a warning]. e) Slightly related: use mod1 ! imports subroutine foo real :: foo end gives the error: Error: Symbol 'foo' at (1) cannot have a type
Subject: Re: Ambigous interfaces not detected Tobias, > > c) Gfortran is a bit inconsequent with regards to ", only:" > use mod1 > use mod2,only: foo > compiles without an error/warning whereas for > use mod1,only: foo > use mod2 > The lack of symmetry is in the setting of attr.ambiguous - I don't know why. My head is hurting and I am going to bed. The other problem is fixed. Paul
Created attachment 12768 [details] Patch and testcases I believe that this is consistent with the discussion on comp.lang.fortran. The references to the standard are needed in the testcases and ChangeLogs are required - are you in a position to do this, Tobias? I am up to my eyeballs in daytime work and have to entertain some colleagues tonight. Paul
> I believe that this is consistent with the discussion on comp.lang.fortran. Looks ok, quick tests with some examples looks also ok and it also regression test on x86_64-unknown-linux-gnu. > The references to the standard are needed in the testcases and ChangeLogs are > required - are you in a position to do this, Tobias? I am up to my eyeballs in > daytime work and have to entertain some colleagues tonight. No, I was too busy, sorry. Maybe tomorrow - or you are faster ;-) I'm not completely happy with the wording of Warning: Although not referenced, generic at (1) has ambiguous interfaces How about a simple (note: I added '' around the %s): Warning: 'generic' at (1) has ambiguous interfaces I'm quite sure I wouldn't have understood the "Although not referenced" correctly without the deep look at the standard. And if it is indeed referenced and not only referred to, then one gets an error message anyhow.
Subject: Re: Ambigous interfaces not detected burnus, > > I'm quite sure I wouldn't have understood the "Although not referenced" > correctly without the deep look at the standard. > And if it is indeed referenced and not only referred to, then one gets an error > message anyhow. > It actually is not referenced - I took onboard what Richard said about not referred to. He is right. The mind boggles at a discussion about the meaning of "is" though :-) To be honest, Tobias, I am getting a bit stuck. I'll see what I can do between now and Sunday afternoon when I depart for Wien... After that, it's up to you. I have many more opportunities, these days, for fixing things than for the nitty-gritty of submission and committing. I can see a fix for 30096, by the way.... Paul
Created attachment 12771 [details] Fix for this and pr30096 This one regtests and fixes PR30096. I will submit it tomorrow. Paul
Paul, > Fix for this and pr30096 > This one regtests and fixes PR30096. > I will submit it tomorrow. Hmm, then I submitted too early. But you might save some time by doing simply a reply to http://gcc.gnu.org/ml/fortran/2006-12/msg00124.html I still would like to see the following change: - gfc_warning ("Although not referenced, %s at %L has ambiguous " + gfc_warning ("Although not referenced, '%s' at %L has ambiguous " "interfaces", sym->name, &sym->declared_at); Otherwise it looks ok. Tobias
Subject: Bug 30068 Author: pault Date: Sat Dec 9 21:13:29 2006 New Revision: 119697 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119697 Log: 2006-12-09 Paul Thomas <pault@gcc.gnu.org> PR fortran/29975 PR fortran/30068 PR fortran/30096 * interface.c (compare_type_rank_if): Reject invalid generic interfaces. (check_interface1): Give a warning for nonreferred to ambiguous interfaces. (check_sym_interfaces): Check whether an ambiguous interface is referred to. Do not check host associated interfaces since these cannot be ambiguous with the local versions. (check_uop_interface, gfc_check_interfaces): Update call to check_interface1. * symbol.c (gfc_get_sym_tree, gfc_get_sym_tree): Allow adding unambiguous procedures to generic interfaces. * gfortran.h (symbol_attribute): Added use_only and ambiguous_interfaces. * module.c (load_need): Set the use_only flag, if needed. * resolve.c (resolve_fl_procedure): Warn for nonreferred interfaces. * expr.c (find_array_section): Fix initializer array contructor. 2006-12-09 Paul Thomas <pault@gcc.gnu.org> Tobias Burnus <burnus@gcc.gnu.org> PR fortran/29975 PR fortran/30068 * gfortran.dg/interface_4.f90: Test adding procedure to generic interface. * gfortran.dg/interface_5.f90: Test warning for not-referenced-to ambiguous interfaces. * gfortran.dg/interface_6.f90: Test invalid, ambiguous interface. * gfortran.dg/interface_7.f90: Test invalid, ambiguous interface. * gfortran.dg/interface_8.f90: Test warning for not-referenced-to ambiguous interfaces. * gfortran.dg/interface_1.f90: Change dg-error into a dg-warning. * gfortran.dg/array_initializer_2.f90: Add initializer array constructor test. PR fortran/30096 * gfortran.dg/interface_9.f90: Test that host interfaces are not checked for ambiguity with the local version. Added: trunk/gcc/testsuite/gfortran.dg/interface_4.f90 trunk/gcc/testsuite/gfortran.dg/interface_5.f90 trunk/gcc/testsuite/gfortran.dg/interface_6.f90 trunk/gcc/testsuite/gfortran.dg/interface_7.f90 trunk/gcc/testsuite/gfortran.dg/interface_8.f90 trunk/gcc/testsuite/gfortran.dg/interface_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/array_initializer_2.f90 trunk/gcc/testsuite/gfortran.dg/generic_7.f90 trunk/gcc/testsuite/gfortran.dg/interface_1.f90
Subject: Bug 30068 Author: pault Date: Thu Dec 21 15:05:24 2006 New Revision: 120113 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120113 Log: 2006-12-21 Paul Thomas <pault@gcc.gnu.org> PR fortran/29975 PR fortran/30068 PR fortran/30096 * interface.c (compare_type_rank_if): Reject invalid generic interfaces. (check_interface1): Give a warning for nonreferred to ambiguous interfaces. (check_sym_interfaces): Check whether an ambiguous interface is referred to. Do not check host associated interfaces since these cannot be ambiguous with the local versions. (check_uop_interface, gfc_check_interfaces): Update call to check_interface1. * symbol.c (gfc_get_sym_tree, gfc_get_sym_tree): Allow adding unambiguous procedures to generic interfaces. * gfortran.h (symbol_attribute): Added use_only and ambiguous_interfaces. * module.c (load_need): Set the use_only flag, if needed. * resolve.c (resolve_fl_procedure): Warn for nonreferred interfaces. * expr.c (find_array_section): Fix initializer array contructor. 2006-12-21 Paul Thomas <pault@gcc.gnu.org> Tobias Burnus <burnus@gcc.gnu.org> PR fortran/29975 PR fortran/30068 * gfortran.dg/interface_4.f90: Test adding procedure to generic interface. * gfortran.dg/interface_5.f90: Test warning for not-referenced-to ambiguous interfaces. * gfortran.dg/interface_6.f90: Test invalid, ambiguous interface. * gfortran.dg/interface_7.f90: Test invalid, ambiguous interface. * gfortran.dg/interface_8.f90: Test warning for not-referenced-to ambiguous interfaces. * gfortran.dg/interface_1.f90: Change dg-error into a dg-warning. * gfortran.dg/array_initializer_2.f90: Add initializer array constructor test. PR fortran/30096 * gfortran.dg/interface_9.f90: Test that host interfaces are not checked for ambiguity with the local version. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_4.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_5.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_6.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_7.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_8.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_9.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/expr.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/module.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/symbol.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/array_initializer_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/generic_7.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/interface_1.f90
Fixed on trunk and 4.2 Paul