May 2013 - ghc-tickets

[GHC] #7787: modifyMVar does not restore value if callback returns error value
by GHC 22 Jun '13

22 Jun '13

#7787: modifyMVar does not restore value if callback returns error value ----------------------------------------+----------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- `modifyMVar` is currently implemented as follows: {{{ modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b modifyMVar m io = mask $ \restore -> do a <- takeMVar m (a',b) <- restore (io a) `onException` putMVar m a putMVar m a' return b }}} The problem is that it forces the `(a',b)` outside of the exception handler. If forcing this throws an exception, `putMVar` will not be called, and a subsequent `withMVar` or similar will hang. Example: {{{ > import Control.Concurrent.MVar > mv <- newMVar 'x' > modifyMVar mv $ \_ -> return undefined *** Exception: Prelude.undefined > withMVar mv print -- hang -- }}} Perhaps we can fix it like this: {{{ - (a',b) <- restore (io a) `onException` putMVar m a + (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 4

[GHC] #7842: Incorrect checking of let-bindings in recursive do
by GHC 21 Jun '13

21 Jun '13

#7842: Incorrect checking of let-bindings in recursive do --------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- I have run into a problem with the type-checking of recursive do blocks, which reduces to the following example: {{{ {-# LANGUAGE RecursiveDo #-} module Bug where bug :: (Int -> IO Int) -> IO (Bool, Char) bug m = mdo i <- m i1 -- RECURSION let i1 :: Int i1 = i -- RECURSION -- This appears to be monomorphic, despite the type signature. f :: b -> b f x = x return (f True, f 'a') }}} This program is rejected with the errors shown below. The problem appears to be that somehow `f` has become monomorphic, despite its type-signature. This seems to happen only when `f` is part of a `let` block that is also involved in the recursion. Here is the error reported by GHC 7.7.20130215: {{{ Bug.hs:15:23: Couldn't match expected type `Char' with actual type `Bool' In the return type of a call of `f' In the expression: f 'a' In the first argument of `return', namely `(f True, f 'a')' Bug.hs:15:25: Couldn't match expected type `Bool' with actual type `Char' In the first argument of `f', namely 'a' In the expression: f 'a' In the first argument of `return', namely `(f True, f 'a')' }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2

[GHC] #7713: Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core
by GHC 21 Jun '13

21 Jun '13

#7713: Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core -------------------------------+-------------------------------------------- Reporter: EduardSergeev | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: -fext-core panic Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- An attempt to compile the attached file with 7.6.2 (and 7.4.2) with "-O2 -fext-core" leads to: ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): make_exp (App _ (Coercion _)) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6

[GHC] #7678: GHC should compile cleanly with clang
by GHC 20 Jun '13

20 Jun '13

#7678: GHC should compile cleanly with clang --------------------------------+------------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: clang Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: 7602 | Related: --------------------------------+------------------------------------------- I'm running into several difficulties (which I'll catalog shortly) building GHC HEAD with Clang 3.2. These mostly seem to be difficulties relating to the preprocessor and the fact clang does not really respect ```-traditional-cpp``` mode, and that it is stricter than gcc about whitespace and whatnot too. This means code like: {{{ {-# RULES "thing" ... #-} }}} becomes invalid: ```clang``` is strict about the fact that preprocessor definitions must occur on the beginning of a line. There seems to be a bug in the preprocessor directive source code to this effect (that it doesn't handle whitespace before a directive.) It's quite unfortunate, because we do this a lot. This also causes build failures in the parser due to some crazy CPP hackery we do. I'll follow up with that shortly. As a workaround, we may have to force ```CPP``` to just continue being ```cpp``` which will Do The Right Thing, while ```CC``` will use ```clang``` instead. Or we'll have to have some script that seds whitespace out or something. This currently blocks #7602 since I can't test my fix otherwise. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 8

[GHC] #7661: GHC build system does not detect opt-3.0 and friends
by GHC 20 Jun '13

20 Jun '13

#7661: GHC build system does not detect opt-3.0 and friends --------------------------------+------------------------------------------- Reporter: singpolyma | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- It is common to install LLVM tools with a version suffix (such as opt-3.0, llc-3.0, etc) so that multiple versions may co-exist. For example, the Debian package llvm-3.0 does this. It would be nice if the build system could detect such tools without needing `--with-opt`, etc, specifically. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

[GHC] #7926: eventfd: unsupported operation when doing anything
by GHC 19 Jun '13

19 Jun '13

#7926: eventfd: unsupported operation when doing anything --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I'm using Debian jessie; sources.list is thus: {{{deb http://ftp.us.debian.org/debian jessie main contrib non-free}}} Ran apt-get upgrade 10 minutes ago. The contents of /var/log/apt/history.log (sorry for the massive list, not sure how to narrow it down): https://gist.github.com/joelteon/07c912a3e7e49be820cc ghc/ghci output (exit 1): {{{eventfd: unsupported operation (Function not implemented)}}} When launching a precompiled executable, the first time it executes an I/O action (exit 1): {{{hClose: user error (Pattern match failure in do expression at libraries/base/GHC/Event/Thread.hs:84:3-10}}} `strace ghci` output is in this gist: https://gist.github.com/anonymous/dcc02c8b29a65ec49be6 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 4

[GHC] #7885: LLVM build broken
by GHC 19 Jun '13

19 Jun '13

#7885: LLVM build broken --------------------------------+------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- The LLVM build has been broken for a number of weeks. Unfortunately this happened before I started running nightly LLVM builds. Here is the error I see (taken from the nightly build log): {{{ inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn-p-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes Binary Bitmap BlockId BreakArray BufWrite ByteCodeAsm ByteCodeInstr ByteCodeItbls ByteCodeLink CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Fingerprint FiniteMap ForeignCall Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes Id IdInfo IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet ObjLink OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcType TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" dll-split: internal error: scavenge_one: strange object -385875968 (GHC version 7.7.20130502 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) make[1]: *** [compiler/stage2/dll-split.stamp] Error 134 make: *** [all] Error 2 Command exited with non-zero status 2 4506.92user 192.03system 1:19:51elapsed 98%CPU (0avgtext+0avgdata 4147968maxresident)k 1400inputs+13715568outputs (3major+33440223minor)pagefaults 0swaps }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 16

[GHC] #7694: LLVM: bootstrapping with LLVM 3.2 does not work
by GHC 18 Jun '13

18 Jun '13

#7694: LLVM: bootstrapping with LLVM 3.2 does not work --------------------------------+------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Building GHC itself using the LLVM back end no longer works with LLVM 3.2 (3.1 is fine). On Linux x86_64, the stage2 compiler fails for me. Unfortunately running the test suite with stage=1 did not produce any quality failures that would help us track down the problem. This does not appear to be related to the new codegen since using LLVM 3.1 does not cause a failure. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 14

[GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 17 Jun '13

17 Jun '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------+---------------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider {{{ {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH.Quote qq = QuasiQuoter { quoteExp = \str -> case str of "a" -> [| True |] "b" -> [| id True |] "c" -> [| True || False |] "d" -> [| False |] , quotePat = undefined , quoteType = undefined , quoteDec = undefined } {-# LANGUAGE QuasiQuotes #-} module B where import A ex1 = [qq|a|] ex2 = [qq|b|] ex3 = [qq|c|] ex4 = [qq|d|] }}} In the expansion of `[qq|a|]` the source span for `True` is reported as 4:7-4:14 and 7:7-7:14 respectively -- i.e., the span of the entire quasi- quote. However, for the expansion of `[qq|b|]` and `[qq|c|]` the source span for `id`, `True`, `False`, and `(||)` are all reported as 5:11-5:14 / 6:11-6:14, i.e., starting at the "contents" of the quasi-quote. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 1

[GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file
by GHC 17 Jun '13

17 Jun '13

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file -----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: feature request | Status: new Priority: normal | Component: Template Haskell Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I'd like to be able to have something like this in the Q monad: type MessageName = String -- or something better, I don't know writeIface :: (Quasi q, Serializable a) => MessageName -> a -> q () readIfaces :: (Quasi q, Serializable a) => MessageName -> q [a] Or instead of returning [a], I'm of course fine with a Monoid, I just need the gathered results for every occurrance of the MessageName. This has to be in the interface file, because I'd like this to work through compilation units, like class instances, I'd like to get every result in the readIfaces call that is ever imported from the current module (transitive closure). Please note, that in a very hacky way this is already possible to do by abusing classes. Namely, I create an empty class for my message type. When I want to send a message, I create a new empty datatype named for the message and I make this an instance of the class. Then on the receiving side I just have to reify the class and I will receive all my instance names/messages. This came up while implementing the HFlags library: http://hackage.haskell.org/package/hflags Maybe I shouldn't be proud of this, but we currently do the hacky way explained above. I would love to have a clean approach. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7867> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6