From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26542 invoked by alias); 11 Apr 2011 18:28:07 -0000 Received: (qmail 26529 invoked by uid 22791); 11 Apr 2011 18:28:06 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx02.qsc.de (HELO mx02.qsc.de) (213.148.130.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Apr 2011 18:27:59 +0000 Received: from [192.168.178.22] (port-92-204-29-161.dynamic.qsc.de [92.204.29.161]) by mx02.qsc.de (Postfix) with ESMTP id 8FF701DDF8; Mon, 11 Apr 2011 20:27:55 +0200 (CEST) Message-ID: <4DA34829.1020206@net-b.de> Date: Mon, 11 Apr 2011 18:28:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7 MIME-Version: 1.0 Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran To: Michael Matz CC: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Implement stack arrays even for unknown sizes References: <20110409100809.BF9CD3BE18@mailhost.lps.ens.fr> In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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: 2011-04/txt/msg00785.txt.bz2 On 04/11/2011 06:04 PM, Michael Matz wrote: > =================================================================== > *** trans-array.c (revision 172206) > --- trans-array.c (working copy) > *************** gfc_trans_auto_array_allocation (tree de [...] > ! gfc_add_init_cleanup (block, inittree, tmp); > } I get the fatal warning: .../gcc/fortran/trans-array.c: In function ‘gfc_trans_auto_array_allocation’: ..../gcc/fortran/trans-array.c:4881:24: error: ‘tmp’ may be used uninitialized in this function [-Werror=uninitialized] which is the line quoted above. * * * Regarding the goal of the patch: I like the idea and I think it is rather useful. It is unfortunate that running out of stack space causes segfaults, which is not very user friendly, but I think HPC users - and in particular Intel compiler users - are used to have "ulimit -s unlimited" (or some large value), which also HPC admins set. For instance, on the login node of our HPC cluster (2*quadcore/node; 24 GB RAM/node, 2200 nodes) one has 3 GB stack space by default (soft and hard limit) - I think the value on the compute nodes is the same. Tobias