From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9896 invoked by alias); 16 Aug 2007 09:07:42 -0000 Received: (qmail 9623 invoked by uid 22791); 16 Aug 2007 09:07:40 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Aug 2007 09:07:25 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l7G97NQ6001005; Thu, 16 Aug 2007 05:07:23 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l7G97NHU023600; Thu, 16 Aug 2007 05:07:23 -0400 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l7G97N1a000798; Thu, 16 Aug 2007 05:07:23 -0400 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11/Submit) id l7G97NHp000796; Thu, 16 Aug 2007 05:07:23 -0400 Date: Thu, 16 Aug 2007 09:07:00 -0000 From: Jakub Jelinek To: Tobias Burnus Cc: Janne Blomqvist , Asher Langton , fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH, fortran] Add -frecursive and fix local array handling with -fopenmp Message-ID: <20070816090722.GW2063@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <1953a4560708151258p44c9b855n2a0fc521879b3a25@mail.gmail.com> <7b446c2e0708151452o7bc6eebcyd995f42fbe8a8e6a@mail.gmail.com> <46C40FEC.6060101@net-b.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C40FEC.6060101@net-b.de> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes 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/msg00995.txt.bz2 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. Silently changing RLIMIT_STACK in libgfortran is IMHO not a good idea, for OpenMP programs that will not help, because at that point libpthread is already initialized and thread stacks will have different default size already anyway, and when Fortran programs spawn other programs it would cause bad havoc (e.g. recent make decided to do this silly thing and suddenly several programs started weirdly misbehaving when run from Makefile as opposed to when run without make - we had to change make to make sure stack limit is restored before execve). Jakub