This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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]

Re: [patch, fortran] PR 32535 - namelist with private items contained in sub-sub-procedure of a module rejected


On Sat, Jul 07, 2007 at 10:09:36PM +0200, Janus Weil wrote:
> Hi all,
> here is a very simple fix for PR 32535, including testcase.
> See http://gcc.gnu.org/ml/fortran/2007-06/msg00488.html
> Would be nice if someone could have a look at it and commit it in case it's 
> ok.
> I ran "make check-gfortran" and only got the same regression that
> Christopher recently reported:
> FAIL: gfortran.fortran-torture/compile/pr32417.f90,  "-O"   (internal
> compiler error)
> So it seems like this problem was not introduced by my patch.
> Cheers,
> Janus

Hi janus,

A couple of items.  You need a ChangeLog entry that should posted
in the body of the email.  For this patch, it would be

2007-07-08  Janus Weil <your email address>

	PR fortran/32535
	* resolve.c (resolve_fl_namelist): Check for namelist private 
	components in contained subprograms.

2007-07-08  Janus Weil <your email address>

	PR fortran/32535
	* gfortran.dg/pr32535.f90: New test.


Can you add -p to your diff command?  It will include the
name of the function that you're modifying.

===================================================================
--- gcc/fortran/resolve.c	(revision 126442)
+++ gcc/fortran/resolve.c	(working copy)
@@ -6876,7 +6876,7 @@
       for (nl = sym->namelist; nl; nl = nl->next)
 	{
 	  if (!nl->sym->attr.use_assoc
-	      && !(sym->ns->parent == nl->sym->ns)
+	      && !(sym->ns->parent == nl->sym->ns) && !(sym->ns->parent!=0 && sym->ns->parent->parent == nl->sym->ns)
 	      && !gfc_check_access(nl->sym->attr.access,
 				   nl->sym->ns->default_access))
 	    {

Try to keep lines to less than 80 characters.  Pointers should be
compared to NULL, and in the above you can completely omit the '!=0'.
So the diff would look like

 	  if (!nl->sym->attr.use_assoc
	      && !(sym->ns->parent == nl->sym->ns)
+		  && !(sym->ns->parent && sym->ns->parent->parent == nl->sym->ns)
 	      && !gfc_check_access(nl->sym->attr.access,
 				   nl->sym->ns->default_access))

Finally, does this scale to arbitrarily deep contained subroutines?


-- 
Steve


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