This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Patch, fortran] PR34813 and PR33295


: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
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" } }
+ 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]