From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11254 invoked by alias); 6 Jan 2013 14:40:15 -0000 Received: (qmail 11234 invoked by uid 22791); 6 Jan 2013 14:40:14 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 06 Jan 2013 14:40:07 +0000 Received: from archimedes.net-b.de (port-92-195-50-179.dynamic.qsc.de [92.195.50.179]) by mx01.qsc.de (Postfix) with ESMTP id 22BDD3CA53; Sun, 6 Jan 2013 15:40:05 +0100 (CET) Message-ID: <50E98CC5.90209@net-b.de> Date: Sun, 06 Jan 2013 14:40:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: gcc patches , gfortran Subject: Re: [Patch, Fortran] PR55763 - improve init-data checks for pointers References: <50E6D03A.3020001@net-b.de> In-Reply-To: <50E6D03A.3020001@net-b.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg00250.txt.bz2 Early * ping* http://gcc.gnu.org/ml/fortran/2013-01/msg00025.html On January 4, 2013, Tobias Burnus wrote: > Fortran 2008 allows: > integer :: pointer => init_data > and > type t > integer :: pointer => init_data > end type t > > The current check in gfc_check_assign_symbol was only called for > former and for constructors, but not for the type definition. > Additionally, BT_CLASS wasn't handled. I also improved the error > location. > > > > The patch has a downside: One gets some messages twice or trice: Once > for resolving the type declaration ("type t") and then for resolving > the default initialization via > gfc_traverse_ns (ns, resolve_values); > > Currently, that's unavoidable as one cannot trivially distinguish > between a user-supplied "sym->value" and the default constructor. If > you think that this is a problem, one can change it, e.g. by setting a > sym->attr.value_is_default_init. > > > Build and regtested on x86-64-gnu-linux. > OK for the trunk? > > Tobias > > PS: For CLASS pointers, there will be an ICE if one tries to associate > a variable to them; that's unchanged by this patch.