Bug 47710 - [OOP] Improve ambiguity check for GENERIC TBP w/ PASS and NOPASS
Summary: [OOP] Improve ambiguity check for GENERIC TBP w/ PASS and NOPASS
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: janus
URL:
Keywords: accepts-invalid
: 37297 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-02-12 09:03 UTC by Tobias Burnus
Modified: 2012-06-22 21:17 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-06-17 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2011-02-12 09:03:37 UTC
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9a2837d8aee4e38c

There is potentially a problem with the ambiguity check for TBP of the form

  procedure, nopass :: baseproc_nopass => baseproc
  procedure, pass   :: baseproc_pass => baseproc 

That is: Both TBP point to the same procedure, though through the PASS and NOPASS they should be distinguishable.

It is a bit unclear whether this is valid - also Richard Maine is confused ;-)
One might want to ask at J3 - maybe up to an interpretation request.

  * * *

Janus' example (cf. also below) should be truly ambiguous:

module mod

  type base_t
  contains
    procedure, nopass :: baseproc_nopass => baseproc1
    procedure, pass   :: baseproc_pass => baseproc2
    generic           :: some_proc => baseproc_pass, baseproc_nopass
  end type

contains

  subroutine baseproc1 (this)
    class(base_t) :: this
    print *, 'baseproc1'
  end subroutine

  subroutine baseproc2 (this,that)
    class(base_t) :: this, that
    print *, 'baseproc2'
  end subroutine

end module

program p
  use mod
  type(base_t) :: t

  call t%some_proc(t)  ! ambiguous!!!
end program
Comment 1 Tobias Burnus 2011-02-12 09:47:53 UTC
The first example is rejected by ifort (12.0? with a warning - but works) and NAG (5.1, 5.2? - error); crayftn and gfortran accept it.
The second example by Janus is accepted by gfortran, NAG 5.1 (both call baseproc1) and by Crayftn (calls baseproc2) - I have not checked with ifort 12 (ifort 11.1 does not support TBP GENERIC).
(Both programs are rejected by PGI 10.5 at a different place which looks like a compiler bug.)

 * * *

In Fortran 2008, this is covered by C1215 in "12.4.3.4.5 Restrictions on generic declarations".

To valid, a program needs to fulfil one of the items (1) to (3); I agree with Richard Maine that the following should be fulfilled for the first program:

"(1) there is a non-passed-object dummy data object in one or the
 other of them such that
    (a) the number of dummy data objects in one that are nonoptional,
        are not passed-object, and with which that dummy data object is TKR
        compatible, possibly including that dummy data object itself,
    exceeds
    (b) the number of non-passed-object dummy data objects, both optional
        and nonoptional, in the other that are not distinguishable from
        that dummy data object,"

"baseproc_nopass" has *one* nonoptional "non-passed-object dummy" this exceeds the number of "non-passed-object dummy data objects" of "baseproc_pass", which has no non-passed-object dummy. Hence, the program should be valid.

For Janus's program, both have exactly the same number of non-passed-object dummies: Namely one. "(2)" does not apply as only one has "pass" and "(3)" also does not seem to be fulfilable. Hence, the program should be invalid.
Comment 2 janus 2011-09-10 08:45:01 UTC
*** Bug 37297 has been marked as a duplicate of this bug. ***
Comment 3 janus 2011-09-10 08:47:40 UTC
Another example test case (from PR37297):


MODULE m

  IMPLICIT NONE

  TYPE t
  CONTAINS
    PROCEDURE, PASS :: proc1
    PROCEDURE, NOPASS :: proc2
    GENERIC :: gen => proc1, proc2
  END TYPE

CONTAINS

  SUBROUTINE proc1 (me)
    CLASS(t) :: me
  END SUBROUTINE

  SUBROUTINE proc2 ()
  END SUBROUTINE

END MODULE

PROGRAM main
  USE m
  IMPLICIT NONE
  TYPE(t) :: myobj
  CALL myobj%gen ()
END PROGRAM main
Comment 4 janus 2012-06-17 17:46:55 UTC
Note: Comment 3 is fixed by the patch at http://gcc.gnu.org/ml/fortran/2012-06/msg00111.html, but comment 0 is not.
Comment 5 janus 2012-06-17 21:28:32 UTC
(In reply to comment #4)
> Note: Comment 3 is fixed by the patch at
> http://gcc.gnu.org/ml/fortran/2012-06/msg00111.html, but comment 0 is not.

Updated patch fixes both:

http://gcc.gnu.org/ml/fortran/2012-06/msg00118.html
Comment 6 janus 2012-06-22 21:05:55 UTC
Author: janus
Date: Fri Jun 22 21:05:51 2012
New Revision: 188902

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188902
Log:
2012-06-22  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/47710
	PR fortran/53328
	* interface.c (count_types_test, generic_correspondence,
	gfc_compare_interfaces): Ignore PASS arguments.
	(check_interface1, compare_parameter): Pass NULL arguments to
	gfc_compare_interfaces.
	* gfortran.h (gfc_compare_interfaces): Modified prototype.
	* expr.c (gfc_check_pointer_assign): Pass NULL arguments to
	gfc_compare_interfaces.
	* resolve.c (resolve_structure_cons): Ditto.
	(check_generic_tbp_ambiguity): Determine PASS arguments and pass them
	to gfc_compare_interfaces.


2012-06-22  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/47710
	PR fortran/53328
	* gfortran.dg/typebound_generic_12.f03: New.
	* gfortran.dg/typebound_generic_13.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/typebound_generic_12.f03
    trunk/gcc/testsuite/gfortran.dg/typebound_generic_13.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
Comment 7 janus 2012-06-22 21:17:23 UTC
Fixed with r188902. Closing.