From patchwork Tue Mar 24 22:39:00 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mikael Morin X-Patchwork-Id: 454088 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 9C3531400DD for ; Wed, 25 Mar 2015 09:39:25 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass reason="1024-bit key; unprotected key" header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=BWKowKz5; dkim-adsp=none (unprotected policy); 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 :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=md47IsmW1M5ewdFRx6Fp2Qa9ChqoQ3s3fsh7Rd3eI4NB0Y 16XMKKCyOuq6vwgk3X2BL5QfO70O7j37mzX/lSpOa8KMPHe5My1FSCqcKQOf8XwI b4uVslY5+xzHU2Iku1YCPLjql418a1/VIF47zp/BieeBRtkifJDqcWqUYzqcQ= 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 :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=2I9Ta97GaunWZX1LigWGO2JNzLs=; b=BWKowKz5djbhn/hNcI3a TjTM/zWD+RUETTAq/szJ4ZhUnk/JRk1b4yV7Qgy2amoJQzVPcZEJh6gOY2WAeh6P YAt7IJ4RnRM3IYNwrEWFFiZo6dOc6Iq7UvvDq4hgtot9lE8K1tOggwiPmA8rIZOO 2cCI9MYzNHq1nTxmog8sfJg= Received: (qmail 103441 invoked by alias); 24 Mar 2015 22:39:17 -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 103414 invoked by uid 89); 24 Mar 2015 22:39:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp22.services.sfr.fr Received: from smtp22.services.sfr.fr (HELO smtp22.services.sfr.fr) (93.17.128.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 24 Mar 2015 22:39:15 +0000 Received: from filter.sfr.fr (localhost [86.72.15.254]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id CD86A7000350; Tue, 24 Mar 2015 23:39:11 +0100 (CET) Authentication-Results: sfrmc.priv.atos.fr; dkim=none (no signature); dkim-adsp=none (no policy) header.from=mikael.morin@sfr.fr Received: from tolstoi.localhost (254.15.72.86.rev.sfr.net [86.72.15.254]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 7C9D0700034B; Tue, 24 Mar 2015 23:39:11 +0100 (CET) X-SFR-UUID: 20150324223911510.7C9D0700034B@msfrf2212.sfr.fr Message-ID: <5511E784.2010501@sfr.fr> Date: Tue, 24 Mar 2015 23:39:00 +0100 From: Mikael Morin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: gfortran , gcc-patches Subject: [Patch, fortran] PR65532 shape mismatch error with data partial initialization X-IsSubscribed: yes Hello, here is a fix for the regression I introduced with my PR64952 patch. The regression is a spurious shape mismatch error message coming from a variable partial initialization through data statements. Before the patch at the time of the shape check, the initialization is still unset as processing of data statements comes after that point, so that no error message is issued. The PR64952 introduce an extra call to gfc_resolve, which may make resolve_types be called more than once. And the second times it is, the data statements have been processed and error messages are issued. The patch I propose here adds a flag to remember the function has been called, and skip it the second time. I considered reusing the existing 'resolved' field, but I had to slightly change its semantics to prevent regressing somewhere, and I was not completely sure how safe that change was. I have finally preferred this safer patch keeping the existing field completely untouched. Regression tested on x86_64-unknown-linux-gnu. OK for trunk? Mikael 2015-03-24 Mikael Morin PR fortran/64952 PR fortran/65532 * gfortran.h (struct gfc_namespace): New field 'types_resolved'. * resolve.c (resolve_types): Return early if field 'types_resolved' is set. Set 'types_resolved' at the end. 2015-03-24 Mikael Morin PR fortran/64952 PR fortran/65532 * gfortran.dg/data_initialized_3.f90: New. Index: gfortran.h =================================================================== --- gfortran.h (révision 221586) +++ gfortran.h (copie de travail) @@ -1691,6 +1691,9 @@ typedef struct gfc_namespace Holds -1 during resolution. */ signed resolved:2; + /* Set when resolve_types has been called for this namespace. */ + unsigned types_resolved:1; + /* Set to 1 if code has been generated for this namespace. */ unsigned translated:1; Index: resolve.c =================================================================== --- resolve.c (révision 221586) +++ resolve.c (copie de travail) @@ -14942,6 +14942,9 @@ resolve_types (gfc_namespace *ns) gfc_equiv *eq; gfc_namespace* old_ns = gfc_current_ns; + if (ns->types_resolved) + return; + /* Check that all IMPLICIT types are ok. */ if (!ns->seen_implicit_none) { @@ -15016,6 +15019,8 @@ resolve_types (gfc_namespace *ns) gfc_resolve_omp_udrs (ns->omp_udr_root); + ns->types_resolved = 1; + gfc_current_ns = old_ns; }