Opened 4 years ago

Closed 17 months ago

#10965 closed bug (fixed)

GHC Panic on import with 'OPTIONS_GHC -fobject-code -O'

Reported by: Orome Owned by:
Priority: normal Milestone: 8.2.1
Component: Compiler Version: 8.0.1-rc2
Keywords: Cc: slyfox, scpmw
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #10549 Differential Rev(s):
Wiki Page:


I get

> :l Test.hs
[1 of 1] Compiling Main             ( Test.hs, interpreted )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.2 for x86_64-apple-darwin):
	floatExpr tick break<11>()

Please report this as a GHC bug:

with Test.hs:

{-# OPTIONS_GHC -fobject-code -O #-}

import Control.Exception (assert)
import Data.Char (ord)

f :: String -> String
f s = assert (all (`elem` letters) s) $ (letters!!) <$> (ix <$> s)
        ix ch = (ord ch - ord 'A')
        letters = ['A'..'Z']

OSX 10.11, GHC 7.10.2; uad-core 64-bit haswell; Homebrew GHC

Change History (6)

comment:1 Changed 4 years ago by bgamari

Resolution: duplicate
Status: newclosed

Thanks for your report. This is a duplicate of #10549 which will be fixed in 7.10.3.

comment:2 Changed 4 years ago by slyfox

Resolution: duplicate
Status: closednew

Seems to be distinct from #10549. Still happens in today's -HEAD:

$ inplace/bin/ghc-stage2 --interactive /tmp/z/G.hs 

GHCi, version 8.1.20160207:  :? for help
Loaded GHCi configuration from /home/slyfox/.ghci
[1 of 1] Compiling Main             ( /tmp/z/G.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.1.20160207 for x86_64-unknown-linux):
        floatExpr tick break<0>()

Please report this as a GHC bug:

comment:3 Changed 4 years ago by slyfox

Cc: slyfox scpmw added

comment:4 Changed 4 years ago by rwbarton

The contents of the module aren't relevant, this module exhibits the same panic.

{-# OPTIONS_GHC -fobject-code -O #-}

f :: String -> String
f = id

The difference is that this module has -fobject-code. checkOptLevel disallows -O, if the target is HscInterpreted. That was the fix for #10549. But here the target is HscAsm.

But somewhere later the target must get set to HscInterpreted, as evidenced by the output

[1 of 1] Compiling Main             ( G.hs, interpreted )

and the fact that the module contains breakpoints. (So as another issue, {-# OPTIONS_GHC -fobject-code #-} doesn't actually work. Seems it hasn't worked since at least 7.8.)

Aha, found it!

upsweep_mod hsc_env old_hpt (stable_obj, stable_bco) summary mod_index nmods
   =   ...
            -- We're using the dflags for this module now, obtained by
            -- applying any options in its LANGUAGE & OPTIONS_GHC pragmas.
            dflags = ms_hspp_opts summary
            prevailing_target = hscTarget (hsc_dflags hsc_env)
            local_target      = hscTarget dflags

            -- If OPTIONS_GHC contains -fasm or -fllvm, be careful that
            -- we don't do anything dodgy: these should only work to change
            -- from -fllvm to -fasm and vice-versa, otherwise we could
            -- end up trying to link object code to byte code.
            target = if prevailing_target /= local_target
                        && (not (isObjectTarget prevailing_target)
                            || not (isObjectTarget local_target))
                        then prevailing_target
                        else local_target

            -- store the corrected hscTarget into the summary
            summary' = summary{ ms_hspp_opts = dflags { hscTarget = target } }

Assuming this stuff about linking object code and byte code is still relevant, I guess we should call checkNewDynFlags on dflags { hscTarget = target }.

comment:5 Changed 4 years ago by rwbarton

I guess the issue is: we can't have an object code module import a byte code module, since how would we link the object file? And if we allowed {-# OPTIONS_GHC -fobject-code #-}, that could end up happening.

The workaround is of course not to write {-# OPTIONS_GHC -fobject-code #-} since it doesn't work.

comment:6 Changed 17 months ago by RyanGlScott

Milestone: 8.2.1
Resolution: fixed
Status: newclosed

I cannot reproduce this issue with GHC 8.2 and later, so closing. Please reopen if this still happens for you.

Note: See TracTickets for help on using tickets.