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]

Re: [patch, Fortran] Fix PR 55593


Am 08.12.2012 17:39, schrieb Janus Weil:
Hi Thomas,

the attached patch fixes a regression introduced with the recent
checking for DO loop variables when they are used with a generic
subroutine where the generic name matches one of the actual names.

Regression-tested. OK for trunk?

A few questions about that patch:


- f = co->symtree->n.sym->formal;

+      if (co->resolved_sym == NULL)
+    break;
+
+      f = co->resolved_sym->formal;


In which cases does it happen that "resolved_sym==NULL" ?

This happens for (now part of the test case, because I got an ICE out of it during testing)

  do undeclared=1,10        ! { dg-error "has no IMPLICIT type" }
     call sub(undeclared)
  end do

Because undeclared is not declared, the resolution doesn't happen,
and resolved_sym is NULL.  This is OK because an error has been
raised about this anyway; one more error would not do much good.


Would it
make sense to do the following instead?

if (co->resolved_sym)
   f = co->resolved_sym->formal;
else
   f = co->symtree->n.sym->formal;

For some reason, co->symtree->n.sym->formal contains bogus information under the conditions of the test case. The intent for the dummy argument in co->symtree->n.sym->formal is set to INOUT. So, I'd rather not fall back to this.

Thomas


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