Bug 37445 - Host-associated proc not found if same-name generic is use-associated
Summary: Host-associated proc not found if same-name generic is use-associated
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: accepts-invalid, rejects-valid, wrong-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-09-09 15:56 UTC by Norman S. Clerman
Modified: 2008-11-08 06:49 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.4.0 4.3.0 4.2.0
Last reconfirmed: 2008-09-28 20:38:51


Attachments
bug4.tgz (255.11 KB, application/x-compressed-tar)
2008-09-09 16:03 UTC, Norman S. Clerman
Details
Reduced test case which is failing with the patch (420 bytes, text/plain)
2008-09-29 22:06 UTC, Tobias Burnus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Norman S. Clerman 2008-09-09 15:56:04 UTC
Hello,

I am attempting to build my lens design program. I encounter the following errors when I compile file cmndtypeM.f90:

cmndtypeM.f90:718.28:

    CALL putALine (UserLine)
                           1
Error: There is no specific subroutine for the generic 'putaline' at (1)
cmndtypeM.f90:723.20:

    CALL PutALine ()
                   1
Error: There is no specific subroutine for the generic 'putaline' at (1)
cmndtypeM.f90:726.20:

    call putALine ()
                   1
Error: There is no specific subroutine for the generic 'putaline' at (1)
cmndtypeM.f90:728.28:

    call putALine (UserLine)
                           1
Error: There is no specific subroutine for the generic 'putaline' at (1)
n

These are not errors. putALine is an internal subroutine hosted by subroutine dump_cmd. Please note that the g95, Intel, and NAG compilers all compile this code.

As soon as I am assigned a bug number, I will upload a tar file, bug4.tgz to
the following address: gcc-bugzilla@gcc.gnu.org. Unpack the file and invoke the
shell script bug4.sh to reproduce the problem.

I'll indicate the bug number in the subject line.

I am running Open SuSE 10.1 on a dual core Athlon chip. I'm using the gcc-trunk
build:

norm@oxford:~/design/gfortran/bug4> gfortran --version
GNU Fortran (GCC) 4.4.0 20080909 (experimental) [trunk revision 140137]
Copyright (C) 2008 Free Software Foundation, Inc.

I am not able to reduce the size of the problem.

Thank you for your attention.

Yours truly,

Norm Clerman
Comment 1 Norman S. Clerman 2008-09-09 16:03:14 UTC
Subject: bug 37445

Hello,

  Attached is a compressed archive containing the files you will need to reproduce bug 37445. Unpack the file and then invoke the shell script bug4.sh to accomplish this.

  I see that when I filled out the bug report form I put my comments about the bug  in the incorrect space. My apologies.

  If you have any questions or problems, don't hesitate to send me an e-mail.

Yours truly,

Norm Clerman
Comment 2 Norman S. Clerman 2008-09-09 16:03:17 UTC
Created attachment 16266 [details]
bug4.tgz
Comment 3 Joost VandeVondele 2008-09-09 18:06:44 UTC
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
Comment 4 Tobias Burnus 2008-09-09 18:44:54 UTC
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.
Comment 5 Tobias Burnus 2008-09-09 19:18:13 UTC
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").
Comment 6 Joost VandeVondele 2008-09-10 06:38:19 UTC
(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.
Comment 7 Joost VandeVondele 2008-09-10 06:48:08 UTC
(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

Comment 8 Tobias Burnus 2008-09-10 11:33:05 UTC
> 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.
Comment 9 Paul Thomas 2008-09-10 12:26:10 UTC
(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
Comment 10 Paul Thomas 2008-09-10 12:33:07 UTC
(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 
Comment 11 Paul Thomas 2008-09-28 20:38:51 UTC
See http://gcc.gnu.org/ml/fortran/2008-09/msg00407.html
Comment 12 Tobias Burnus 2008-09-29 10:25:00 UTC
Somehow the patch is not enough to compile program (see tar.gz / attachment 16266 [details]):

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.
Comment 13 Tobias Burnus 2008-09-29 21:39:18 UTC
> 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
Comment 14 Tobias Burnus 2008-09-29 22:06:23 UTC
Created attachment 16429 [details]
Reduced test case which is failing with the patch
Comment 15 Paul Thomas 2008-09-30 10:29:31 UTC
(In reply to comment #14)
> Created an attachment (id=16429) [edit]
> Reduced test case which is failing with the patch
> 

OK - I'll get onto it!

Thanks

Paul
Comment 16 Paul Thomas 2008-11-03 06:46:11 UTC
Subject: Bug 37445

Author: pault
Date: Mon Nov  3 06:44:47 2008
New Revision: 141543

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141543
Log:
2008-11-03  Paul Thomas  <pault@gcc.gnu.org>

	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  <pault@gcc.gnu.org>

	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

Comment 17 Paul Thomas 2008-11-08 06:20:40 UTC
Subject: Bug 37445

Author: pault
Date: Sat Nov  8 06:19:12 2008
New Revision: 141706

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141706
Log:
2008-11-08  Paul Thomas  <pault@gcc.gnu.org>

        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  <pault@gcc.gnu.org>

        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

Comment 18 Paul Thomas 2008-11-08 06:49:25 UTC
Fixed on thrunk and 4.3.

Thanks for the report.

Paul