May 2017 - ghc-tickets

[GHC] #11758: Drop x86_64 binutils <2.17 hack
by GHC 20 Jun '17

20 Jun '17

#11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc2 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `X86.CodeGen.genSwitch` contains this comment, {{{ else -- HACK: On x86_64 binutils<2.17 is only able to generate -- PC32 relocations, hence we only get 32-bit offsets in -- the jump table. As these offsets are always negative -- we need to properly sign extend them to 64-bit. This -- hack should be removed in conjunction with the hack in -- PprMach.hs/pprDataItem once binutils 2.17 is standard. }}} binutils 2.17 is now quite standard; even CentOS 5 shipped with 2.17. I think it is likely safe to remove this hack at this point. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13681: Remove deprecated ForceSpecConstr
by GHC 20 Jun '17

20 Jun '17

#13681: Remove deprecated ForceSpecConstr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: SpecConstr | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a note at the top of `SpecConstr` which says {{{ ToDo [Oct 2013] ~~~~~~~~~~~~~~~ 1. Nuke ForceSpecConstr for good (it is subsumed by GHC.Types.SPEC in ghc-prim) 2. Nuke NoSpecConstr }}} `ForceSpecConstr` still exists so this ticket is to track the progress made on removing it. It isn't clear to me why it is ok to get rid of `NoSpecConstr` (which prevents SpecConstr firing) either. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13681> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13691: Bump time submodule
by GHC 16 Jun '17

16 Jun '17

#13691: Bump time submodule -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `time` version currently on the `ghc-8.2` branch is [[https://github.com/haskell/time/issues/74|broken]] Make sure this gets fixed before the release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13691> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2
by GHC 16 Jun '17

16 Jun '17

#13708: Panic! (the "impossible" happened) bug in GHC 8.2.1 rc2 -------------------------------------+------------------------------------- Reporter: deech | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The bug can be reproduced but it does take some setup. Here's the error report in case it's familiar: {{{ ... [1 of 2] Compiling Valuators ( .stack- work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-fluid-valuators/fltkhs- fluid-valuators-tmp/Valuators.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.0/build/fltkhs-fluid-valuators/fltkhs- fluid-valuators-tmp/Valuators.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-linux): idInfo a_ad4D Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The bug is a GUI binding. Reproducing is reliable but unfortunately takes some setup. To reproduce: {{{ # Install the FLTK GUI toolkit from source. > wget http://fltk.org/pub/fltk/1.3.4/fltk-1.3.4-1-source.tar.gz > tar -zxf fltk-1.3.4-1-source.tar.gz > cd fltk-1.3.4-1 > ./configure --enable-gl --enable-shared --enable-localjpeg --enable- localzlib --enable-localpng > make > sudo make install > fltk-config --version 1.3.4-1 # Install the bindings from source > git clone -b 8.2.1-rc2 https://github.com/deech/fltkhs > cd fltkhs > cabal install # Install the package causing the bug from source > git clone -b 8.2.1-rc2 https://github.com/deech/fltkhs-fluid-demos > cd fltkhs-fluid-demos > cabal install }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13751: Runtime crash with <<loop>> after concurrent stressing of STM computatinos.
by GHC 16 Jun '17

16 Jun '17

#13751: Runtime crash with <<loop>> after concurrent stressing of STM computatinos. -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10414 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For reproduction, see stack project at https://github.com/robinp/bugreports/tree/master/blackhole. Copying its readme here: ### Compiler & OS GHC 7.10.3, 8.0.1, 8.0.2 (didn't check others). Linux: 4.10.13-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux 4-core ### What does the code do? TLDR endlessly forks a batch of 8 threads, and waits for them to finish. Each thread calls `observeDuration` on an irrelevant IO action. `observeDuration` measures the time, then updates some data structures in `STM` context in a `TVar`. After a short while (usually within 1 minute), the program aborts with `<<loop>>`. See below for a more detailed investigation. ### To run stack install # Restart if doesn't terminate in a minute. loop-exe +RTS -N4 -Ds > debug 2> debug.out ; beep ### Observe `debug` shows the metering batches run for a while, then get stuck. `debug.out` contains `<<loop>>`. My debug log reading fu is poor, but in less cleaned-up versions of the program it was more trivial to see that two threads get blocked on each others blackhole. In the current log there is mentioning of blackholes, but also MVars, and I don't see what's going on. ### Tracking down When built with profiling (remove `--eventlog --debug` from cabal file, then `stack clean` then `stack build --profile`), and running with `+RTS -N4 -xc` the following stack traces appear: *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.meter, called from Main.mainPrometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (IND_STATIC), stack trace: Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main loop-exe: loop-exe: <<loop>> <<loop>> loop-exe: thread blocked indefinitely in an MVar operation An other stack trace from an other run as bonus (these two are representative): *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Prometheus.Metric.Summary.invariant, called from Prometheus.Metric.Summary.compress, called from Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Prometheus.Metric.Summary.invariant, called from Prometheus.Metric.Summary.compress, called from Prometheus.Metric.Summary.observe, called from Prometheus.Metric.Summary.observeDuration, called from Main.meter.action, called from Main.meter.cfork, called from Main.meter, called from Main.main loop-exe: <<loop>> *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.meter, called from Main.main *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.meter, called from Main.main loop-exe: thread blocked indefinitely in an MVar operation I tried to even simplify by removing `prometheus-client` dep, but it seems that the kind of computation done in Prometheus.Metric.Summary.observe, namely putting a lazy computation inside a data type stored in a TVar, are needed to trigger the blackholing. When I tried to simplify those operations, or bang the remaining few fields of the data type, the error didn't reproduce (at least couldn't reproduce as quick as it usually does). The relevant pieces of code from prometheus-client's P.M.Summary module. Note: I manually replaced the `MonadMonitor` constraint with plain IO in that call chain, but it didn't have much effect. {{{#!hs data Estimator = Estimator { estCount :: !Int64 , estSum :: !Double , estQuantiles :: [Quantile] , estItems :: [Item] } deriving (Show) newtype Summary = MkSummary (STM.TVar Estimator) observeDuration :: IO a -> Metric Summary -> IO a observeDuration io metric = do start <- getCurrentTime result <- io end <- getCurrentTime let dt = fromRational $ toRational $ end `diffUTCTime` start withSummary metric dt return result observe :: MonadMonitor m => Double -> Metric Summary -> m () observe v s = withSummary s (insert v) withSummary :: MonadMonitor m => Metric Summary -> (Estimator -> Estimator) -> m () withSummary (Metric {handle = MkSummary valueTVar}) f = doIO $ STM.atomically $ do STM.modifyTVar' valueTVar compress STM.modifyTVar' valueTVar f insert :: Double -> Estimator -> Estimator insert = ... compress :: Estimator -> Estimator compress = ... }}} I checked `insert` and `compress` and they don't seem to be able to loop in any edge case, so this bug is likely an RTS thing. ### Related tickets I found: https://ghc.haskell.org/trac/ghc/ticket/10218 GHC creates incorrect code which throws <<loop>> https://ghc.haskell.org/trac/ghc/ticket/10414 : Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8697: Type rationals
by GHC 16 Jun '17

16 Jun '17

#8697: Type rationals ------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've used GHC's Type Nats to implement my own type level rationals (code below). This works fine, but the syntax is a little funky because you have to write out the number as a fraction. For example, you must write 13/10 instead of 1.3; or even worse, 13/1 instead of 13. It would be nice to just write the decimal notation. I only see one potential problem with this feature: the dot in the decimal notation could interfere with the dot in forall statements. I guess this can be parsed unambiguously, but maybe not. {{{ data Frac = Frac Nat Nat data instance Sing (n::Frac) = SFrac Integer Integer instance (SingI a, SingI b) => SingI ('Frac a b) where sing = SFrac (fromSing (sing :: Sing a)) (fromSing (sing :: Sing b)) instance Fractional r => SingE (Kind :: Frac) r where fromSing (SFrac a b) = fromIntegral a/fromIntegral b type (/) a b = 'Frac a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13267: Constraint synonym instances
by GHC 15 Jun '17

15 Jun '17

#13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something funny happens when you try to declare an instance of a constraint synonym: {{{ {-# LANGUAGE ConstraintKinds #-} module F where type ShowF a = Show (a -> Bool) instance ShowF Int where show _ = "Fun" }}} I get: {{{ F.hs:8:5: error: ‘show’ is not a (visible) method of class ‘ShowF’ | 8 | show _ = "Fun" | ^^^^ }}} OK, but it gets weirder. Look at: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances #-} module F where type ShowF a = (Show (a -> Bool)) instance ShowF Int where }}} This is accepted (with a complaint that `show` is not implemented.) It gets even more awful: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances, MultiParamTypeClasses #-} module F where type ShowF a = (Show Bool, Show Int) instance ShowF Int where }}} This is awful: GHC treats `Show Bool` and `Show Int` as if they were constraints, and then emits the following DFun: {{{ df9d1b4635f2a752f29ff327ab66d1cb $f(%,%)ShowShow :: (Show Bool, Show Int) DFunId {- Strictness: m, Inline: CONLIKE, Unfolding: DFun: @ a @ b. @ (Show Bool) @ (Show Int) $fShowBool $fShowInt -} }}} I don't even know what this is supposed to mean. OK, so what should we do? I think there are a few possibilities: 1. Completely outlaw instance declarations on constraint synonyms. 2. Allow instance declarations on constraint synonyms, but only if after desugaring the synonym, you end up with a single class head. I would find this useful in a few cases, for example, if you are writing `instance MonadSample (Impl t) MyMonad`, if you had `type MonadSample2 t a = MonadSample (Impl t) a` you might prefer writing `instance MonadSample t MyMonad` instead 3. Figure out what instance declarations with multiple class heads, and proceed accordingly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13429: Optimizer produces Core with an infinite <<loop>>
by GHC 14 Jun '17

14 Jun '17

#13429: Optimizer produces Core with an infinite <<loop>> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While using vector package to implement convolution and supplying `-O1` or `-02` to ghc compilation results in core with an infinite loop. In order to trigger this behavior at least two modules is required. Attached is the minimal setup that I could come up with, that demonstrates the issue. Here is the stack trace: {{{ $ stack --install-ghc --resolver lts-8.3 exec -- ghc -O1 -prof -fprof-auto main.hs && ./main +RTS -xc [1 of 2] Compiling Loop ( Loop.hs, Loop.o ) [2 of 2] Compiling Main ( main.hs, main.o ) Linking main ... *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.CAF --> evaluated by: Main.main, called from Main.CAF --> evaluated by: Loop.toKernel.\, called from Data.Vector.Fusion.Util.>>=, called from Loop.toKernel, called from Main.main, called from Main.CAF --> evaluated by: Data.Vector.Fusion.Util.>>=, called from Loop.toKernel, called from Main.main, called from Main.CAF *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.CAF main: <<loop>> }}} At first I though that it might be a bug in a vector package, which is still a possibility, but since I was not able to observe that issue with ghc-7.8.4, I decided to open an ticket here. I tested attached code with all of subsequent released ghc versions (7.10.1 - 8.0.2), which resulted in the infinite loop. Worth noting that sometimes, when recompilation of only the `main.hs` file is enforced, program starts to work as expected. Here is an example: {{{ $ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main [1 of 2] Compiling Loop ( Loop.hs, Loop.o ) [2 of 2] Compiling Main ( main.hs, main.o ) Linking main ... main: <<loop>> $ touch main.hs $ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main [2 of 2] Compiling Main ( main.hs, main.o ) Linking main ... <Image 1x1> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 47

[GHC] #13756: Typo in user guide suggests that there's an -O* option
by GHC 14 Jun '17

14 Jun '17

#13756: Typo in user guide suggests that there's an -O* option -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide /options-optimise.html it still correctly said: {{{ No -O*-type option specified: This is taken to mean: “Please compile quickly ... }}} But in https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /using-optimisation.html#ghc-flag--O* it says: {{{ -O* This is taken to mean: “Please compile quickly ... }}} The `No -O*-type option specified:` bit must have been accidentally dropped in the conversion to the new user guide format. (I dared put this into 8.2.1 because it's probably trivial to fix if one understands the syntax language that the user guide is written in.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12056: Too aggressive `-w` option
by GHC 12 Jun '17

12 Jun '17

#12056: Too aggressive `-w` option -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- By running {{{ ghc -w -Wunrecognised-warning-flags -Wfoo Main.hs }}} I would expect the warning {{{ on the commandline: warning: unrecognised warning flag: -Wfoo }}} however this warning isn't reported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14