From: Dick Hendrickson <dick.hendrick...@att.net>
Subject: Re: [Historical] "Logical" type representation
Date: 1999/06/25
Message-ID: <3773A2DD.29F@att.net>#1/1
X-Deja-AN: 493805331
Content-Transfer-Encoding: 7bit
References: <7kdq9r$ef5@deadzone.rsn.hp.com> <7kf0ml$4uq@newsops.execpc.com> <1999Jun21.172819.1@sldb4.slac.stanford.edu> <87yahcdoia.fsf@bglbv.my-dejanews.com> <7kov68$250$1@walter-fddi.cray.com> <3771284A.20E10EEB@moene.indiv.nluug.nl> <377207d2@dnews.tpgi.com.au> <87ogi5fktt.fsf@bglbv.my-deja.com>
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@worldnet.att.net
X-Trace: bgtnsc01.worldnet.att.net 930325255 5506 12.75.167.138 (25 Jun 1999 15:40:55 GMT)
Organization: AT&T WorldNet Services
Mime-Version: 1.0
NNTP-Posting-Date: 25 Jun 1999 15:40:55 GMT
Newsgroups: comp.lang.fortran

bg...@my-deja.com wrote:
> 
> "Roger Caffin" <r.caf...@tpg.com.au> writes:
> 
> > Toon Moene wrote in message
> [In the context of a ones' complement machine:]
> > >Question to the Fortran compiler bug list:
> > >
> > >I have this 3000 line Fortran routine and after compilation, only a
> > ><very small> object file results - how comes ?
> 
> > Simple.
> > Since it is just a test program it doesn't really do anything.
> > You are using the DVF compiler with full optimisation turned on.
> [...]
> 
> You are being unfair to DVF. Toon was paraphrasing an actual report of
> the compiler bug he described in the rest of his post. Judging from
> the description, this could not have occurred on any of the hardware
> architectures supported by DVF.
> 
> You are also raising the broader question: should software attempt to
> read the user's mind? My current answer to this is "certainly not:
> such attempts are bound to fail on *my* mind, and I am prepared to
> go to great lengths to make sure that this remains so for the
> foreseeable future."

Are you sure about this?  Compilers routinely discard "dead code"
and that's almost always a good thing.  Many times a program is
written to deal with the general case and then specific cases are
compiled by changing a few constants in a parameter statement.  A
good optimizer should do the right thing.  (Yes, it's a good idea to
have a /non-optimize switch and a good compiler also warns about
non-reachable blocks of dead code).

I've got a program that is prepared to deal with Quad precision
so it defines parameters R1_KV, R2_KV, and R4_KV.  And I have a few
IF statements like   IF (R2_KV .EQ. R4_KV) blah blah
to do the right thing on processors that don't support Quad precision.
I'd expect the compiler to do the comparison at compile time and
not generate the dead code.

Similarly, compilers do interprocedural analysis (or inlining which 
is about the same thing) and the compiled coded is based on the
actual values of the arguments.  Many general purpose subroutines
are called from only a few places and have a few constants for 
some of their arguments.  The code can be much more efficient if
the actual values are used at compile time to control code
generation.

Dick Hendrickson