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#Discussio... 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:jv@iai.uni-bonn.de