#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: patch Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): I don't totally understand the point about the debugger. I thought ghci always loads binary if it can? I usually use the * syntax for :load, so the current module is always interpreted, so I can see private names if there an export list. Hasn't it always been true that to set a breakpoint you have to force the module to load as bytecode, either with * or by touching it so it thinks the binary is out of date? I don't really use the debugger so I might be missing some detail. For context, I'm loading modules in two situations: one is from command line ghci, where I'm loading test modules, which were compiled with -fhpc. I also link the modules into a test binary, which I do I want -fhpc for so I can get coverage, but when testing from ghci I don't care about that stuff, I just want it to load the binary modules, not recompile everything as bytecode every time. The other situation is that I use the GHC API to load modules into a running application. Those modules are compiled with -O, and I use GHC.setSessionDynFlags to get the same flags used to compile them when compiling the application itself so I can load them. But the GHCI API then goes and filters out -O, making the flags different... if I'm remembering the results of my research correctly. After that, I'll give it some expressions to evaluate, or maybe reload some modules as bytecode, just like you might do in ghci. Similar to the -fhpc case, I don't actually care that the interpreted code is not optimized, I just want to load the binary modules. My suggestion was to turn off the thing that filters the flags. Of course even if it retains -O it doesn't mean the bytecode interpreter can magically do optimizations, so it would be a bit of a lie. But it seems like the lie is not so bad. It would be optimizing if it could, and it will act as if the flag is set for the purposes of loading modules, but by its nature bytecode is not optimized, so it just doesn't apply when it compiles bytecode. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:43 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler