Re: inlining + optimization = nuisance bugs

zalman@netcom.com (Zalman Stern)
1 Oct 1998 00:52:50 -0400

          From comp.compilers

Related articles
[24 earlier articles]
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)
Re: inlining + optimization = nuisance bugs tim@wagner.princeton.edu (1998-09-29)
Re: inlining + optimization = nuisance bugs dmr@bell-labs.com (Dennis Ritchie) (1998-09-29)
Re: inlining + optimization = nuisance bugs dmr@bell-labs.com (Dennis Ritchie) (1998-09-29)
Re: inlining + optimization = nuisance bugs zalman@netcom.com (1998-10-01)
Re: inlining + optimization = nuisance bugs wclodius@aol.com (1998-10-01)
Re: inlining + optimization = nuisance bugs qjackson@wave.home.com (Quinn Tyler Jackson) (1998-10-04)
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-10-04)
| List of all articles for this month |
From: zalman@netcom.com (Zalman Stern)
Newsgroups: comp.compilers
Date: 1 Oct 1998 00:52:50 -0400
Organization: ICGNetcom
References: 98-09-164
Keywords: arithmetic, optimize

Luddy Harrison (luddy@concmp.com) wrote:
: there is not a single compiler that I know
: of whose default optimization configuration preserves the bitwise
: semantics of floating point that you advocate.


It is not an issue with many architectures. (E.g. MIPS prior to
MIPS-IV.) On those machines, it just falls out.


: (Is there any compiler
: shipping for the x86 family that, when given only the -O flag, writes
: out every double precision floating number after every operation?


As many of us have said, the x86 architecture is flawed. Especially in
that the precision flags don't handle the xponent range. Witness the
whole Java issue. (Which I'm sure you'll dismiss out of hand. But I'm
also sure that if the x86 was some low volume exotic people would have
blown it off as unfit for Java in a heartbeat.)


: Is there any compiler shipping for the PowerPC familiy that, when given
: only the -O flag, suppresses the generation of fmadd and fmsub? None
: that I know of.)


Every one of them I know of (Two from Apple, Metrowerks, xlc from IBM,
gcc) provides an option to turn off fused multiply and add
operations. Likewise for other architectures that provide this feature
(e.g. MIPS-IV.) It allows compiler vendors to say "If you have sensitive
code that depends on 'exact' IEEE-754, throw this switch and you'll get
it." Which is a BIG selling point to some people.


[...]
: You design a circuit using resistors with a 10% tolerance. You build
: and test it. It works. You (suddenly, unpredictably) replace the
: resistors with new ones whose tolerance is 1%. The circuit stops
: working. Where does the fault lie?


You design a circuit which depends on matched components. The precise
value of some parameter of the components (capacitance, resistance,
whatever) can vary (say with temperature), but a set of components are
guaranteed to vary in a correlated fashion. (This is an actual design
technique by the way.) Some external force replaces one of the matched
components with a part that has superior tolerance, but is no longer
matched. The circuit operates less well or fails. Some of us feel it is
within our rights to be upset with this external force. (And as our
moderator pointed out, in a real business, such mistakes are considered
errors.)


-Z-


Post a followup to this message

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