From patchwork Tue Aug 17 02:21:55 2010
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [fortran] PR41859 ICE on invalid expression involving DT with pointer
 components in I/O
Date: Mon, 16 Aug 2010 16:21:55 -0000
From: Jerry DeLisle <jvdelisle@verizon.net>
X-Patchwork-Id: 61848
Message-Id: <4C69F243.4090001@verizon.net>
To: gfortran <fortran@gcc.gnu.org>
Cc: gcc patches <gcc-patches@gcc.gnu.org>

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;