From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24663 invoked by alias); 12 Apr 2011 12:42:23 -0000 Received: (qmail 24647 invoked by uid 22791); 12 Apr 2011 12:42:22 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ppsw-41.csi.cam.ac.uk (HELO ppsw-41.csi.cam.ac.uk) (131.111.8.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 12:42:17 +0000 Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43728) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1Q9cvA-0007ul-Q6 (Exim 4.72) (return-path ); Tue, 12 Apr 2011 13:42:16 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1Q9cvA-0001G4-1p (Exim 4.67) (return-path ); Tue, 12 Apr 2011 13:42:16 +0100 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 12 Apr 2011 13:42:16 +0100 Date: Tue, 12 Apr 2011 12:42:00 -0000 From: "N.M. Maclaren" To: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: Implement stack arrays even for unknown sizes Message-ID: In-Reply-To: References: <20110409100809.BF9CD3BE18@mailhost.lps.ens.fr> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 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/msg00865.txt.bz2 On Apr 12 2011, Michael Matz wrote: >On Mon, 11 Apr 2011, Steven Bosscher wrote: > >> Isn't there a way to put a maximum on the size of the arrays on stack, >> e.g. -fstack-arrays-limit= or something like that? > >Not without generating contorded code. The problem is that these arrays >are variable length, hence runtime tests would be required, branching to >malloc or stack_save/alloca, and also for the deallocation side, requiring >a flag for branching to free or stack_restore. And as we use the variable >length facilities this is actually not controllable in such a way, the >frontend doesn't generate alloca calls at all. It would almost certainly be cleaner and simpler to use a secondary stack than to have such dynamic testing. It is very similar (conceptually) to the dynamic code that switches between inline and library code for sizes of DO-loop or array on some specialist HPC compilers. And that gets very messy, very fast. Regards, Nick Maclaren.