Andrew Coppin wrote:
> On the other hand, turn up the optimisation settings on a C compiler
> high enough and the program breaks. Somewhere the compiler elides a
> second call to a function which actually happens to have some
> side-effect that the compiler isn't aware of, and your stream is now one
> byte out of alignment, or whatever. Fiddling with optimisation settings
> in GHC may make your program slow to a crawl rather than go faster, but
> it *never* makes it segfault on startup.
Note, though, that "slow to crawl" may go as far as "not terminate".
GHC's optimizer can make a terminating program nonterminating. For some
discussion, see:
http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion#Discussion
In fact, one can also make up examples where turning on optimization
lets GHC transform a "good" program into one halting with an arbitrary
error (division by zero, say).
The recipe for (artificial) such examples can be found in footnote 2 of:
http://www.iai.uni-bonn.de/~jv/TUD-FI09-06.pdf
The error "in the wild" that is mentioned on the wiki page occurred in
the context of the stream fusion library development.
Best regards,
Janis.
--
Jun.-Prof. Dr. Janis Voigtländer
http://www.iai.uni-bonn.de/~jv/
mailto:j...@iai.uni-bonn.de
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
