From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18780 invoked by alias); 21 Aug 2007 15:49:21 -0000 Received: (qmail 18667 invoked by uid 22791); 21 Aug 2007 15:49:19 -0000 X-Spam-Check-By: sourceware.org Received: from mail.physik.uni-muenchen.de (HELO mail.physik.uni-muenchen.de) (192.54.42.129) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Aug 2007 15:49:11 +0000 Received: from localhost (unknown [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id B10E420011; Tue, 21 Aug 2007 17:49:08 +0200 (CEST) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (mail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10023) with LMTP id 3E-1SvwOuftN; Tue, 21 Aug 2007 17:49:08 +0200 (CEST) Received: from [10.158.66.100] (d086.lmu.vpn.lrz-muenchen.de [141.84.23.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 83B5B2000A; Tue, 21 Aug 2007 17:49:08 +0200 (CEST) Message-ID: <46CB0964.50304@physik.uni-muenchen.de> Date: Tue, 21 Aug 2007 15:58:00 -0000 From: =?ISO-8859-1?Q?Tobias_Schl=FCter?= User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Fran=E7ois-Xavier_Coudert?= Cc: Asher Langton , Tobias Burnus , "fortran@gcc.gnu.org" , gcc-patches Subject: Re: [PATCH, fortran] PR20441 -finit-local-zero References: <1953a4560708171312u705f5bf4ie9d8ce645d2f02b6@mail.gmail.com> <46C9C1C0.6070107@net-b.de> <1953a4560708201048u3f8b95f4o873ee4204da0edca@mail.gmail.com> <19c433eb0708210429g7e68a53anccffa19fcb8861c0@mail.gmail.com> In-Reply-To: <19c433eb0708210429g7e68a53anccffa19fcb8861c0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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/msg01374.txt.bz2 François-Xavier Coudert wrote: >>> PS: I wonder whether it makes sense to have -finit-character=c to >>> initially character variables with, e.g. "XXXXXXXXXXXXXXXXXXXX". >> It makes sense, but I left it out because I didn't know if anyone >> would find it useful. I can easily add an finit-character option, >> though. > > I'd find it useful. I think -finit-character=32 would fill with > spaces, and so on (ie, using a ASCII value as argument). I'm wondering if all these options are really useful enough to justify their existence. What additional benefit does this fine-grained control have over, say, one option that allows me to give a 32bit value that will be filled into any variable's space? This suggestions allows behavior for -finit-local-zero, and therefore fixes the backwards ocmpatibility issue. For debugging, I don't think there's a realistic case where this is not sufficient. I'm somewhat doubtful that the maintenance overhead is worth the general solution. We have already identified two cases previously not thought of in this thread. Another issue that has remained unadressed so far: what happens if I initialize a INTEGER*1 to 2**20? I'm sure I could think of more issues or potential headaches. Cheers, - Tobi