#13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * version: 8.0.1 => 8.2.1-rc1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I wonder if this bug has the same underlying cause as #13500? The `[flags changed]` part makes me suspect so. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ezyang (added) Comment: I've identified commit 818760d68c0e5e4479a4f64fc863303ff5f23a3a (Fix #10923 by fingerprinting optimization level) as the culprit. cc'ing ezyang, the author of that commit. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Suppose I wanted ghci for optimization, specifically -O2, how would I specify that? See #13002 as mentioned above. Assuming I could specify it then ghci would simply load the compiled file, right? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Thanks, that answers my question, you can do it as you described. Also you can specify those options in your .ghci file and that works as would be expected. So the question seems to be, if you have an object file compiled with flags different than the ghci flags (possibly the default ones) should ghci load it (as it did in 8.0.2) or should it compile the source into interpreted byte code and load that (as it does now) I think I prefer the old behavior, if you want interpreted byte code, remove the object file otherwise load will load your object file as is. However if we want to change this behavior to what it is currently I could live with that as long as the documentation is clear about the change and the current behavior. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Whether or not it is the "right" behaviour, it would be good if the user manual documented the behaviour and the underlying principles. And describes how to work around it if you want something different. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I think I will be happy with whatever people come up with here. I filed the bug originally as I was surprised by the change in behavior. As Simon wrote above: it would be good if the user manual documented the behaviour and the underlying principles. And describes how to work around it if you want something different. As Ben wrote above ideally the final fix will also address the converse of this bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): I just ran into this issue myself. The main thing I have to add is to note that this issue also affects -fhpc, so whatever solution should take that into account too. I took a look through FlagChecker.hs for other candidates, but didn't see anything else. A simple fix would be for ghci to note that -fhpc or -O are being ignored, but still include them in its flag hash when it does the recompilation check. I didn't notice that suggestion in the discussion above. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I like the "ghci allows but ignores -fhpc and -O" idea and I'd like to see this in 8.2.2. However see also https://ghc.haskell.org/trac/ghc/ticket/13002, not sure if "ghci allows but ignores -fhpc and -O" means that 13002 would not get resolved. As my original summary wrote this is a regression and I'd like to see it resolved sooner rather than later. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: high | 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:D3514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => RecompilationCheck -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: high | 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:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I'll settle for what Simon suggested: " if the user manual documented the behaviour and the underlying principles. And describes how to work around it if you want something different." Whatever the solution, I'd like to be able to specify the optimization level of compilation, e.g. -O or -02 in a .ghci file as well as by an argument to ghci, so that it will take effect when I compile inside of emacs. i.e. in other words I'd like 13002 fixed too, if possible. The use case here is working with optimized compiled code in emacs/ghci, making changes and measuring the performance; thus you want to be able to compile those changes in emacs at a given optimization level. I think elaforge may want something more specific but I'll let him speak for himself. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

I'm not sure teaching ghci to ignore -O and -fhpc is a great idea since

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: new Priority: high | 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:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): Sorry about the delay, I guess trac doesn't email me when tickets are updated. The desired end result is that I have a bunch of .o files compiled with -O, and I need to load them into the GHC API. Similarly, I have a set of .o files compiled with -fhpc, and I need to load them into ghci. Any solution that reaches that result will probably work for me! [ bgamari ] there may be users that want to use these flags from within an

interactive session.

I don't understand this, ghci already ignores -O and -fhpc, and as far as I know always has, whether or not people want to use them. So the request is to continue ignoring those flags as always, but to be able to load files compiled with them... which presumably means include them in the hash. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: new Priority: high | 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:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I guess this probably means teasing apart fingerprints that are currently merged, recording these options separately. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: new 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:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): === Some summary === The essence of this ticket is explained quite well by Edward in comment:11. I don't think I agree with Edward about how the interpretation of `-fobject-code` should play into everything, but his essential points stand: 1. We want to be able to run `ghc --make` and be sure that we get compilation products entirely equivalent to compiling from scratch. 2. We want `ghci` (especially) to be able to load `-dynamic`-compiled modules even if those modules were compiled with slightly different options. The question of what "slightly different" means is really up to the user. === The solution === Fortunately, it looks like this is probably not hard! Currently, we use `fingerprintDynFlags` to calculate a fingerprint of all the dflags that it believes can affect the compilation result and (in `addFingerprints`) record that fingerprint in the `ModIface`. When we are compiling with flags that don't match, we recompile the dependencies. What we want to do, I believe, is record not only the fingerprint but also information about some of the individual options. Some thoughts: 1. A change in whether cost center profiling is enabled `gopt Opt_SccProfilingOn dflags` absolutely mandates recompilation. I believe we want users to be able to (selectively) ignore changes to - `-O` - `-fhpc` - `-fignore-asserts` - Automatic cost-center insertion (`-fprof-...`) I think we can do this by using one fingerprint for each of these options, or, even simpler, for each option and each module, either "This module and its dependencies use value X" or "At least one dependency uses a different value than this module". 2. I believe we're currently somewhat too conservative about language flags in general. For example, I wouldn't expect enabling `-X` + `DataKinds`, `AllowAmbiguousTypes`, `ExplicitNamespaces`, `ConstraintKinds`, `MultiParamTypeClasses`, `FunctionalDependencies`, `FlexibleInstances`, `FlexibleContexts`, `UndecidableInstances`, `TupleSections`, `TypeSynonymInstances`, `StandaloneDeriving`, `DefaultSignatures`, `NullaryTypeClasses`, `EmptyCase`, `MultiWayIf`, or `ConstrainedClassMethods` to be able to change the result of compiling any module that was successfully compiled before. For these options, we're really only interested if one of them is ''turned off'' that was previously ''turned on''. For these, rather than a proper fingerprint, we want to record, for each option and each module, whether the module or at least one of its dependencies was compiled with that flag. 3. We should consider fingerprinting the result of running the preprocessor(s) over the source. If the `-D`, `-U`, or `-I` options change, or an `#include`d file changes, we only need to recompile if the results of preprocessing have actually changed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: new 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:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, having a description of what this will look like from the users' perspective would help us ascertain whether or not this will address the issue. Once we have that perhaps elaforge could also comment. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: new 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:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm working on the separate optimization level tracking. I'll probably have that done by the end of the day. I'll likely need a bit of help to get the user interface sorted. I'm not sure how that should look. Maybe a separate `-frecompile-for-opt-level-change`? By the way, as far as I can tell, we ''don't'' track changes in ''individual'' optimization flags, like `-ffull-laziness`. I imagine we should do something about that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: Phab:D3514 => Phab:D4123 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 George): So after this fix if I load a file compiled with -O2 into ghci will ghci just load it without recompiling it? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): It feels like an odd approach. The situation implied by -fignore-optim- changes is that I'm not passing the same flags, but I want to load '.o's anyway. But from my point of view, I *am* passing the same flags, the problem is that ghci is filtering them out. So with that new flag, it becomes: pass the same flags, ghci filters out some making them not the same, pass another flag that says ignore when some flags are not the same. We'll need another flag that does the same thing for -fhpc (as you mention) and then possibly in the future some more to ignore any other symptoms of ghci filtering out flags. Doesn't it seem a bit convoluted? If I weren't following this thread, and ran into this problem, I'm not sure I'd be able to find all proper flags to get it to work. Compare that to making ghci no longer change the flags you pass, even if it can't implement them: it just works, no flags needed. You could add one to suppress the warning about "ignoring some of your flags" but we have some general verbosity level stuff already. That said, I am following this thread, so I will know about the flags, so they (once you put in one for -fhpc of course) will fix my problem. So aside from my worry that it seems overcomplicated, I'm in favor. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

Replying to [comment:38 George]:

...

So after this fix if I load a file compiled with -O2 into ghci will ghci just load it without recompiling it?

After this fix, you'll be able to load a compiled module (including one compiled with `-O` or `-O2`) into GHCi without recompiling it if nothing substantial has changed (e.g., source files) and both of the following are

#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 George): Replying to [comment:39 dfeuer]: true:

1. The file was compiled with `-dynamic` 2. GHCi is run with `-fignore-optim-changes`

The latter tells GHC that a file shouldn't be recompiled just because an

"optimization flag" has changed. That's a bit of a fuzzy designation, but it includes all the flags included in `-O2` and several others as well. The one that might be most surprising is `-fignore-asserts`. If we need to add additional flags in the future to refine the way we handle such, we can consider it.

Will this let you do what you need?

Works perfectly for me. Thanks!

I intend to do something similar for HPC, but I haven't yet.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 dfeuer): elaforge, I think I understand kind of what you're asking for now, but there are some tricky questions about the UI. The biggest question is probably how to make interaction with `-fobject-code` sensible. In particular, we don't currently produce object code (ever) when `-fobject- code` is off. So if I type `ghci -O2 A`, where `A` depends on `B`, what should happen if `B` was not compiled `-O2`? Should we generate object code for `B` anyway to obey `-O2`? That seems a bit surprising. Should we load it interpreted? That seems inconsistent. Or perhaps we should change the interpretation of `-fobject-code` in a slightly different direction. What if we make `:load *A` guarantee that it loads `A` interpreted whether or not `A` has been compiled already and whether or not GHCi was run with `-fobject-code`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:44 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): If -fobject-code is off, then ghci -O2 A B can load both modules by the usual rules, which is to say if it finds .o files that were also compiled with -O2, then it will load them. Otherwise, it loads them as bytecode. For `ghci -O2 A B` example, I think it should load B as bytecode if the flags don't match. It doesn't seem inconsistent to me, here are the rules: With -fobject-code, always load binary, which means recompile (as binary) if the flags don't match. With -fbyte-code, load binary if there already is one, and the flags match, otherwise load as bytecode. Flags that don't apply to bytecode (namely -O and -fhpc) are ignored, but do affect whether or not the flags match when loading binary. Can you expand on how it seems inconsistent? I'm guessing that you're thinking that -O means "binary and bytecode are optimized" while I'm happy for it to mean "binary is optimized" with no implication for bytecode. I admit the case might be weaker for -fhpc, in that people might not expect that -fhpc means binary only. But I guess that's just an aspect of bytecode that it doesn't support those things, and if there's a warning that says "we're ignoring these for bytecode", as there already currently is, then it seems fine to me. I think the only change would be to have DynFlags.makeFlagsConsistent emit the warnings, but not mutate the dflags. Of course it might then trigger assertion failures down the line, but presumably they would be easy to fix. I just did an experiment with -prof, because presumably it's also not supported by bytedcode, but unlike -O it doesn't warn for ghci. But it looks like while it's happy to load binary modules compiled with -prof, even if you don't pass it to ghci, it will then crash trying to run things: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/9p/tb878hlx67sdym1sndy4sxf40000gn/T/ghc93652_0/libghc_1.dylib, 5): Symbol not found: _CCS_DONT_CARE Referenced from: /var/folders/9p/tb878hlx67sdym1sndy4sxf40000gn/T/ghc93652_0/libghc_1.dylib Expected in: flat namespace in /var/folders/9p/tb878hlx67sdym1sndy4sxf40000gn/T/ghc93652_0/libghc_1.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Maybe I should file this as a separate bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:46 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 dfeuer): elaforge, I have an idea that feels like it provides a reasonably consistent UI, but I'd like to see what you think. 1. Optimization flags (including `-O0`) imply `-fobject-code`. This ensures that GHC respects optimization flags regardless of `--interactive`. 2. Even when `-fobject-code` is on, `:load *M` will load `M` as bytecode. This provides the "escape hatch" from `-fobject-code` that you need to use debugging features, etc. 3. We add `-fignore-optim-changes` and `-fignore-hpc-changes` (​Phab:D4123), enabling users to put together object code and bytecode with diverse optimization levels and HPC info while still updating automatically based on source changes and whether profiling is enabled. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:48 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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.3 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): bgamari: No problem, I understand about release schedules. I'm sorry to drag it out a bit, but on the other hand it's good to be careful about flag design since it's one of those APIs that is hard to fix later. I'll copy paste this in the mailing list thread, just so there's a record in both places. I still don't feel like 1 is necessary, I'd rather flags cause other flags to be ignored with a warning, rather than turn on other flags. But that's just a vague preference, with no strong evidence for it. Maybe it could emit a warning if you didn't put -fobject-code in explicitly, e.g. "-O implies -fobject-code, adding that flag." So as long as we accept 1, then 2 and 3 follow naturally. Given that, I support this UI. Thanks for looking into it! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:50 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.2.3 => 8.4.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:52 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler