GHCi stdout bug when base package is not optimised
Reported by Igloo:
The problem from a couple of weeks ago, where ghci's hFlush command seems to be flushing a different stdout to the one that expressions evaluated by ghci write to, happens with a "quickest" build:
SRC_HC_OPTS = -H64m -Onot -fasm
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -Onot -fasm
GhcLibHcOpts = -Onot -fasm
GhcLibWays =
SplitObjs = NO
but not if libraries are optimised:
SRC_HC_OPTS = -H64m -Onot -fasm
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -Onot -fasm
GhcLibHcOpts = -O -fasm
GhcLibWays =
SplitObjs = NO
ghci004 is an example of a failing test (no output is printed if libraries are not optimised).
This seems completely illogical to me. I'd have expected such a bug would be caused by optimisation meaning stdout gets inlined somewhere or something. Very curious!
Trac metadata
Trac field | Value |
---|---|
Version | 6.7 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | Unknown |
Architecture | Unknown |