[GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O

[GHC]

#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