From patchwork Tue Aug 17 02:21:55 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerry DeLisle X-Patchwork-Id: 61848 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id CC04FB70CD for ; Tue, 17 Aug 2010 12:22:21 +1000 (EST) Received: (qmail 11024 invoked by alias); 17 Aug 2010 02:22:17 -0000 Received: (qmail 11002 invoked by uid 22791); 17 Aug 2010 02:22:16 -0000 X-SWARE-Spam-Status: No, hits=4.0 required=5.0 tests=AWL, BAYES_40, BOTNET, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from vms173013pub.verizon.net (HELO vms173013pub.verizon.net) (206.46.173.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Aug 2010 02:22:11 +0000 Received: from [192.168.1.10] ([unknown] [64.234.92.14]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L79000BNYKJZQS6@vms173013.mailsrvcs.net>; Mon, 16 Aug 2010 21:21:57 -0500 (CDT) Message-id: <4C69F243.4090001@verizon.net> Date: Mon, 16 Aug 2010 19:21:55 -0700 From: Jerry DeLisle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-version: 1.0 To: gfortran Cc: gcc patches Subject: [patch, fortran] PR41859 ICE on invalid expression involving DT with pointer components in I/O Content-type: multipart/mixed; boundary=------------080805030104090608000609 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list 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 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;