X-pop3-spooler: POP3MAIL 2.1.0 b 3 961213 -bs-
Delivered-To: pcg AT goof DOT com
To: Jochen Heyd <jheyd AT tech DOT chem DOT ethz DOT ch>
Cc: "Hannes Lvffler" <Hannes DOT Loeffler AT uibk DOT ac DOT at>, beastium-list AT Desk DOT nl
Subject: Re: Problem with unusual array dimensions in Fortran
References: <351882E0 DOT F9A9F5AD AT tech DOT chem DOT ethz DOT ch> <yh6iup3maen DOT fsf AT tci005 DOT uibk DOT ac DOT at> <3518EC5D DOT 5073D402 AT tech DOT chem DOT ethz DOT ch>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
From: Hannes DOT Loeffler AT uibk DOT ac DOT at (Hannes =?ISO-8859-1?Q?L=F6ffler?=)
Date: 25 Mar 1998 11:56:26 +0100
In-Reply-To: Jochen Heyd's message of "Wed, 25 Mar 1998 12:37:01 +0100"
Message-ID: <yh6emzrm42t.fsf@tci005.uibk.ac.at>
X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald"
Sender: Marc Lehmann <pcg AT goof DOT com>
Status: RO
Content-Length: 1215
Lines: 47

Jochen Heyd <jheyd AT tech DOT chem DOT ethz DOT ch> writes:

> Hannes L=F6ffler wrote:
> > =

> > Jochen Heyd <jheyd AT tech DOT chem DOT ethz DOT ch> writes:
> > =

> > > GNU Fortran Front End version 0.5.22-19970929
> > > test.f: In subroutine `sub':
> > > test.f:12:
> > >          subroutine sub(b)
> > >                         ^
> > > Array `b' at (^) is too large to handle
> > =

> > GAUSSIAN?
> =

> Yes, the one I'm trying to compile now is Gaussian94.
> A 40% speed improvement would be measured in DAYS, so it's worth all th=
e
> trouble...
>  =

> > This is a long standing bug in g77.

To be more precise: a long standing bug since the egcs version of g77.


> I think I remember g77 having problems with large arrays (still in
> 0.4.x), but I haven't seen any lately and huge amouts of swap space wer=
e
> usually able to cure it.

This is still a problem (should be fixed in 0.6, whenever it will be
released). But I think it is not related to the negative bounds array bug=
=2E


> If it wouldn't work with the standard g77, I would have left it at that=
=2E

Yes it works with 0.5.21, which is somewhat faster than 0.5.19.1.
I didn't try the recently annonced 0.5.22 (for gcc 2.7.3.2) but I think i=
t
still has the same bug.