Re: [Patch, fortran] PR35997 - [4.3/4.4 regression]Used function interface bug

Re: [Patch, fortran] PR35997 - [4.3/4.4 regression]Used function interface bug

[FX]

> 2008-04-28  Paul Thomas  <pault@gcc.gnu.org>
>
> 	PR fortran/35997
> 	* module.c (find_symbol): Do not return a result for a symbol
> 	that has been renamed in another module.

OK to commit. Please wait a bit before 4.3.

FX



-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: [Patch, fortran] PR35997 - [4.3/4.4 regression]Used function interface bug

[Paul Richard Thomas]

FX,


> OK to commit. Please wait a bit before 4.3.
>

Many thanks - I was going to mail the list to the effect that I had
already committed to trunk on the grounds that the patch is
(semi-)obvious and rather isolated in its effect.  I am forced to wait
a bit before committing to 4.3 because I'll be out of town until early
next week:)

Cheers

Paul

[Patch, fortran] PR35997 - [4.3/4.4 regression]Used function interface bug

[Paul Richard Thomas]

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

:ADDPATCH fortran:

This is yet another regression that I have caused - hopefully they are
drying up:)

The problem arises because the present version of module.c does not
add a new symtree that is not renamed if the symbol is already
present.  The test in module.c(find_symbol) was failing to resolve the
case where the renaming is already done in the module that is being
use associated.  This patch accomplishes this by looking for a symtree
with the same name as the symbol and, upon failure, checking that the
symbol is not
renamed; this can only correspond to the unresolved case.

Notice that the reporter focussed on interface functions - this bug
applies to ANY symbol that is renamed in another module and available
by use association from that module.  Accordingly the test case has,
in addition to the function of the reporter's testcase, a variable.
This is a trivial extension but it is as well to establish the
principle.

This has been regtested on Cygwin_NT/amd64 - I'll do a full bootstrap
and regtest when I get home - OK for trunk and 4.3?

Paul

2008-04-28  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/35997
	* module.c (find_symbol): Do not return a result for a symbol
	that has been renamed in another module.

2008-04-28  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/35997
	* gfortran.dg/use_rename_3.f90

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

Index: /svn/svn4.3/gcc-4_3-branch/gcc/fortran/module.c
===================================================================
*** /svn/svn4.3/gcc-4_3-branch/gcc/fortran/module.c	(revision 134754)
--- /svn/svn4.3/gcc-4_3-branch/gcc/fortran/module.c	(working copy)
*************** find_symtree_for_symbol (gfc_symtree *st
*** 3146,3158 ****
  /* A recursive function to look for a speficic symbol by name and by
     module.  Whilst several symtrees might point to one symbol, its
     is sufficient for the purposes here than one exist.  Note that
!    generic interfaces are distinguished.  */
  static gfc_symtree *
  find_symbol (gfc_symtree *st, const char *name,
  	     const char *module, int generic)
  {
    int c;
!   gfc_symtree *retval;
  
    if (st == NULL || st->n.sym == NULL)
      return NULL;
--- 3146,3159 ----
  /* A recursive function to look for a speficic symbol by name and by
     module.  Whilst several symtrees might point to one symbol, its
     is sufficient for the purposes here than one exist.  Note that
!    generic interfaces are distinguished as are symbols that have been
!    renamed in another module.  */
  static gfc_symtree *
  find_symbol (gfc_symtree *st, const char *name,
  	     const char *module, int generic)
  {
    int c;
!   gfc_symtree *retval, *s;
  
    if (st == NULL || st->n.sym == NULL)
      return NULL;
*************** find_symbol (gfc_symtree *st, const char
*** 3162,3169 ****
  	     && strcmp (module, st->n.sym->module) == 0
  	     && !check_unique_name (st->name))
      {
!       if ((!generic && !st->n.sym->attr.generic)
! 	     || (generic && st->n.sym->attr.generic))
  	return st;
      }
  
--- 3163,3176 ----
  	     && strcmp (module, st->n.sym->module) == 0
  	     && !check_unique_name (st->name))
      {
!       s = gfc_find_symtree (gfc_current_ns->sym_root, name);
! 
!       /* Detect symbols that are renamed by use association in another
! 	 module by the absence of a symtree and null attr.use_rename,
! 	 since the latter is not transmitted in the module file.  */
!       if (((!generic && !st->n.sym->attr.generic)
! 		|| (generic && st->n.sym->attr.generic))
! 	    && !(s == NULL && !st->n.sym->attr.use_rename))
  	return st;
      }
  
Index: gcc/testsuite/gfortran.dg/use_rename_3.f90
===================================================================
*** gcc/testsuite/gfortran.dg/use_rename_3.f90	(revision 0)
--- gcc/testsuite/gfortran.dg/use_rename_3.f90	(revision 0)
***************
*** 0 ****
--- 1,35 ----
+ ! { dg-do compile }
+ ! Tests the fix for PR35997, in which the use association of renamed
+ ! valid2 and flag2 was treated as if the renaming were done on use
+ ! association in the main program.  Thus, the following, direct use
+ ! association of valid and flag did not occur.
+ !
+ ! Contributed by Drew McCormack <drewmccormack@mac.com>
+ !
+ module funcinterfacemod
+   interface
+     logical function valid ()
+     end function
+   end interface
+   logical :: flag = .true.
+ end module
+ 
+ module secondmod
+   use funcinterfacemod, valid2 => valid, flag2 => flag
+ end module
+ 
+ logical function valid ()
+   valid = .true.
+ end function
+ 
+ program main
+   use secondmod
+   use funcinterfacemod
+   if (valid ()) then
+     print *, 'Is Valid'
+   endif
+   if (flag) then
+     print *, 'Is flag'
+   endif
+ end program
+ ! { dg-final { cleanup-modules "funcinterfacemod secondmod" } }