This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch, fortran] PR 32535 - namelist with private items contained in sub-sub-procedure of a module rejected
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Janus Weil <jaydub66 at googlemail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org, Tobias Burnus <burnus at net-b dot de>
- Date: Sat, 7 Jul 2007 13:43:53 -0700
- Subject: Re: [patch, fortran] PR 32535 - namelist with private items contained in sub-sub-procedure of a module rejected
- References: <854832d40707071309hd8f3044gbb7f7e202dd1db0@mail.gmail.com>
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