- ghc-tickets - Haskell.org

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

[GHC] #7909: GHC doesn't respect -optl and -optc in a couple of places
by GHC 21 May '13

21 May '13

#7909: GHC doesn't respect -optl and -optc in a couple of places ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ A legitimate use of `-optl` and `-optc` is to pass options that should ''always'' be passed to gcc, such as `-B<something>` if we're invoking `gcc` against a particular set of libraries. For this to work, we have to ensure that `-optl` and `-optc` options are always passed. In `joinObjectFiles`, we don't add the options from `-optl`. I suspect that we don't want to just add them, because we also put the `-l` options in this list, so we should separate the two. In `mkExtraObj`, we don't add the options from `-optc`. Probably we should refactor things so that these options are automatically added by `SysTools.runCc` and friends, being careful about option ordering. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7907: patch to make comment about stgclosure struct more accurate
by GHC 21 May '13

21 May '13

#7907: patch to make comment about stgclosure struct more accurate ------------------------------+--------------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- I've been digging into the rts code to understand function application etc, and the current comment about where StgClosure is defined is wrong. theres a patch fix it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3