January 2013 - ghc-tickets

[GHC] #7589: LLVM 3.2 Support
by GHC 03 Apr '13

03 Apr '13

#7589: LLVM 3.2 Support -----------------------------+---------------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- LLVM 3.2 is out as of mid December. We need to update the backend to support it. There seems to be a number of new bugs due to the change. With LLVM 3.1 we get the following testsuite failures: {{{ OVERALL SUMMARY for test run started at Mon Jan 14 21:42:32 PST 2013 3552 total tests, which gave rise to 13164 test cases, of which 0 caused framework failures 11606 were skipped 1515 expected passes 23 had missing libraries 15 expected failures 0 unexpected passes 5 unexpected failures Unexpected failures: * codeGen/should_run cgrun044 [exit code non-0] (optllvm) * concurrent/should_run 367_letnoescape [bad exit code] (optllvm) * numeric/should_run arith005 [bad stdout] (optllvm) typecheck/should_compile tc226 [exit code non-0] (optllvm) typecheck/should_compile tc235 [exit code non-0] (optllvm) }}} Where the failures marked with '*' are unique to the LLVM backend. With LLVM 3.2 we get the following: {{{ OVERALL SUMMARY for test run started at Tue Jan 15 16:02:01 PST 2013 3552 total tests, which gave rise to 13164 test cases, of which 0 caused framework failures 11606 were skipped 1512 expected passes 23 had missing libraries 15 expected failures 0 unexpected passes 8 unexpected failures Unexpected failures: ** codeGen/should_compile 1916 [exit code non-0] (optllvm) ** codeGen/should_run cgrun028 [exit code non-0] (optllvm) * codeGen/should_run cgrun044 [exit code non-0] (optllvm) * concurrent/should_run 367_letnoescape [bad exit code] (optllvm) * numeric/should_run arith005 [bad stdout] (optllvm) ** numeric/should_run numrun012 [exit code non-0] (optllvm) typecheck/should_compile tc226 [exit code non-0] (optllvm) typecheck/should_compile tc235 [exit code non-0] (optllvm) }}} Where failures marked with '*' are unique to the LLVM backend and failures marked with '**' are unique to LLVM 3.2 relative to 3.1. I believe bootstrapping with LLVM also fails now. However, that may be due to the change to the new-code-generator, and not of LLVM 3.1 -> 3.2. I'll create a separate ticket for that. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7589> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers
by GHC 24 Mar '13

24 Mar '13

#7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers -----------------------------+---------------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 7.6.1 | Keywords: qnx unregistered cross-compile Os: Unknown/Multiple | Architecture: arm Failure: Runtime crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I have built an unregistered LLVM cross-compiler for arm-unknown-nto- qnx8.0.0eabi, which I finally got to build using the attached patch. Simple programs no longer crash like they do in registered ARM cross- compilers (as reported on mailing list at http://www.haskell.org/pipermail /ghc-devs/2013-January/000005.html and other places), however the following code does crash: {{{ {-# LANGUAGE ForeignFunctionInterface #-} module Main (main) where import Foreign.Ptr foreign import ccall "wrapper" wrap_refresh :: ( IO ()) -> IO (FunPtr ( IO ())) main :: IO () main = do wrap_refresh (return ()) return () }}} It seems, from experiments, that any code using the "wrapper" imports causes this error: {{{ $ ./Main *** stack smashing detected ***: Main terminated Abort (core dumped) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7621> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #7642: Nullary type classes
by GHC 15 Mar '13

15 Mar '13

#7642: Nullary type classes -----------------------------+---------------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- GHC supports `MultiParamTypeClasses` with two or more parameters, but it explicitly rejects classes with no parameters. There doesn't seem to be a good reason for that. Some example uses that came up in IRC: {{{ isPrime :: RiemannHypothesis => Integer -> Bool unsafePerformIO :: Unsafe => IO a -> a }}} The main reason to allow it is probably that it's a pointless restriction, like EmptyDataDecls. In fact, the simplest implementation for this patch consists of deleting one line of code. The attached patch is slightly bigger because it also fixes error messages (I also included a detabbing patch). If necessary this can be made a separate `LANGUAGE` flag -- this patch just folds it into `MultiParamTypeClasses`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7642> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #7597: plugins01 fails if it has been run previously (doesn't force recompile)
by GHC 07 Mar '13

07 Mar '13

#7597: plugins01 fails if it has been run previously (doesn't force recompile) -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Component: Test Suite Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Just to make sure I don't forget about this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7597> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7627: Space in nullary unboxed tuples
by GHC 25 Feb '13

25 Feb '13

#7627: Space in nullary unboxed tuples -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ Prelude> :t (# #) (# #) :: (##) }}} should be {{{ (# #) :: (# #) }}} - the syntax requires a space. I apologise for raising such a trivial matter. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #7645: Parens in an error message
by GHC 14 Feb '13

14 Feb '13

#7645: Parens in an error message -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #7609 -----------------------------+---------------------------------------------- {{{ {-# LANGUAGE TypeOperators #-} data (+) a b f :: ((+) a a, Maybe) f = undefined }}} gives {{{ X.hs:3:16: Expecting one more argument to `Maybe' In the type signature for `f': f :: (+ a a, Maybe) }}} which should be `(+) a a`. I tried {{{ #!diff diff --git a/compiler/hsSyn/HsTypes.lhs b/compiler/hsSyn/HsTypes.lhs index 74aa477..d0d9e1a 100644 --- a/compiler/hsSyn/HsTypes.lhs +++ b/compiler/hsSyn/HsTypes.lhs @@ -614,7 +614,7 @@ ppr_mono_ty ctxt_prec (HsForAllTy exp tvs ctxt ty) ppr_mono_ty _ (HsBangTy b ty) = ppr b <> ppr_mono_lty pREC_CON ty ppr_mono_ty _ (HsQuasiQuoteTy qq) = ppr qq ppr_mono_ty _ (HsRecTy flds) = pprConDeclFields flds -ppr_mono_ty _ (HsTyVar name) = ppr name +ppr_mono_ty _ (HsTyVar name) = pprPrefixOcc name ppr_mono_ty prec (HsFunTy ty1 ty2) = ppr_fun_ty prec ty1 ty2 ppr_mono_ty _ (HsTupleTy con tys) = tupleParens std_con (interpp'SP tys) where std_con = case con of }}} but this causes the kind * to be printed as (*). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7631: Allow to differentiate between newtypes and datatypes
by GHC 13 Feb '13

13 Feb '13

#7631: Allow to differentiate between newtypes and datatypes -----------------------------+---------------------------------------------- Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Component: libraries (other) Version: 7.6.1 | Keywords: generics Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When writing a generic instance, I would like to be able to tell whether the type under consideration has been declared using newtype or data. For example, in SmallCheck we generate values of certain "depth". It is natural to treat datatype constructors as increasing the depth of the constructed value, and newtype constructors as preserving the depth. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7595: Static flags code needs cleanup
by GHC 09 Feb '13

09 Feb '13

#7595: Static flags code needs cleanup -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Component: Driver Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- While reading through the source code I noticed that code responsible for handling static flags could use some refactoring: * there are two modules that handle static flags: [[GhcFile(compiler/main/StaticFlags.hs)]] and [[GhcFile(compiler/main/StaticFlagParser.hs)]]. This is about 300 lines of code total and can be easily placed within a single file, especially that division of functions between these two files is sometimes confusing. * [[GhcFile(compiler/main/StaticFlags.hs)]] contains code responsible for handling dynamic flags. I will merge code from [[GhcFile(compiler/main/StaticFlagParser.hs)]] into into [[GhcFile(compiler/main/StaticFlags.hs)]], create a [[GhcFile(compiler/main/StaticFlags.hs-boot)]] to break module dependency cycles and move the code for handling dynamic flags to [[GhcFile(compiler/main/DynFlags.hs)]] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #7639: Fix installation issues with cross compiling + honour Stage1Only properly
by GHC 05 Feb '13

05 Feb '13

#7639: Fix installation issues with cross compiling + honour Stage1Only properly ----------------------------------+----------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Installing GHC failed | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- This patch fixes three problems that occur during a cross compile to embedded Linux (details below): 1. arm-ldu-linux-gnueabi-ghc-pkg gets a symlink but no wrapper script upon installation, and this causes the installation to break later when it tries to run it. 2. hp2ps doesn't get the prefix like the other commands do (i.e. arm-ldu- linux-gnueabi-ghc- is missing from the name of the executable). This is just for consistency. 3. The stage2 compiler is built when Stage1Only is set to YES (though it does not get installed). This makes the build take longer than it needs to. mk/build.mk: SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO INTEGER_LIBRARY = integer-simple Stage1Only = YES configure command: ./configure --target=arm-ldu-linux-gnueabi --prefix=/usr/local/ghc-ldu -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #7646: resource busy (file is locked) with multi-threaded file ops
by GHC 04 Feb '13

04 Feb '13

#7646: resource busy (file is locked) with multi-threaded file ops ----------------------------------------+----------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use *strict IO*. When compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages. But with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`. Tested under Mac OSX 10.8.2 and Linux. Tested with both GHC 7.6.1 and 7.6.2. I could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs +RTS -N2 -RTS to reproduce the bug. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6