This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: GCSE store motion

From: Tim Hollebeek <tim at hollebeek dot com>
To: Toon Moene <toon at moene dot indiv dot nluug dot nl>
Cc: Mark Mitchell <mark at codesourcery dot com>, "law at redhat dot com" <law at redhat dot com>, Roger Sayle <roger at eyesopen dot com>, Daniel Berlin <dberlin at dberlin dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
Date: Fri, 17 May 2002 17:31:09 -0400
Subject: Re: GCSE store motion
References: <3557.1021484283@porcupine.cygnus.com> <23630000.1021488625@gandalf.codesourcery.com> <3CE2BCB4.D6D36685@moene.indiv.nluug.nl>
Reply-to: tim at hollebeek dot com

> 
> No, but it'll help any and all Fortran programs that have to be compiled
> with -fno-automatic because they were developed on systems where local
> variables in subroutines kept their values from call to call.
> 
> Given the number of times my advice on comp.lang.fortran of compiling
> with -fno-automatic actually `stopped the bug', I'd think that's rather
> important ...

If it has it's own -f flag, perhaps that flag could default to true
for fortran (or fortran + -fno-automatic) and false elsewhere.  Though
it'd be nice to verify that it actually helps such programs first.

-Tim

References:
- Re: GCSE store motion
  - From: law
- Re: GCSE store motion
  - From: Mark Mitchell
- Re: GCSE store motion
  - From: Toon Moene

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]