Re: inlining + optimization = nuisance bugs

Andrew Fry <andrewf@slhosiery.com.au>
24 Sep 1998 00:23:12 -0400

          From comp.compilers

Related articles
[14 earlier articles]
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-18)
Re: inlining + optimization = nuisance bugs cfc@world.std.com (Chris F Clark) (1998-09-19)
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-22)
Re: inlining + optimization = nuisance bugs zalman@netcom.com (1998-09-22)
Re: inlining + optimization = nuisance bugs chase@world.std.com (David Chase) (1998-09-22)
Re: inlining + optimization = nuisance bugs christian.bau@isltd.insignia.com (1998-09-22)
Re: inlining + optimization = nuisance bugs andrewf@slhosiery.com.au (Andrew Fry) (1998-09-24)
Re: inlining + optimization = nuisance bugs comments@cygnus-software.com (Bruce Dawson) (1998-09-24)
Re: inlining + optimization = nuisance bugs Martin.Ward@SMLtd.Com (1998-09-26)
Re: inlining + optimization = nuisance bugs toon@moene.indiv.nluug.nl (Toon Moene) (1998-09-29)
Re: inlining + optimization = nuisance bugs wclodius@aol.com (1998-09-29)
Re: inlining + optimization = nuisance bugs ralph@inputplus.demon.co.uk (Ralph Corderoy) (1998-09-29)
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-29)
[7 later articles]
| List of all articles for this month |

From: Andrew Fry <andrewf@slhosiery.com.au>
Newsgroups: comp.compilers
Date: 24 Sep 1998 00:23:12 -0400
Organization: Compilers Central
References: 98-09-071 98-09-085
Keywords: arithmetic

> However, you can have "too much" precision if you can't have it
> universally.


It seems that people have been upset when the compiler emitted code
counter to whatever dirty tricks they were expecting.


The job of a compiler is to do the dirty work. Some of the floating
point dirty work is to keep track of machine precision. If the
compiler was to provide some kind of precision information, it could
tell us what is really happening, and relieve apps programmers of
trying to outguess the compiler programmers.


The compiler could provide pseudofunctions, like sizeof(), which would
tell us what precision (at compile time) or error range (at run time)
is actually available. Something like -


sizeof(x) gives 8
precision(x) gives 15 number of accurate digits
precision(x*y) gives 14
pluserror(x) gives 1e-14 + part of +/- range
minuserror(x) gives 3e-15 - part of +/- range


We could expand this by telling the compiler the precision of input
data, and let it do all the dirty work.


read(......, x, y)
precision(x) = 8 tell compiler actual precision
precision(y) = 6
x = x * y
precision(x) now gives 6


Alternatively, floating point types could include actual precision
data, which could be optimised out if never used.


type double = record
value: machinedouble;
precision: integer;
end;


I am not aware of compilers which provide these kind of facilities.
Has anything along these lines been done?


Andrew Fry
[PL/I let you specify the number of bits of precision, but the compilers
just round up to the next largest convenient hardware format. -John]






--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.