Newsgroups: comp.sys.apollo
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: ftn 10.8.p serious problems / tirade (again)
Message-ID: <1991Apr3.230735.9578@alchemy.chem.utoronto.ca>
Summary: ftn 10.8 abandoned
Sender: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Organization: University of Toronto Chemistry Department
Date: Wed, 3 Apr 1991 23:07:35 GMT

We have found several serious problems in the recently released ftn
10.8.p (for DN10000's), especially when optimization is turned on.
The most serious one involves incorrect optimization of simple loops
with GOTO, IF and DO involved, which may in fact be an example of the
general bug described in the Release Notes (Section 4.1.3), if only I could
actually understand what that example means. The Notes say that this bug
affects only M680x0 systems, yet the problem programs actually work
properly on the m68k nodes, so this is probably something different.
Compiling with '-g' fixes this problem, but with slower running code,
provided you know that the program messed up in the first place.

We are also getting "backend failures" of the compiler itself on
simple routines that compiled with '-O' with the ftn 10.7/patch
compiler without problem (which has a lot of "backend failure"
problems itself, and also seems incapable of correctly compiling
most routines using complex variables/arrays).
Compiling with '-g' fixes these problems, but with slower running code.

Our ab initio chemistry program, derived from Gaussian 8x, also
produces incorrect (but close) results - I haven't had the nerve to
recompile G88 itself. The "incorrect but close" errors are the most
disturbing, since without an external check, you would believe the
calculation was correct, which could easily lead to publication of
incorrect results in the scientific literature, and resulting
embarrassment when the paper must be retracted (and believe me the cause
of the retraction would be made VERY CLEAR). In this case, compiling
with '-g' corrects some of the wrong results BUT NOT ALL, which is also
very disturbing.

Since the compiler can not produce useful, trustworthy code (or at least as
trustworthy as ftn 10.7/patch, which is not a terribly high watermark
itself unfortunately), we have abandoned the ftn 10.8 compilers and have
reverted to the 10.7/patch compiler, whose bugs (we think) we know.

As an aside, a couple of questions:

1) why was a compiler released with a bug like Section 4.1.3
of the Notes? The code will fail to work properly at execution time,
but may not screw up enough for the program to abort - bugs like
"backend failures" are much more benign since no code is produced
and the user gets a specific notice that something is wrong.

2) where the **** are the DN10000 compiler beta testers? We are finding
problems within 24 hours of installing the compilers, but that seems to
be story of our life with HP/Apollo :-(.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775