From patchwork Tue Aug 17 15:00:54 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Janus Weil X-Patchwork-Id: 61922 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 E5F69B70DC for ; Wed, 18 Aug 2010 01:01:16 +1000 (EST) Received: (qmail 27000 invoked by alias); 17 Aug 2010 15:01:12 -0000 Received: (qmail 26898 invoked by uid 22791); 17 Aug 2010 15:01:10 -0000 X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Aug 2010 15:01:05 +0000 Received: by bwz12 with SMTP id 12so3114869bwz.20 for ; Tue, 17 Aug 2010 08:01:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.119.134 with SMTP id z6mr4433930bkq.193.1282057254608; Tue, 17 Aug 2010 08:00:54 -0700 (PDT) Received: by 10.204.143.154 with HTTP; Tue, 17 Aug 2010 08:00:54 -0700 (PDT) In-Reply-To: <4C6A3E58.40102@net-b.de> References: <4C6A3E58.40102@net-b.de> Date: Tue, 17 Aug 2010 17:00:54 +0200 Message-ID: Subject: Re: [Patch, Fortran, F08] PR45290: pointer initialization From: Janus Weil To: Tobias Burnus Cc: gfortran , gcc-patches 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 Tobias, thanks for your feedback. >> I hope everything should work as advertised. Regtesting was successful >> on x86_64-unknown-linux-gnu (except for the continuing failure of >> array_memcpy_3.f90, cf. PR45266). >> Ok for trunk? > > For pointer initialization there is a case where the changed SAVE behaviour > in Fortran 2008 matters. So far I had the impression that there is no such > case, but seemingly we have now one. (Actually, that's not quite true: it > also occurs for coarrays where I seem to handle it explicitly.) > > "A variable, common block, or procedure pointer declared in the scoping unit > of a main program, module, or submodule implicitly has the SAVE attribute, > which may be con rmed by explicit speci cation" (Fortran 2008, 5.3.16 SAVE > attribute) > > Thus, I believe the following program is valid and should not be rejected. > We have now two possibilities: (a) setting SAVE_IMPLICIT or (b) adding > explicit check for pointer initialization. > > > module m >  integer, target  :: t1 >  integer, pointer :: p1 => t1 ! valid, "t1" is implicitly SAVE > end module m Ok, I have picked your option (a) and set SAVE_IMPLICIT in decl.c (match_attr_spec). I also had to modify gfc_add_save to handle SAVE_IMPLICIT (important e.g. when copying attributes). > The following program ICEs (segfault) via >    by 0x573B54: gfc_create_module_variable (trans-decl.c:3597) > in >    at 0x57E731: gfc_conv_variable (trans-expr.c:593) > > > module m >  integer, target, save  :: t1 >  integer, pointer :: p1 => t1 > end module m > > program main >  use m > end program main Oops. To get rid of this I had to add the following hunk in trans-expr.c: @@ -590,7 +590,8 @@ gfc_conv_variable (gfc_se * se, gfc_expr * expr) entry_master = sym->attr.result && sym->ns->proc_name->attr.entry_master && !gfc_return_by_reference (sym->ns->proc_name); - parent_decl = DECL_CONTEXT (current_function_decl); + if (current_function_decl) + parent_decl = DECL_CONTEXT (current_function_decl); if ((se->expr == parent_decl && return_value) || (sym->ns && sym->ns->proc_name and then then another one: > And the following is invalid and gives an ICE: > > module m >  integer, target, save  :: t1 >  integer, pointer :: p1 => t1 >  integer, pointer, save :: p2 => p2 ! invalid & ICE >  integer, pointer :: p3 => p1 ! ICE & invalid as "p1" is not a TARGET > end module m About this one I'm still not sure. F08 explicitly says: C556 An entity with the TARGET attribute shall not have the POINTER attribute. But still gfc_variable_attr seems to set the TARGET attribute for things that actually are POINTERS. Can someone explain this? New patch attached. Cheers, Janus Index: gcc/fortran/trans-decl.c =================================================================== --- gcc/fortran/trans-decl.c (revision 163296) +++ gcc/fortran/trans-decl.c (working copy) @@ -3587,7 +3587,7 @@ gfc_create_module_variable (gfc_symbol * sym) && (sym->equiv_built || sym->attr.in_equivalence)) return; - if (sym->backend_decl && !sym->attr.vtab) + if (sym->backend_decl && !sym->attr.vtab && !sym->attr.target) internal_error ("backend decl for module variable %s already exists", sym->name);