May 2013 - ghc-tickets

[GHC] #7925: ghc 7.4.2 builds with errors on Red Had Enterprise Linux 6
by GHC 22 May '13

22 May '13

#7925: ghc 7.4.2 builds with errors on Red Had Enterprise Linux 6 -------------------+-------------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -------------------+-------------------------------------------------------- GHC 7.4.2 builds on RHEL 6, but with three test failures. None of these errors are show-stopping, and we seem to have a good Haskell Platform now built on top, but since 7.4.2 is a numbered release, the failures were unexpected, so I am reporting them. {{{ > > Unexpected failures: > > lib/Time T5430 [bad stdout] (normal) > > perf/compiler parsing001 [stat not good enough] (normal) > > simplCore/should_compile spec-inline [stderr mismatch] (optasm) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7925> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7924: throwIO gets subsumed by a later imprecise exception
by GHC 22 May '13

22 May '13

#7924: throwIO gets subsumed by a later imprecise exception -----------------------------+---------------------------------------------- Reporter: dmwit | 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: -----------------------------+---------------------------------------------- The code below exits with exception "Boom" when compiled with no options (the expected behavior, since throwIO should always subsume exceptions that come later in the IO monad), but with a head-of-empty-list exception when compiled with -O. Similar code has shown this problem on 7.2 and 7.4. {{{ {-# LANGUAGE DeriveDataTypeable #-} import Control.Exception (throwIO, Exception) import Control.Monad (when) import Data.Typeable (Typeable) data Boom = Boom deriving (Show, Typeable) instance Exception Boom main = do args <- return [] -- Should throw this exception. when (length args /= 1) (throwIO Boom) -- With -O, instead throws this one from head []. let n = read (head args) when (n < 0) (throwIO Boom) return (fromInteger n :: Int) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6135: Unboxed Booleans
by GHC 22 May '13

22 May '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by simonmar): I don't see any changes to the code generator in there - how does it work if the code generator is still generating code for Bool-returning primops, or is it just a gigantic coincidence that it still works somehow? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7913: Argument order not preserved by nubBy
by GHC 22 May '13

22 May '13

#7913: Argument order not preserved by nubBy -------------------------+-------------------------------------------------- Reporter: paullik | Owner: Type: bug | Status: new Priority: normal | Component: Prelude Version: 7.6.3 | Keywords: nubBy Os: Linux | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- Hello. I recently wanted to know how the element 4 in [2,4] is ruled out by: {{{ nubBy (\x y -> x `mod` y == 0) [2,4] }}} and discussing this on #haskell we discovered that the documentation or the code is buggy. The [http://hackage.haskell.org/packages/archive/base/latest/doc/html/src /Data-List.html#nubBy numBy source] states that ''we keep the call to `eq` with arguments in the same order as in the reference implementation'', which, comparing the following two lines, is not true: {{{ nubBy eq (x:xs) = x : nubBy eq (filter (\ y -> not (eq x y)) xs) elem_by eq y (x:xs) = y `eq` x || elem_by eq y xs }}} Also this is easily proved by defining: {{{ nubBy' eq [] = [] nubBy' eq (x:xs) = x : nubBy' eq (filter (\ y -> not (eq x y)) xs) }}} Then running: {{{ nubBy (\x y -> x `mod` y == 0) [2,4] }}} which yields [2] because of '''eq y x''' and {{{ nubBy' (\x y -> x `mod` y == 0) [2,4] }}} which yields [2,4] because of '''eq x y'''. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7913> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2528: nub not as reliable as nubBy
by GHC 22 May '13

22 May '13

#2528: nub not as reliable as nubBy -----------------------------+---------------------------------------------- Reporter: jdressel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 7.8.1 Comment: See also #7913 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2528#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 22 May '13

22 May '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Changes (by jstolarek): * status: new => patch Comment: Patches submitted. Some remarks: * I updated the wiki page. It describes motivation for changes, design decisions (why return Int#) and an example benchmark that shows how new primops can be used to write faster algorithms. * This is my first serious change to the compiler so I think this patch should be carefully reviewed. Most of all, someone with more knowledge than me should probably take a look at functions `isComparisonMachOp` and `maybeInvertComparison` in `cmm/CmmMachOp.hs` and decide whether they are still necessary or not. I think they are, but I am not certain. * I remind that constant folding for Integer works for primop wrappers and not primops themselves. I think it will be much easier to deal with this when it is considered as a separate issue. Ones the patches get accepted I'll fill a ticket for this. * I noticed that the testsuite is not adapted to work with integer- simple library. Running validation with `INTEGER_LIBRARY=integer-simple` results with many tests failing because they have an explicit dependency on integer-gmp package or one of its internal modules. Should I create a ticket for this? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5863: Deriving Typeable for data families
by GHC 21 May '13

21 May '13

#5863: Deriving Typeable for data families ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: deriving/should_fail/T5863a | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T5863a -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5863#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5863: Deriving Typeable for data families
by GHC 21 May '13

21 May '13

#5863: Deriving Typeable for data families -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by dreixel): * status: new => closed * resolution: => fixed Comment: Fixed. The error now is: {{{ T5863a.hs:9:31: Can't make a derived instance of ‛Typeable * (T Int)’: Deriving Typeable is not allowed for family instances; derive Typeable for ‛T’ alone In the data instance declaration for ‛T’ T5863a.hs:12:32: Can't make a derived instance of ‛Typeable * (T Bool)’: Deriving Typeable is not allowed for family instances; derive Typeable for ‛T’ alone In the data instance declaration for ‛T’ }}} As apparently there is already a test named T5863, I named this one T5863a. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5863#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5863: Deriving Typeable for data families
by GHC 21 May '13

21 May '13

#5863: Deriving Typeable for data families ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by jpm@…): commit 6806906d41581c42805e2f09cc6fda9035a288ef {{{ Author: Jose Pedro Magalhaes <jpm(a)cs.ox.ac.uk> Date: Tue May 21 14:55:36 2013 +0100 Fix #5863 compiler/typecheck/TcDeriv.lhs | 32 ++++++++++++++++++++++++-------- docs/users_guide/glasgow_exts.xml | 3 +++ 2 files changed, 27 insertions(+), 8 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5863#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7914: base library's MD5 symbols clash with others
by GHC 21 May '13

21 May '13

#7914: base library's MD5 symbols clash with others -----------------------------+---------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- We have a large C++ application into which we are linking the GHC runtime. Being large, this app has many components, among which is one that defines a bunch of MD5 functions that have overlapping names with those defined in base, but different ABIs. Depending on the order in which the linker runs across the object files, we end up with a crash during application startup as a result of one component picking up the other component's MD5 symbols. The offending source file is libraries/base/cbits/md5.c. A simple fix for this would be to prefix the function names with e.g. _ghc_ or something similar, so that the names would not clash. There are perhaps other functions in base (probably many others) that could benefit from a similar treatment, but we're not crashing on those yet. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7914> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3