[Patch, fortran] PR33542 - gfortran does not detect ambigious specific names if they are the same as generic names

[Patch, fortran] PR33542 - gfortran does not detect ambigious specific names if they are the same as generic names

[Paul Richard Thomas]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

:ADDPATCH fortran:

This is the obvious version of the 'obvious' patch that wasn't.  Sorry
about the last mess.

The general rule is that use associated symbols can be ambiguous just
as long as they are not referenced.  This is done so that other
symbols may be used from these modules that are not ambiguous, without
necessitating only clauses.

In the case of this PR, the symtree for 'foo' is ambiguous, where
there are two identically named specific procedures.  Thus, the trick
is to make sure this is detected when resolving the actual argument.
The testcase is the original..

This time, I have tested tonto-2.3 with the patch, as well as
bootstrapping and regtesting.

OK for trunk?

Paul

2007-10-07  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/33542
	* resolve.c (resolve_actual_arglist): If the actual argument is
	ambiguous, then there is an error.

2007-10-07  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/33542
	* gfortran.dg/ambiguous_specific_1.f90: New test.


-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: submit.diff --]
[-- Type: text/x-patch; name="submit.diff", Size: 1776 bytes --]

Index: /svn/trunk/gcc/fortran/resolve.c
===================================================================
*** /svn/trunk/gcc/fortran/resolve.c	(revision 129068)
--- /svn/trunk/gcc/fortran/resolve.c	(working copy)
*************** resolve_actual_arglist (gfc_actual_argli
*** 971,976 ****
--- 971,983 ----
  	  continue;
  	}
  
+       if (e->expr_type == FL_VARIABLE && e->symtree->ambiguous)
+ 	{
+ 	  gfc_error ("'%s' at %L is ambiguous", e->symtree->n.sym->name,
+ 		     &e->where);
+ 	  return FAILURE;
+ 	}
+ 
        if (e->ts.type != BT_PROCEDURE)
  	{
  	  if (gfc_resolve_expr (e) != SUCCESS)
Index: /svn/trunk/gcc/testsuite/gfortran.dg/ambiguous_specific_1.f90
===================================================================
*** /svn/trunk/gcc/testsuite/gfortran.dg/ambiguous_specific_1.f90	(revision 0)
--- /svn/trunk/gcc/testsuite/gfortran.dg/ambiguous_specific_1.f90	(revision 0)
***************
*** 0 ****
--- 1,38 ----
+ ! { dg-do compile }
+ ! Checks the fix for PR33542, in which the ambiguity in the specific
+ ! interfaces of foo was missed.
+ !
+ ! Contributed by Tobias Burnus <burnus@gcc.gnu.org>
+ !
+ MODULE M1
+    INTERFACE FOO
+      MODULE PROCEDURE FOO
+    END INTERFACE
+ CONTAINS
+    SUBROUTINE FOO(I)
+      INTEGER, INTENT(IN) :: I
+      WRITE(*,*) 'INTEGER'
+    END SUBROUTINE FOO
+ END MODULE M1
+ 
+ MODULE M2
+    INTERFACE FOO
+      MODULE PROCEDURE FOO
+    END INTERFACE
+ CONTAINS
+    SUBROUTINE FOO(R)
+      REAL, INTENT(IN) :: R
+      WRITE(*,*) 'REAL'
+    END SUBROUTINE FOO
+ END MODULE M2
+ 
+ PROGRAM P
+    USE M1
+    USE M2
+    implicit none
+    external bar
+    CALL FOO(10)
+    CALL FOO(10.)
+    call bar (foo)  ! { dg-error "is ambiguous" }
+ END PROGRAM P
+ ! { dg-final { cleanup-modules "m1 m2" } }

Re: [Patch, fortran] PR33542 - gfortran does not detect ambigious specific names if they are the same as generic names

[Tobias Schlüter]

Paul Richard Thomas wrote:
> +       if (e->expr_type == FL_VARIABLE && e->symtree->ambiguous)
> + 	{
> + 	  gfc_error ("'%s' at %L is ambiguous", e->symtree->n.sym->name,
> + 		     &e->where);
> + 	  return FAILURE;
> + 	}

I forgot how we handle renames (I mean USE X, A=>B), but I'm guessing 
that e->symtree->name would be the safe choice for the name to print. 
Also a testcase with renaming would be a good thing to have.

Unless there is trouble with renaming, the patch is ok.

Cheers,
- Tobi

Re: [Patch, fortran] PR33542 - gfortran does not detect ambigious specific names if they are the same as generic names

[Jerry DeLisle]

Paul Richard Thomas wrote:
> :ADDPATCH fortran:
> 
> This is the obvious version of the 'obvious' patch that wasn't.  Sorry
> about the last mess.
> 
> The general rule is that use associated symbols can be ambiguous just
> as long as they are not referenced.  This is done so that other
> symbols may be used from these modules that are not ambiguous, without
> necessitating only clauses.
> 
> In the case of this PR, the symtree for 'foo' is ambiguous, where
> there are two identically named specific procedures.  Thus, the trick
> is to make sure this is detected when resolving the actual argument.
> The testcase is the original..
> 
> This time, I have tested tonto-2.3 with the patch, as well as
> bootstrapping and regtesting.
> 
> OK for trunk?
> 
> Paul
> 
> 2007-10-07  Paul Thomas  <pault@gcc.gnu.org>
> 
> 	PR fortran/33542
> 	* resolve.c (resolve_actual_arglist): If the actual argument is
> 	ambiguous, then there is an error.
> 
> 2007-10-07  Paul Thomas  <pault@gcc.gnu.org>
> 
> 	PR fortran/33542
> 	* gfortran.dg/ambiguous_specific_1.f90: New test.
> 
> 
> 
OK

Re: [Patch, fortran] PR33542 - gfortran does not detect ambigious specific names if they are the same as generic names

[Paul Richard Thomas]

Tobias,


> Unless there is trouble with renaming, the patch is ok.

I'll give it a try but I'm rather sure that it's OK.

Cheers

Paul

-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy