From patchwork Mon Jun 23 10:39:53 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 362752 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 601221400AA for ; Mon, 23 Jun 2014 20:40:38 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=TU42qJTqHEFkAql/9 gR1akHaw1csOs4kF/wBmQLWJCxQqcA/zNZ3J2KSTpD+siZJKb7vj39u/9t1P+LJl C4x4KPwDlfwh3IpAaCvEHsG5g3XqWhg1J13qIkma0cTMW46guzdTczJTeA0tgyRQ bbEAmkA32zuuLyTJG5hl+XRAIk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=sGtRoMjU0T6C3M374KFdGYV l1OY=; b=SUuDSSjz6mBLKuyDtDIW8kvLYdwUzCJcXxaHTHs6k981VNXp9hhhVeB OZNhvHQI0d4QOQN0J2FpZ7zBMOdbjBKX4McF3VEWDV6TLiCLm6ko1OpyvvoZmV0O QsozI1Y3k6XZXmT3rB7GC9EctjBodFO+D6ERS0+TylKEWSOwxXyc= Received: (qmail 4050 invoked by alias); 23 Jun 2014 10:40:31 -0000 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 Received: (qmail 4029 invoked by uid 89); 23 Jun 2014 10:40:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 23 Jun 2014 10:40:00 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5NAdwla012661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jun 2014 06:39:59 -0400 Received: from tucnak.zalov.cz (ovpn-116-32.ams2.redhat.com [10.36.116.32]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5NAdufC013041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Jun 2014 06:39:58 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.8/8.14.7) with ESMTP id s5NAdsi0024809; Mon, 23 Jun 2014 12:39:55 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.8/8.14.8/Submit) id s5NAdrk1024808; Mon, 23 Jun 2014 12:39:53 +0200 Date: Mon, 23 Jun 2014 12:39:53 +0200 From: Jakub Jelinek To: Tobias Burnus Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Subject: Re: Fortran OpenMP UDR fixes, nested handling fixes etc. Message-ID: <20140623103953.GR31640@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20140620165016.GC31640@tucnak.redhat.com> <53A54239.2010605@net-b.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <53A54239.2010605@net-b.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes On Sat, Jun 21, 2014 at 10:28:41AM +0200, Tobias Burnus wrote: > Jakub Jelinek wrote: > >Bootstrap/regtest pending, does this look ok? > > Except for the module/resolved issues discussed elsewhere, it look good to > me. So, either we need something like the following patch (incremental), or another possibility for the problem is not do the value.function.name related change in module.c in the UDR patch, and instead fix up the UDR combiner/initializer expressions when they are loaded from module (change "" name to NULL only in the UDR combiner/initializer expressions, where they shouldn't be resolved yet). Or make sure value.function.name is set to non-NULL when resolving all intrinsic function calls, rather than just for a subset of them. With this patch it seems to pass bootstrap/regtest. 2014-06-21 Jakub Jelinek * resolve.c (resolve_function): If value.function.isym is non-NULL, consider it already resolved. * module.c (fix_mio_expr): Likewise. * trans-openmp.c (gfc_trans_omp_array_reduction_or_udr): Don't initialize value.function.isym. Jakub --- gcc/fortran/resolve.c.jj 2014-06-20 23:31:49.000000000 +0200 +++ gcc/fortran/resolve.c 2014-06-21 20:07:39.708099045 +0200 @@ -2887,7 +2887,8 @@ resolve_function (gfc_expr *expr) /* See if function is already resolved. */ - if (expr->value.function.name != NULL) + if (expr->value.function.name != NULL + || expr->value.function.isym != NULL) { if (expr->ts.type == BT_UNKNOWN) expr->ts = sym->ts; --- gcc/fortran/module.c.jj 2014-06-20 23:31:49.000000000 +0200 +++ gcc/fortran/module.c 2014-06-23 08:53:50.488662314 +0200 @@ -3173,7 +3173,8 @@ fix_mio_expr (gfc_expr *e) && !e->symtree->n.sym->attr.dummy) e->symtree = ns_st; } - else if (e->expr_type == EXPR_FUNCTION && e->value.function.name) + else if (e->expr_type == EXPR_FUNCTION + && (e->value.function.name || e->value.function.isym)) { gfc_symbol *sym; --- gcc/fortran/trans-openmp.c.jj 2014-06-20 23:31:49.000000000 +0200 +++ gcc/fortran/trans-openmp.c 2014-06-23 11:53:02.932495166 +0200 @@ -1417,7 +1417,6 @@ gfc_trans_omp_array_reduction_or_udr (tr e4->expr_type = EXPR_FUNCTION; e4->where = where; e4->symtree = symtree4; - e4->value.function.isym = gfc_find_function (iname); e4->value.function.actual = gfc_get_actual_arglist (); e4->value.function.actual->expr = e3; e4->value.function.actual->next = gfc_get_actual_arglist ();