From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18249 invoked by alias); 29 Aug 2007 00:05:43 -0000 Received: (qmail 18053 invoked by uid 22791); 29 Aug 2007 00:05:41 -0000 X-Spam-Check-By: sourceware.org Received: from el-out-1112.google.com (HELO el-out-1112.google.com) (209.85.162.181) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Aug 2007 00:05:37 +0000 Received: by el-out-1112.google.com with SMTP id n30so9069elf for ; Tue, 28 Aug 2007 17:05:35 -0700 (PDT) Received: by 10.114.199.1 with SMTP id w1mr12576waf.1188345934399; Tue, 28 Aug 2007 17:05:34 -0700 (PDT) Received: by 10.114.195.16 with HTTP; Tue, 28 Aug 2007 17:05:34 -0700 (PDT) Message-ID: <1953a4560708281705ua0d5720ge733b326ec5502f3@mail.gmail.com> Date: Wed, 29 Aug 2007 02:02:00 -0000 From: "Asher Langton" To: "Tobias Burnus" Subject: Re: [PATCH, fortran] PR20441 -finit-local-zero Cc: "fortran@gcc.gnu.org" , gcc-patches In-Reply-To: <46C9C1C0.6070107@net-b.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1953a4560708171312u705f5bf4ie9d8ce645d2f02b6@mail.gmail.com> <46C9C1C0.6070107@net-b.de> X-Google-Sender-Auth: 498da33e0c84b02c 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: 2007-08/txt/msg02024.txt.bz2 On 8/20/07, Tobias Burnus wrote: > Hi Asher, > > Asher Langton wrote: > > Here's a patch to add -finit-local-zero, > Shouldn't also the derived variables be initialized? > > type bar > real :: r > complex :: z > integer :: i > character(len=5) :: c > logical :: l > end type bar > type(bar) :: t > > print *, t%r; print *, t%z; print *, t%i; > print *, t%c; print *, t%l > end > > With ifort and sunf95 they are set to zero; with "openf95 -zerouv" they > are zero. NAG f95 gives partially zeros (?) but -nan works. > > I therefore think that -finit* also should initialize those. Replacing > "integer :: i" by "integer :: i = 5" changes the behaviour of gfortran > (independent of the -finit* options): Not only "i" is initalized but all > other variables are initialized to zero. Using -finit-real=nan I would > still expect NAN and not "0.0" ... Hi Tobias, I've thought about this quite a bit, and I haven't come up with a good solution. If some of the components have initializers, then I can add initializers to the gfc_constructor for the remaining components (in expr.c::gfc_default_initializer()). However, I couldn't find a straightforward way to avoid initializing derived types variables that appear in equivalence statements, so this fails in gfortran.dg/equiv_7.f90::derived_types(). Handling arbitrary derived types is tougher. For a scalar derived type, it would suffice to run through the components and generate some initialization statements, but initializing arrays of derived types is more difficult. It can probably done by abusing the gfc_constructor initializers and letting trans-expr.c::gfc_trans_assignment() handle the scalarization, but I haven't figured out a clean way to do this. For now, my inclination is to leave derived type initialization as a TODO and document the -finit-* limitations in the manual. If that's acceptable, I'll put together a fresh patch with the added documentation, as well as an -finit-character option. -Asher