[Patch, fortran] PR34813 and PR33295

[Patch, fortran] PR34813 and PR33295

[Paul Richard Thomas]

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

:ADDPATCH fortran:

These only come together because of a possible identification that
theye are the same bug.  This turns out not to be so but never mind:)

The first, PR33295 looked as if it was yet another foul-up in
trans-types.c but, in fact, is not.  What is happening is that this
derived type function is not correctly broadcasting the derived type
symbol because it is in the function namespace, rather than the module
namespace.  Resolving the derived type is sufficient to fix the
problem, since it puts the derived type symbol on the derived type
list for the namespace.  However, I decide that it is better to
promote the derived type to visibility in the same namespace as the
function to ensure that it is properly handled when the module is
read.  I cannot see any harm in this but the same result could be
achieved by modifying the module read.  The testcase is the
reporter's.

PR34813 is peculiar because I would have thought we would have
encountered this one by now!  Anyway, the patch makes it an error to
assign NULL to anything other than pointers or allocatable components
in a derived type constructor.  The testcase is the reporter's.

My Linux box is, at the present, screened by a teenage girls pajama
party.  It is not worth my life to get at it....  Thus the patch is
only regtested on Cygwin_NT.  I'll check it out in earnest once the
dust has settled.

I propose that this patch not only be applied to trunk but to 4.3 as well.  OK?

Cheers

Paul

2008-03-21  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34813
	* resolve.c (resolve_structure_cons): It is an error to assign
	NULL to anything other than a pointer or allocatable component.

	PR fortran/33295
	* resolve.c (resolve_symbol): If the symbol is a derived type,
	resolve the derived type.  If the symbol is a derived type
	function, ensure that the derived type is visible in the same
	namespace as the function.

2008-03-21  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34813
	* gfortran.dg/null_3.f90 : New test

	PR fortran/33295
	* gfortran.dg/module_function_type_1.f90 : New test

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

Index: gcc/fortran/resolve.c
===================================================================
*** gcc/fortran/resolve.c	(revision 133208)
--- gcc/fortran/resolve.c	(working copy)
*************** resolve_structure_cons (gfc_expr *expr)
*** 827,832 ****
--- 827,842 ----
  	    t = gfc_convert_type (cons->expr, &comp->ts, 1);
  	}
  
+       if (cons->expr->expr_type == EXPR_NULL
+ 	    && !(comp->pointer || comp->allocatable))
+ 	{
+ 	  t = FAILURE;
+ 	  gfc_error ("The NULL in the derived type constructor at %L is "
+ 		     "being applied to component '%s', which is neither "
+ 		     "a POINTER nor ALLOCATABLE", &cons->expr->where,
+ 		     comp->name);
+ 	}
+ 
        if (!comp->pointer || cons->expr->expr_type == EXPR_NULL)
  	continue;
  
*************** resolve_symbol (gfc_symbol *sym)
*** 7974,7979 ****
--- 7984,8008 ----
        return;
      }
  
+   /* Make sure that the derived type has been resolved and that the
+      derived type is visible in the symbol's namespace, if it is a
+      function.  */
+   if (sym->ts.type == BT_DERIVED)
+     {
+       gfc_symbol *ds;
+ 
+       if (resolve_fl_derived (sym->ts.derived) == FAILURE)
+ 	return;
+ 
+       gfc_find_symbol (sym->ts.derived->name, sym->ns, 1, &ds);
+       if (!ds && sym->attr.function)
+ 	{
+ 	  symtree = gfc_new_symtree (&sym->ns->sym_root,
+ 				     sym->ts.derived->name);
+ 	  symtree->n.sym = sym->ts.derived;
+ 	}
+     }
+ 
    /* Unless the derived-type declaration is use associated, Fortran 95
       does not allow public entries of private derived types.
       See 4.4.1 (F95) and 4.5.1.1 (F2003); and related interpretation
Index: gcc/testsuite/gfortran.dg/null_3.f90
===================================================================
*** gcc/testsuite/gfortran.dg/null_3.f90	(revision 0)
--- gcc/testsuite/gfortran.dg/null_3.f90	(revision 0)
***************
*** 0 ****
--- 1,18 ----
+ ! { dg-do compile }
+ ! This checks the fix for PR34813 in which the error at line 17
+ ! was not detected.
+ !
+ ! Contributed by Daniel Franke <dfranke@gcc.gnu.org>
+ !
+ SUBROUTINE kd_tree_init_default()
+   TYPE :: kd_tree_node
+     INTEGER :: dummy
+   END TYPE
+ 
+   TYPE :: kd_tree
+     TYPE(kd_tree_node) :: root
+   END TYPE
+ 
+   TYPE(kd_tree)  :: tree
+   tree = kd_tree(null()) ! { dg-error "neither a POINTER nor ALLOCATABLE" }
+ END SUBROUTINE
Index: gcc/testsuite/gfortran.dg/module_function_type_1.f90
===================================================================
*** gcc/testsuite/gfortran.dg/module_function_type_1.f90	(revision 0)
--- gcc/testsuite/gfortran.dg/module_function_type_1.f90	(revision 0)
***************
*** 0 ****
--- 1,33 ----
+ ! { dg-do compile }
+ ! This checks the fix for PR33295 in which the A_type in initA was
+ ! not promoted to module level and so not recognised as being the
+ ! same as that emanating directly from module a. 
+ !
+ ! Contributed by Janus Weil <jaydub66@gmail.com>
+ !
+ module A
+   type A_type
+     real comp
+   end type
+ end module A
+ 
+ module B
+ contains
+   function initA()
+     use A
+     implicit none
+     type(A_type):: initA
+     initA%comp=1.0
+   end function
+ end module B
+ 
+ program C
+   use B
+   use A
+   implicit none
+   type(A_type):: A_var
+   A_var = initA()
+ end program C
+ 
+ ! { dg-final { cleanup-modules "A B" } }
+ 

Re: [Patch, fortran] PR34813 and PR33295

[Paul Richard Thomas]

Dominique,

> The patch works as advertised for the PRs, however I have two failures
> of the kind:

> two_list.f90:26.22:

> end module REAL_LISTS
>                      1
> Internal Error at (1):
> free_sym_tree(): Negative refs

> Since the codes are fairly long, I add only one at the end.
> They come from pr30793. I did not regtested yet.

This failure comes about because the function 'get_scalar_field_msh'
is private.  Adding a check of the access clears the problem.  I'll go
through the logic before re-submitting.

Thanks for spotting this wrinkle.

Paul


Dominique

On Fri, Mar 21, 2008 at 9:51 PM, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> :ADDPATCH fortran:
>
>  These only come together because of a possible identification that
>  theye are the same bug.  This turns out not to be so but never mind:)
>
>  The first, PR33295 looked as if it was yet another foul-up in
>  trans-types.c but, in fact, is not.  What is happening is that this
>  derived type function is not correctly broadcasting the derived type
>  symbol because it is in the function namespace, rather than the module
>  namespace.  Resolving the derived type is sufficient to fix the
>  problem, since it puts the derived type symbol on the derived type
>  list for the namespace.  However, I decide that it is better to
>  promote the derived type to visibility in the same namespace as the
>  function to ensure that it is properly handled when the module is
>  read.  I cannot see any harm in this but the same result could be
>  achieved by modifying the module read.  The testcase is the
>  reporter's.
>
>  PR34813 is peculiar because I would have thought we would have
>  encountered this one by now!  Anyway, the patch makes it an error to
>  assign NULL to anything other than pointers or allocatable components
>  in a derived type constructor.  The testcase is the reporter's.
>
>  My Linux box is, at the present, screened by a teenage girls pajama
>  party.  It is not worth my life to get at it....  Thus the patch is
>  only regtested on Cygwin_NT.  I'll check it out in earnest once the
>  dust has settled.
>
>  I propose that this patch not only be applied to trunk but to 4.3 as well.  OK?
>
>  Cheers
>
>  Paul
>
>  2008-03-21  Paul Thomas  <pault@gcc.gnu.org>
>
>         PR fortran/34813
>         * resolve.c (resolve_structure_cons): It is an error to assign
>         NULL to anything other than a pointer or allocatable component.
>
>         PR fortran/33295
>         * resolve.c (resolve_symbol): If the symbol is a derived type,
>         resolve the derived type.  If the symbol is a derived type
>         function, ensure that the derived type is visible in the same
>         namespace as the function.
>
>  2008-03-21  Paul Thomas  <pault@gcc.gnu.org>
>
>         PR fortran/34813
>         * gfortran.dg/null_3.f90 : New test
>
>         PR fortran/33295
>         * gfortran.dg/module_function_type_1.f90 : New test
>



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

Re: [Patch, fortran] PR34813 and PR33295

[Paul Richard Thomas]

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

The attached cures the problem that Dominique found by being much more
restrictive on what gets a new symtree and looking after the reference
count.

Bootstraps and regtests on x86_ia64/FC8 - OK for trunk?

Paul

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

Index: gcc/fortran/resolve.c
===================================================================
*** gcc/fortran/resolve.c	(revision 133208)
--- gcc/fortran/resolve.c	(working copy)
*************** resolve_structure_cons (gfc_expr *expr)
*** 827,832 ****
--- 827,842 ----
  	    t = gfc_convert_type (cons->expr, &comp->ts, 1);
  	}
  
+       if (cons->expr->expr_type == EXPR_NULL
+ 	    && !(comp->pointer || comp->allocatable))
+ 	{
+ 	  t = FAILURE;
+ 	  gfc_error ("The NULL in the derived type constructor at %L is "
+ 		     "being applied to component '%s', which is neither "
+ 		     "a POINTER nor ALLOCATABLE", &cons->expr->where,
+ 		     comp->name);
+ 	}
+ 
        if (!comp->pointer || cons->expr->expr_type == EXPR_NULL)
  	continue;
  
*************** resolve_symbol (gfc_symbol *sym)
*** 7974,7979 ****
--- 7984,8012 ----
        return;
      }
  
+   /* Make sure that the derived type has been resolved and that the
+      derived type is visible in the symbol's namespace, if it is a
+      module function and is not PRIVATE.  */
+   if (sym->ts.type == BT_DERIVED
+ 	&& sym->ts.derived->attr.use_assoc
+ 	&& sym->ns->proc_name->attr.flavor == FL_MODULE)
+     {
+       gfc_symbol *ds;
+ 
+       if (resolve_fl_derived (sym->ts.derived) == FAILURE)
+ 	return;
+ 
+       gfc_find_symbol (sym->ts.derived->name, sym->ns, 1, &ds);
+       if (!ds && sym->attr.function
+ 	    && gfc_check_access (sym->attr.access, sym->ns->default_access))
+ 	{
+ 	  symtree = gfc_new_symtree (&sym->ns->sym_root,
+ 				     sym->ts.derived->name);
+ 	  symtree->n.sym = sym->ts.derived;
+ 	  sym->ts.derived->refs++;
+ 	}
+     }
+ 
    /* Unless the derived-type declaration is use associated, Fortran 95
       does not allow public entries of private derived types.
       See 4.4.1 (F95) and 4.5.1.1 (F2003); and related interpretation
Index: gcc/testsuite/gfortran.dg/null_3.f90
===================================================================
*** gcc/testsuite/gfortran.dg/null_3.f90	(revision 0)
--- gcc/testsuite/gfortran.dg/null_3.f90	(revision 0)
***************
*** 0 ****
--- 1,18 ----
+ ! { dg-do compile }
+ ! This checks the fix for PR34813 in which the error at line 17
+ ! was not detected.
+ !
+ ! Contributed by Daniel Franke <dfranke@gcc.gnu.org>
+ !
+ SUBROUTINE kd_tree_init_default()
+   TYPE :: kd_tree_node
+     INTEGER :: dummy
+   END TYPE
+ 
+   TYPE :: kd_tree
+     TYPE(kd_tree_node) :: root
+   END TYPE
+ 
+   TYPE(kd_tree)  :: tree
+   tree = kd_tree(null()) ! { dg-error "neither a POINTER nor ALLOCATABLE" }
+ END SUBROUTINE
Index: gcc/testsuite/gfortran.dg/module_function_type_1.f90
===================================================================
*** gcc/testsuite/gfortran.dg/module_function_type_1.f90	(revision 0)
--- gcc/testsuite/gfortran.dg/module_function_type_1.f90	(revision 0)
***************
*** 0 ****
--- 1,33 ----
+ ! { dg-do compile }
+ ! This checks the fix for PR33295 in which the A_type in initA was
+ ! not promoted to module level and so not recognised as being the
+ ! same as that emanating directly from module a. 
+ !
+ ! Contributed by Janus Weil <jaydub66@gmail.com>
+ !
+ module A
+   type A_type
+     real comp
+   end type
+ end module A
+ 
+ module B
+ contains
+   function initA()
+     use A
+     implicit none
+     type(A_type):: initA
+     initA%comp=1.0
+   end function
+ end module B
+ 
+ program C
+   use B
+   use A
+   implicit none
+   type(A_type):: A_var
+   A_var = initA()
+ end program C
+ 
+ ! { dg-final { cleanup-modules "A B" } }
+