From patchwork Fri Aug 19 15:45:35 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 660907 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 3sG6kP4m5Vz9sxN for ; Sat, 20 Aug 2016 01:45:49 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=xIlmfMCx; dkim-atps=neutral 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:subject:message-id:reply-to:mime-version:content-type; q=dns; s=default; b=HHvpNUp2eNOrZ5RLeXIEAqrGscGK/I3wrnupKduRQ2k B5HW3SH2hl2aNp+FEcdB+WObDwOfgJOhMBvDAjgIpWmh26d/ngfH20B8lmjkfsFB k3Jv7x8BLxBgIt6KoTnnHfJFEqAM9k5LgyTBqTLZHNAWSp+YI+LbPSmcJkkClFZQ = 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:subject:message-id:reply-to:mime-version:content-type; s=default; bh=MPg10Ip16okR73rRnfP5V6K/5Pc=; b=xIlmfMCx9nO6NerzY g66d16YrGO8cKKnM+MFAk4LZCW6rgmNwwA6i98PSHZoa/ZCDRkWlX9oD0adRkw9j aWcV0Jos5ePqsj9pt6PGVt/hXmAy2kcpN4ZDQkLDTkzPr0iI+0KDymLiNo1xKflV U+yDIpzAvoiJa6WdhEGoJocyLw= Received: (qmail 60993 invoked by alias); 19 Aug 2016 15:45:41 -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 60976 invoked by uid 89); 19 Aug 2016 15:45:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=ns, 4.5, backports, sk:gfc_omp 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 ESMTP; Fri, 19 Aug 2016 15:45:40 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1960513AA1; Fri, 19 Aug 2016 15:45:39 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-43.brq.redhat.com [10.40.204.43]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7JFjbcK018927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Aug 2016 11:45:38 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u7JFjZa5030146; Fri, 19 Aug 2016 17:45:36 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u7JFjZkr030145; Fri, 19 Aug 2016 17:45:35 +0200 Date: Fri, 19 Aug 2016 17:45:35 +0200 From: Jakub Jelinek To: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: [committed] Fix handling of ASSOCIATE in OpenMP resolving (PR fortran/71014) Message-ID: <20160819154535.GX14857@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes Hi! The saving+clearing and restoring of OpenMP state during gfc_resolve is meant for when during resolving of one subroutine/function etc. we resolve another one, but apparently ASSOCIATE blocks (and BLOCK, though that isn't supported yet - OpenMP 4.5 only supports Fortran 2003, not 2008) add another namespace and we definitely want to e.g. notice vars used as DO loop iterators even inside of ASSOCIATE. Fixed thusly, tested on x86_64-linux and i686-linux, committed to trunk, backports queued. 2016-08-19 Jakub Jelinek PR fortran/71014 * resolve.c (gfc_resolve): For ns->construct_entities don't save, clear and restore omp state around the resolving. * testsuite/libgomp.fortran/pr71014.f90: New test. Jakub --- gcc/fortran/resolve.c.jj 2016-08-16 09:01:20.000000000 +0200 +++ gcc/fortran/resolve.c 2016-08-19 15:57:13.173596549 +0200 @@ -15587,7 +15587,8 @@ gfc_resolve (gfc_namespace *ns) /* As gfc_resolve can be called during resolution of an OpenMP construct body, we should clear any state associated to it, so that say NS's DO loops are not interpreted as OpenMP loops. */ - gfc_omp_save_and_clear_state (&old_omp_state); + if (!ns->construct_entities) + gfc_omp_save_and_clear_state (&old_omp_state); resolve_types (ns); component_assignment_level = 0; @@ -15599,5 +15600,6 @@ gfc_resolve (gfc_namespace *ns) gfc_run_passes (ns); - gfc_omp_restore_state (&old_omp_state); + if (!ns->construct_entities) + gfc_omp_restore_state (&old_omp_state); } --- libgomp/testsuite/libgomp.fortran/pr71014.f90.jj 2016-08-19 16:12:40.272914118 +0200 +++ libgomp/testsuite/libgomp.fortran/pr71014.f90 2016-08-19 16:10:33.000000000 +0200 @@ -0,0 +1,20 @@ +! PR fortran/71014 +! { dg-do run } +! { dg-additional-options "-O0" } + +program pr71014 + implicit none + integer :: i, j + integer, parameter :: t = 100*101/2 + integer :: s(16) + s(:) = 0 +!$omp parallel do + do j = 1, 16 + associate (k => j) + do i = 1, 100 + s(j) = s(j) + i + end do + end associate + end do + if (any(s /= t)) call abort +end program pr71014