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
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:
The error "in the wild" that is mentioned on the wiki page occurred in
the context of the stream fusion library development.
Jun.-Prof. Dr. Janis Voigtländer
Haskell-Cafe mailing list