home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.arch
- Path: sparky!uunet!news.univie.ac.at!email!mips.complang.tuwien.ac.at!anton
- From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
- Subject: Re: Program behaviour (was Re: trapping speculative ops
- Message-ID: <1992Aug28.095045.8327@email.tuwien.ac.at>
- Sender: news@email.tuwien.ac.at
- Nntp-Posting-Host: mips.complang.tuwien.ac.at
- Organization: Institut fuer Computersprachen, Technische Universitaet Wien
- References: <l9q6e0INN919@exodus.Eng.Sun.COM> <1992Aug27.202845.10747@bcars64a.bnr.ca>
- Date: Fri, 28 Aug 1992 09:50:45 GMT
- Lines: 29
-
- In article <1992Aug27.202845.10747@bcars64a.bnr.ca>, schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
- |> In article <l9q6e0INN919@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
- |> >As far as loads and stores go, I am similarly mystified by the
- |> >insistence that each and every trap from the source program be
- |> >preserved in "very-optimized" code (not code compiled for debugging,
- |> >or at a "normal" level of optimization).
- |>
- |> Some people (including me), believe that there is only *one* level
- |> of optimization. One should always ship the same binary that one
- |> tested; doing otherwise expresses immense faith in the ability of
- |> one's process to recompile the same source as well as the correctness
- |> of ones tools - the compilers, optimizes, linkers.
-
- Not only that. Optimization can even uncover bugs in the program that
- don't show up in debugging mode. E.g.:
-
- f(i, i++);
-
- This could work as you intended (say, using the same value of i both
- times) in debugging mode, but it could deliver different results when
- optimized.
-
- The moral of the story: Deliver the same code that you debugged. Let
- sleeping bugs sleep:-)
-
- - anton
- --
- M. Anton Ertl Some things have to be seen to be believed
- anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
-