From patchwork Thu Jan 3 21:31:32 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mikael Morin X-Patchwork-Id: 209314 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 7B38E2C0085 for ; Fri, 4 Jan 2013 08:31:58 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1357853519; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=bBtFGwL Bbuzu6gh8nRaQOJ4aLTU=; b=fIPnWZrESe0ZQBAQesMdq05XHUOKOjYcSvd7YBp ANR4oNLfb16C1h+8xhPz9N0I2haQ6+zwRNl+h+NOBYRuMT4REenk/5i0QQL4O4JV qbXYeyaJQVef1azcj+D7CZ7dOG9vGwsxqgCtN7N60sZVd5GiUEKzW5thE8Ia2uBB rMuo= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:X-SFR-UUID:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=kVsidOL1rUx+dfWFcQuP9ynlrX5SZuVffoDYbMjrFsBvGEbhU70Tbsu+A7YjqR C8qVXzKmumWuCLvZtqFgUTOLAQpcM2ILBSSmAFdyDKC/Ao3sg6WJo1PL7F398qH8 RxLdIezDexZKWXdQ+3sBXEhIrDXK45vXC7oLJ0xfoAJAc=; Received: (qmail 12023 invoked by alias); 3 Jan 2013 21:31:51 -0000 Received: (qmail 12003 invoked by uid 22791); 3 Jan 2013 21:31:49 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, RCVD_IN_HOSTKARMA_NO, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp21.services.sfr.fr (HELO smtp21.services.sfr.fr) (93.17.128.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Jan 2013 21:31:40 +0000 Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id E62D87000067; Thu, 3 Jan 2013 22:31:38 +0100 (CET) Received: from [192.168.1.58] (147.15.72.86.rev.sfr.net [86.72.15.147]) by msfrf2114.sfr.fr (SMTP Server) with ESMTP id 8D0A77000061; Thu, 3 Jan 2013 22:31:38 +0100 (CET) X-SFR-UUID: 20130103213138577.8D0A77000061@msfrf2114.sfr.fr Message-ID: <50E5F8B4.6080507@sfr.fr> Date: Thu, 03 Jan 2013 22:31:32 +0100 From: Mikael Morin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121222 Thunderbird/10.0.11 MIME-Version: 1.0 To: gfortran , gcc-patches Subject: [Patch, fortran] PR55827 ICE with multiple fortran modules. X-IsSubscribed: yes 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 Hello, here is a fix for PR fortran/55827 where we had a function expression (loaded from a module) whose symtree pointer was NULL. My attempt to have symtree properly set got me way too far, so this is fixing the unconditional usages of symtree based on Steve's patch in the PR. As noted in the PR, it looks bogus to have a NULL expr->symtree, but in fact expr->value.function.esym is set, and it is what is solely looked at, apart for the cases fixed in this patch. The trans-expr.c part initializes `sym' earlier and uses it instead of accessing `expr->symtree' directly. The class.c part creates a similar construct to initialize `ts' without accessing `expr->symtree' directly. I don't use Steve's way (returning early for a NULL symtree), because I remembered that `expr->symtree' could be a generic symbol, thus have invalid type for use to initialize `ts', contrary to `expr->value.function.esym'. It's better to always use `esym' when it is available. And then returning early on NULL symtree is not necessary any more. Regression tested on x86_64-unknown-linux-gnu. OK for trunk? Do we want it on the branches as well? Mikael 2013-01-03 Steven G. Kargl Mikael Morin * class.c (gfc_fix_class_refs): Adapt ts initialization for the case e->symtree == NULL. * trans-expr.c (gfc_conv_function_expr): Init sym earlier. Use it. 2013-01-03 Steven G. Kargl Mikael Morin * gfortran.dg/use_10.f90: New test. diff --git a/class.c b/class.c index 8a8a54a..8b00a2c 100644 --- a/class.c +++ b/class.c @@ -166,7 +166,23 @@ gfc_fix_class_refs (gfc_expr *e) && e->value.function.isym != NULL)) return; - ts = &e->symtree->n.sym->ts; + if (e->expr_type == EXPR_VARIABLE) + ts = &e->symtree->n.sym->ts; + else + { + gfc_symbol *func; + + gcc_assert (e->expr_type == EXPR_FUNCTION); + if (e->value.function.esym != NULL) + func = e->value.function.esym; + else + func = e->symtree->n.sym; + + if (func->result != NULL) + ts = &func->result->ts; + else + ts = &func->ts; + } for (ref = &e->ref; *ref != NULL; ref = &(*ref)->next) { diff --git a/trans-expr.c b/trans-expr.c index 42f6e0c..d36b466 100644 --- a/trans-expr.c +++ b/trans-expr.c @@ -5420,20 +5420,20 @@ gfc_conv_function_expr (gfc_se * se, gfc_expr * expr) return; } + /* expr.value.function.esym is the resolved (specific) function symbol for + most functions. However this isn't set for dummy procedures. */ + sym = expr->value.function.esym; + if (!sym) + sym = expr->symtree->n.sym; + /* We distinguish statement functions from general functions to improve runtime performance. */ - if (expr->symtree->n.sym->attr.proc == PROC_ST_FUNCTION) + if (sym->attr.proc == PROC_ST_FUNCTION) { gfc_conv_statement_function (se, expr); return; } - /* expr.value.function.esym is the resolved (specific) function symbol for - most functions. However this isn't set for dummy procedures. */ - sym = expr->value.function.esym; - if (!sym) - sym = expr->symtree->n.sym; - gfc_conv_procedure_call (se, sym, expr->value.function.actual, expr, NULL); }