From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!zaphod.mps.ohio-state.edu!rpi!crdgw1!ge-dab!peora!petsd!joe
From: joe@petsd.UUCP (Joe Orost)
Newsgroups: comp.lang.ada
Subject: Non-static constant propagation in optimizing Ada compilers
Message-ID: <1735@petsd.UUCP>
Date: 5 Jan 90 01:37:04 GMT
Reply-To: joe@petsd.UUCP (Joseph M. Orost)
Organization: Concurrent Computer Corporation, Tinton Falls, NJ
List-Id: <comp.lang.ada>

Ada compilers must be able to compute arithmetic expressions exactly.  It
says so in the language definition.  Should an optimizing compiler use this
"infinite precision" arithmetic when it is performing non-static constant
propagation?  What do you think?   For example:

   function example return float is
      f : float := 1.000000000000000000000000001;
      i : integer;
   begin
      i := integer(f);
      return f - float(i);
   end example;

If an optimizing compiler used "infinite precision" arithmetic,
it could replace the program with:

   function example return float is
   begin
      return 0.000000000000000000000000001;
   end example;

The other alternative is for the compiler to use the arithmetic of the
target machine to perform the calculations (possibly requiring emulation
if host /= target).  In this case, the function would return 0.0, which is
the answer you would get from a non-optimizing compiler.

Other similar problems occur when an optimizing compiler register allocates
floating point values, especially on a 68881/68882 where the registers hold
much more precision than single precision memory locations, which again will
cause different results than in a non-optimizing compiler.  I hear that they
are fixing this problem in the 68040.