Message ID | 4C69F243.4090001@verizon.net |
---|---|
State | New |
Headers | show |
Ping! On 08/16/2010 07:21 PM, Jerry DeLisle wrote: > Hi, > > This patch is fairly simple. The ICE occurred because in resolve.c > (resolve_transfer) the checking for invalid was being skipped. When the > io_element is enclosed in parenthesis, the resulting expression > presented to resolve_transfer is expr_type == EXPR_OP. Existing code > just treated this as a case of neither a variable or function. > > The patch traverses down the operands until a non EXPR_OP type > expression or NULL is found. It is necessary to traverse this way > because one can have multiple levels of parenthesis. Attempting to > simplify the expression did not work. (I suspect because we try to > preserve parens for use in translation, not sure) > > Regression tested on i686-linux-gnu. > > OK for trunk? > > Regards, > > Jerry > > 2010-08-16 Jerry DeLisle <jvdelisle@gcc.gnu.org> > > PR fortran/41859 > * resolve.c (resolve_transfer): Traverse operands and set expression > to be checked to a non EXPR_OP type.
Index: resolve.c =================================================================== --- resolve.c (revision 163259) +++ resolve.c (working copy) @@ -7696,7 +7696,11 @@ resolve_transfer (gfc_code *code) exp = code->expr1; - if (exp->expr_type != EXPR_VARIABLE && exp->expr_type != EXPR_FUNCTION) + while (exp != NULL && exp->expr_type == EXPR_OP) + exp = exp->value.op.op1; + + if (exp == NULL || (exp->expr_type != EXPR_VARIABLE + && exp->expr_type != EXPR_FUNCTION)) return; sym = exp->symtree->n.sym;