User account creation filtered due to spam.

Bug 40443 - Elemental procedure in genericl interface incorrectly selected in preference to specific procedure
Summary: Elemental procedure in genericl interface incorrectly selected in preference ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: wrong-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2009-06-15 01:16 UTC by Ian Harvey
Modified: 2009-06-29 16:46 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-06-21 07:42:05


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Harvey 2009-06-15 01:16:11 UTC
F95 standard section 14.1.2.4.1 (particular Note 14.6) implies to me that when an elemental and a non-elemental specific procedure in a generic interface both "match" a reference, it is the specific instance that should be selected.

The reference selected by gfortran appears to depend on the ordering of procedures in the generic interface block.  I'd expect the last line of output from the following to be "S, S" as a result of selecting the specific procedure "SpecProc".  I get "E, E" which has come from the elemental procedure.


MODULE SomeOptions
  IMPLICIT NONE  
  INTERFACE ElemSpec
    MODULE PROCEDURE ElemProc
    MODULE PROCEDURE SpecProc
  END INTERFACE ElemSpec  
  INTERFACE SpecElem
    MODULE PROCEDURE SpecProc
    MODULE PROCEDURE ElemProc
  END INTERFACE SpecElem
CONTAINS
  ELEMENTAL SUBROUTINE ElemProc(a)  
    CHARACTER, INTENT(OUT) :: a
    !****
    a = 'E'            
  END SUBROUTINE ElemProc

  SUBROUTINE SpecProc(a)  
    CHARACTER, INTENT(OUT) :: a(:)
    !****    
    a = 'S'    
  END SUBROUTINE SpecProc
END MODULE SomeOptions

PROGRAM MakeAChoice
  USE SomeOptions  
  IMPLICIT NONE
  CHARACTER scalar, array(2)    
  !****
  CALL ElemSpec(scalar) ! Should choose the elemental (and does)
  WRITE (*, 100) scalar
  CALL ElemSpec(array)  ! Should choose the specific (and does)
  WRITE (*, 100) array
  !----
  CALL SpecElem(scalar) ! Should choose the elemental (and does)
  WRITE (*, 100) scalar
  CALL SpecElem(array)  ! Should choose the specific (but doesn't)
  WRITE (*, 100) array  
  !----
  100 FORMAT(A,:,', ',A)
END PROGRAM MakeAChoice


>gfortran --version
GNU Fortran (GCC) 4.5.0 20090421 (experimental) [trunk revision 146519]
Comment 1 Tobias Burnus 2009-06-15 07:46:11 UTC
Paul, I CC you as you are our generic-resolution expert.

 * * *

gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all print the following:

E
S, S
E
E, E   ! << you expect an "S, S" here

Looking at the following excerpt from Fortran 2003, it looks indeed as if all the compiler get it wrong. Especially, the standard does not assume (to my reading) that the generic resolution depends on the order. However, before changing it, one needs to double check - that several compiler gets it wrong and (of my collection) none gets it correct also happens only rarely.

 * * *

"12.4.4.1 Resolving procedure references to names established to be generic

"(1) If the reference is consistent with a nonelemental reference to one of the specific interfaces of a generic interface that has that name and either is in the scoping unit in which the reference appears or is made accessible by a USE statement in the scoping unit, the reference is to the specific procedure in the interface block that provides that interface. The rules in 16.2.3 ensure that there can be at most one such specific procedure.

 (2) If (1) does not apply, if the reference is consistent with an elemental reference to one of the specific interfaces of a generic interface that has that name and either is in the scoping unit in which the reference appears or is made accessible by a USE statement in the scoping unit, the reference is to the specific elemental procedure in the interface block that provides that interface. The rules in 16.2.3 ensure that there can be at most one such specific elemental procedure."
Comment 2 jpr 2009-06-15 08:28:36 UTC
(In reply to comment #1)
> Paul, I CC you as you are our generic-resolution expert.
> 
>  * * *
> 
> gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
> print the following:
> 
> E
> S, S
> E
> E, E   ! << you expect an "S, S" here
> 

FWIW, Portland and Intel compilers both print 

E
S, S
E
S, S

BR, Juha
Comment 3 Tobias Burnus 2009-06-15 11:24:02 UTC
> > gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
> > print the following:

Correction, ifort 9.1 to 11.1 all print "S, S" - sorry for missing it. But the other compilers listed above indeed print "E, E".

> FWIW, Portland and Intel compilers both print 
> S, S
Comment 4 Paul Thomas 2009-06-15 13:21:27 UTC
(In reply to comment #1)
> Paul, I CC you as you are our generic-resolution expert.

Well, gosh golly, that's a mantle that I did not seek:-)

Note that my account at the CC address is no longer valid - I'll fix that.

In the mean time I will peruse the standard.

Cheers

Paul
Comment 5 Dominique d'Humieres 2009-06-17 13:04:37 UTC
Note that the latest release of g95 gives now:

E
S, S
E
S, S
Comment 6 Paul Thomas 2009-06-21 07:42:04 UTC
This should be relatively easy to fix - I have not looked yet but I am rather sure I know what to do and where to do it.

Cheers

Paul
Comment 7 Paul Thomas 2009-06-22 04:41:23 UTC
Subject: Bug 40443

Author: pault
Date: Mon Jun 22 04:41:10 2009
New Revision: 148776

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148776
Log:
2009-06-22  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/40443
	* interface.c (gfc_search_interface): Hold back a match to an
	elementary procedure until all other possibilities are
	exhausted.

2009-06-22  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/40443
	* gfortran.dg/generic_18.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/generic_18.f90
Modified:
    trunk/gcc/fortran/interface.c

Comment 8 Paul Thomas 2009-06-22 04:42:07 UTC
Subject: Bug 40443

Author: pault
Date: Mon Jun 22 04:41:53 2009
New Revision: 148777

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148777
Log:
2009-06-22  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/40443
	* interface.c (gfc_search_interface): Hold back a match to an
	elementary procedure until all other possibilities are
	exhausted.

2009-06-22  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/40443
	* gfortran.dg/generic_18.f90: New test.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/testsuite/ChangeLog

Comment 9 Tobias Burnus 2009-06-29 07:49:35 UTC
Can this be backported to 4.4? If so, it should happen soonish to be in 4.4.1. Paul, shall I do it for you?
Comment 10 Paul Thomas 2009-06-29 09:23:24 UTC
(In reply to comment #9)
> Can this be backported to 4.4? If so, it should happen soonish to be in 4.4.1.
> Paul, shall I do it for you?
>

Thanks for the offer, Tobias - I'll be attending to it tonight.

Did you see that I have a fix for PR40551?

Cheers

Paul 

Comment 11 Paul Thomas 2009-06-29 16:45:06 UTC
Subject: Bug 40443

Author: pault
Date: Mon Jun 29 16:44:49 2009
New Revision: 149056

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149056
Log:
2009-06-29  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/40443
	* interface.c (gfc_search_interface): Hold back a match to an
	elementary procedure until all other possibilities are
	exhausted.

2009-06-29  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/40443
	* gfortran.dg/generic_18.f90: New test.

Added:
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/generic_18.f90
Modified:
    branches/gcc-4_4-branch/gcc/fortran/ChangeLog
    branches/gcc-4_4-branch/gcc/fortran/interface.c
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

Comment 12 Paul Thomas 2009-06-29 16:46:02 UTC
Fixed on trunk and 4.4

Thanks for the report

Paul