[GHC] #14127: -fignore-interface-pragmas and -fspecialise do not go well together
GHC
ghc-devs at haskell.org
Wed Aug 16 15:29:32 UTC 2017
#14127: -fignore-interface-pragmas and -fspecialise do not go well together
-------------------------------------+-------------------------------------
Reporter: lspitzner | Owner: (none)
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.2
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Compile-time | Unknown/Multiple
crash or panic | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Changes (by RyanGlScott):
* status: infoneeded => closed
* resolution: => fixed
Comment:
After reading the source code some more, I believe this was properly fixed
in GHC 8.2. Specifically, in commit
d49b2bb21691892ca6ac8f2403e31f2a5e53feb3 (Allow top-level string literals
in Core (#8472)). That patch made the
[http://git.haskell.org/ghc.git/blobdiff/a2a67b77c3048713541d1ed96ec0b95fb2542f9a..d49b2bb21691892ca6ac8f2403e31f2a5e53feb3:/compiler/coreSyn/CorePrep.hs
following change]:
{{{#!diff
diff --git a/compiler/coreSyn/CorePrep.hs b/compiler/coreSyn/CorePrep.hs
index c93a121..fb650f6 100644 (file)
--- a/compiler/coreSyn/CorePrep.hs
+++ b/compiler/coreSyn/CorePrep.hs
@@ -1168,7 +1168,9 @@ deFloatTop (Floats _ floats)
= foldrOL get [] floats
where
get (FloatLet b) bs = occurAnalyseRHSs b : bs
- get b _ = pprPanic "corePrepPgm" (ppr b)
+ get (FloatCase var body _) bs =
+ occurAnalyseRHSs (NonRec var body) : bs
+ get b _ = pprPanic "corePrepPgm" (ppr b)
-- See Note [Dead code in CorePrep]
occurAnalyseRHSs (NonRec x e) = NonRec x
(occurAnalyseExpr_NoBinderSwap e)
}}}
Before, `get` was being called on a `FloatCase`, which is the only
constructor that could have given the output `[True]
$s$fSelectorMetaMetaSel_a = "_dconf_dump_annotations"#`. But now that this
case is covered properly, the issue appears to have gone away. So I'll opt
to close this issue, since I can't reproduce the problem on 8.2, and
coming up with a minimal regression test doesn't seem feasible.
Please feel free to re-open the issue if you come across the same panic on
GHC 8.2 or later.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14127#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list