From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2561 invoked by alias); 16 Aug 2007 18:34:22 -0000 Received: (qmail 2507 invoked by uid 22791); 16 Aug 2007 18:34:21 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0506.google.com (HELO nz-out-0506.google.com) (64.233.162.230) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Aug 2007 18:34:17 +0000 Received: by nz-out-0506.google.com with SMTP id s1so173650nze for ; Thu, 16 Aug 2007 11:34:15 -0700 (PDT) Received: by 10.114.79.1 with SMTP id c1mr1127039wab.1187289254277; Thu, 16 Aug 2007 11:34:14 -0700 (PDT) Received: by 10.114.195.16 with HTTP; Thu, 16 Aug 2007 11:34:14 -0700 (PDT) Message-ID: <1953a4560708161134v7d56a7ak343af9096a6ff48c@mail.gmail.com> Date: Thu, 16 Aug 2007 18:34:00 -0000 From: "Asher Langton" To: "Jakub Jelinek" Subject: Re: [PATCH, fortran] Add -frecursive and fix local array handling with -fopenmp Cc: "Tobias Burnus" , "Janne Blomqvist" , fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org In-Reply-To: <20070816090722.GW2063@devserv.devel.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1953a4560708151258p44c9b855n2a0fc521879b3a25@mail.gmail.com> <7b446c2e0708151452o7bc6eebcyd995f42fbe8a8e6a@mail.gmail.com> <46C40FEC.6060101@net-b.de> <20070816090722.GW2063@devserv.devel.redhat.com> X-Google-Sender-Auth: 0a84d5b6a3f35bdf 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/msg01045.txt.bz2 On 8/16/07, Jakub Jelinek wrote: > On Thu, Aug 16, 2007 at 10:50:52AM +0200, Tobias Burnus wrote: > > Note that you only see "weird things" if you have either parallel code > > (-fopenmp) which is fixed by Asher's patch or whether you are using > > recurse code without specifying RESCURSIVE, which is invalid Fortran. > > > > > > Regarding Asher's patch, I think it is OK as it. > > I don't like that, overriding explicit -fmax-stack-var-size=XXX by -fopenmp > sounds like a very bad idea to me. > -fopenmp certainly can change the default, when -fmax-stack-var-size=XXX > isn't explicitly used, from 32K to -1, but if the user requests particular > cutoff we should honor that. That's reasonable. The ifort compiler seems to do the same thing, but issues a warning: % ifort -save -openmp openmp_stack.f90 ifort: warning: explicit static allocation of locals specified, overriding OpenMP's implicit auto allocation When -recursive and -save are specified together, ifort seems to silently override the -save flag. -Asher