Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-gr.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!utah-cs!utah-gr!donn
From: donn@utah-gr.UUCP (Donn Seeley)
Newsgroups: net.lang.f77
Subject: Re: Problem with EQUIVALENCE
Message-ID: <1319@utah-gr.UUCP>
Date: Sun, 27-Jan-85 01:43:17 EST
Article-I.D.: utah-gr.1319
Posted: Sun Jan 27 01:43:17 1985
Date-Received: Tue, 29-Jan-85 06:44:25 EST
References: <803@ttds.UUCP> <44@angband.UUCP>
Organization: University of Utah CS Dept
Lines: 39

Bo Sundman (sundman@ttds.UUCP) and Steve Correll (sjc@angband.UUCP)
write about a problem with equivalences.  Steve Correll is correct in
pointing out that the basic problem is that the VAX has floating point
move instructions which normalize data; these instructions also may
cause reserved operand faults for malformed data.  The 4.2 BSD compiler
generates floating point move instructions for floating point
assignments when optimization is not enabled.  In the examples, the
'wrong' result is achieved by taking a variable last defined as an
INTEGER, treating it as a DOUBLE PRECISION value and assigning it to a
DOUBLE PRECISION variable, then treating the result as an INTEGER.

Jerry Berkman at Berkeley has a change, implemented in recent versions
of the compiler, which causes integer move instructions to be
substituted for floating point move instructions in all situations, not
just when optimizing.  The change is fairly complicated and is one of
many that I haven't posted since I began using code from post-4.2 BSD
versions of the C compiler...  At any rate, both Sundman's and
Correll's examples work 'correctly' with the local version of f77
because an integer move is a straightforward copy with no normalization
or checks for well-formedness.

Of course the behavior of the examples under the 4.2 compiler is
technically in accord with the standard.  Section 17.3 of ANSI
X3.9-1978, subsection 2, states:  'When an entity of a given type
becomes defined, all totally associated entities of different type
become undefined.' You are strongly advised not to write code that
assumes that undefined values are predictable.  But (sigh) there are
lots of old programs written by people who 'knew' there would never be
a problem, so the next release of the compiler will support them.

Before Jerry's fix, I used to arrange for 'make' to run 'sed' on the
assembler output of the compiler when not optimizing so that all 'movf'
and 'movd' instructions were changed to 'movl' and 'movq'
instructions.  It's something to think about...  If you're really
desperate, write me for a copy of the new compiler.  FTP is
encouraged, tapes are tolerated but have a long turnaround...

Donn Seeley    University of Utah CS Dept    donn@utah-cs.arpa
40 46' 6"N 111 50' 34"W    (801) 581-5668    decvax!utah-cs!donn