[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #17 from pault at gcc dot gnu dot org 2008-11-08 06:20 --- Subject: Bug 37445 Author: pault Date: Sat Nov 8 06:19:12 2008 New Revision: 141706 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141706 Log: 2008-11-08 Paul Thomas [EMAIL PROTECTED] PR fortran/37445 * resolve.c (resolve_call): Check host association is correct. (resolve_actual_arglist ): Remove return is old_sym is use associated. Only reparse expression if old and new symbols have different types. PR fortran/PR35769 * resolve.c (gfc_resolve_assign_in_forall): Change error to a warning. 2008-11-08 Paul Thomas [EMAIL PROTECTED] PR fortran/37445 * gfortran.dg/host_assoc_call_3.f90: New test. * gfortran.dg/host_assoc_call_4.f90: New test. * gfortran.dg/host_assoc_function_4.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_call_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_call_4.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_function_4.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #18 from pault at gcc dot gnu dot org 2008-11-08 06:49 --- Fixed on thrunk and 4.3. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #16 from pault at gcc dot gnu dot org 2008-11-03 06:46 --- Subject: Bug 37445 Author: pault Date: Mon Nov 3 06:44:47 2008 New Revision: 141543 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141543 Log: 2008-11-03 Paul Thomas [EMAIL PROTECTED] PR fortran/37445 * resolve.c (resolve_actual_arglist ): Correct comparison of FL_VARIABLE with e-expr_type. (resolve_call): Check that host association is correct. (resolve_actual_arglist ): Remove return is old_sym is use associated. Only reparse expression if old and new symbols have different types. PR fortran/PR35769 * resolve.c (gfc_resolve_assign_in_forall): Change error to a warning. 2008-11-03 Paul Thomas [EMAIL PROTECTED] PR fortran/37445 * gfortran.dg/host_assoc_call_3.f90: New test. * gfortran.dg/host_assoc_call_4.f90: New test. * gfortran.dg/host_assoc_function_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/host_assoc_call_3.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_call_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_function_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #15 from pault at gcc dot gnu dot org 2008-09-30 10:29 --- (In reply to comment #14) Created an attachment (id=16429) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16429action=view) [edit] Reduced test case which is failing with the patch OK - I'll get onto it! Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #12 from burnus at gcc dot gnu dot org 2008-09-29 10:25 --- Somehow the patch is not enough to compile program (see tar.gz / attachment 16266): gfortran -c syskindsM.f90 formatbankM.f90 charutilM.f90 tinyisetM.f90 timestampmodM.f90 errelmntM.f90 errstackM.f90 debugmodM.f90 parlistM.f90 winkindsM.f90 ewinhandM.f90 guiclrsM.f90 iso_varying_stringM.f90 windataM.f90 sysdepM.f90 winnowsM.f90 asciichrM.f90 winidenM.f90 BBModI.f90 hardmodM.f90 WinModI.f90 errormodM.f90 errormodM.f90:1083.32: Error: Type mismatch in argument 'arrayindex' at (1); passed TYPE(terrorelement) to INTEGER(4) errormodM.f90:668.114: Error: SUBROUTINE 'getbasicdata' at (1) cannot call itself, as it is not RECURSIVE The files compile without problems with NAG f95, ifort and g95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #13 from burnus at gcc dot gnu dot org 2008-09-29 21:39 --- Somehow the patch is not enough to compile program Actually the situation is worse -- the failure occurs now much earlier: w/ patch: Failure in errormodM.f90 (43th compiled file) w/o patch: Failure in cmndtypeM.f90 (80th compiled file) Thus I withdraw the OK for the patch http://gcc.gnu.org/ml/fortran/2008-09/msg00407.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #14 from burnus at gcc dot gnu dot org 2008-09-29 22:06 --- Created an attachment (id=16429) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16429action=view) Reduced test case which is failing with the patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #11 from pault at gcc dot gnu dot org 2008-09-28 20:38 --- See http://gcc.gnu.org/ml/fortran/2008-09/msg00407.html -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-09 18:06:44 |2008-09-28 20:38:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #6 from jv244 at cam dot ac dot uk 2008-09-10 06:38 --- (In reply to comment #5) 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. My standardese has become a bit rusty, but I think this just means that this would be invalid: SUBROUTINE S3 CALL putaline() CALL putaline(1) CONTAINS SUBROUTINE putaline(x) character, optional :: x END SUBROUTINE END SUBROUTINE since in the call 'CALL putaline(1)' the identifier refers to the scoping unit. All compilers you mentioned reject the above. I suspect the reduced program is valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #7 from jv244 at cam dot ac dot uk 2008-09-10 06:48 --- (In reply to comment #6): actually, I rather sure that gfortran gets it wrong. This would be a wrong-code MODULE M1 CONTAINS SUBROUTINE S1 write(6,*) M1 OK CALL ABORT() END SUBROUTINE END MODULE MODULE M2 USE M1 CONTAINS SUBROUTINE S2 CALL S1() CONTAINS SUBROUTINE S1 write(6,*) M2 OK END SUBROUTINE END SUBROUTINE END MODULE USE M2 CALL S2 END -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Keywords||rejects-valid, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #8 from burnus at gcc dot gnu dot org 2008-09-10 11:33 --- actually, I rather sure that gfortran gets it wrong. This would be a wrong-code Unless it were accepts-invalid. (Which I don't think, see below.) Unfortunately, I yesterday somehow completely missed the second CONTAINS, which makes putALine an internal procedure to subroutine S3, which changes the picture as this is no longer a USE-associated issue but a internal procedure vs. host-associated. Sorry for misreading this. I believe it is allowed per 16.4.1.3 Host association, but I cannot find the case of an internal procedure. Maybe it is also hidden in 16.2 Scope of local identifiers, which rules out some cases which do not apply (and one could argue it thus allows this not ruled out case). In any case, I believe (now that I saw the second CONTAINS) that the programs in comment 3 and comment 7 are valid. Sorry again for my misreading. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #9 from pault at gcc dot gnu dot org 2008-09-10 12:26 --- (In reply to comment #3) reduced: MODULE M1 INTERFACE putaline MODULE PROCEDURE S1,S2 END INTERFACE CONTAINS SUBROUTINE S1(I) END SUBROUTINE SUBROUTINE S2(F) END SUBROUTINE END MODULE MODULE M2 USE M1 CONTAINS SUBROUTINE S3 CALL putaline() CONTAINS SUBROUTINE putaline(x) character, optional :: x END SUBROUTINE END SUBROUTINE END MODULE USE M2 CALL S3 END I believe that this is valid, as you say. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #10 from pault at gcc dot gnu dot org 2008-09-10 12:33 --- (In reply to comment #3 resolve.c(check_host_association) explicitly excludes checking the symbol for the procedure if it is use associated. It might just be that the check should exclude symbols that are both host and use associated. I'll have to check tonight. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #4 from burnus at gcc dot gnu dot org 2008-09-09 18:44 --- Paul, sounds like a bug for you. * * * The problem is that gfortran calls the use-associated (generic or specific) procedure instead of the host-associated procedure. (The procedure is use-associated in the specification part of a module). If the procedure is USEd in the subroutine or in a PROGRAM, all compilers print an error. * * * I wonder whether the following is valid: module m2 use, only: s1 All compilers accept this. However, how to read then the following, assuming that s1 is also a host-associated procedure: MODULE M2 USE M1, only: s1 procedure(),pointer :: procptr = s1 (Note: procptr = s1 is Fortran 2008 syntax; F2003 only allows = null().) Actually, I would reject a program if only: is specified [or for use m2, s1=s2], but I have not checked the standard, yet. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Summary|incorrect error reported|Host-associated proc not ||found if same-name generic ||is use-associated http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
[Bug fortran/37445] Host-associated proc not found if same-name generic is use-associated
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-09 19:18 --- Thinking it over, I think the program is INVALID per 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. (I couldn't find anything special about specification parts in modules - not that I expected to find something. The quote above is for Fortran 2003, but the same is true for Fortran 2008; I have not checked Fortran 90/95 but I do not expect a different result.) That the program is invalid solves a huge number of potential problems, some of which I eluded some in comment 4. I was about to ask at comp.lang.fortran, but decided that it is obvious enough that there is no need to do so. Note: I believe that already subroutine putaline(...) is invalid. -- Even though g95, NAG f95, ifort, Lahey, and openf95 accept it, but it is not the first time that a lot of compilers have the same bug. If you don't agree, please find the relevant section in the standard or ask someone to do so at comp.lang.fortran. gfortran is still buggy as it accepts the program (if one comments out s3). -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|32834 | nThis|| Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37445
