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
