- ghc-tickets - Haskell.org

[GHC] #7988: Big integers crashing integer-simple on qnxnto-arm
by GHC 28 Jun '13

28 Jun '13

#7988: Big integers crashing integer-simple on qnxnto-arm --------------------------+------------------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: QNX | Architecture: arm Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- The following program gives a SIGSEGV when run on qnxnto-arm (my Blackberry Z10 running OS10.1, to be exact) after being compiled by my cross-compiler. Initial investigation shows that compiling a non-cross-compiler for i486 that uses integer-simple does *not* crash on the same program, so it's not a fundamental issue with integer-simple (unless the bug has been fixed between the version of source my cross-compiler uses and HEAD, which I have not yet tested because I'm not sure how to build HEAD to make a good- style statically-linking-libraries GHC). {{{ module Main(main) where main::IO() main=print 169821641172389640937095636777672117931888945045504182713271897430274187839083732143233634367563316254925040331580602942790529924419031237257992694047545188803054325440702792009735658578224936744314329623399862853427161588994478038000957583036049445212750560294647972107700330648403394932373528288706138101730866129542001812796094504052779945357555018210304989340497464935845180607042646690920787035715174921382511732745931975718868480005317353569848454618331425749699355019762926384123909468814180690222898222556785716853422930906736084397064171894642825018414586574929919999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7939: RHS of associated type not kind-checked
by GHC 28 Jun '13

28 Jun '13

#7939: RHS of associated type not kind-checked ----------------------------------------+----------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- The following code compiles without complaint: {{{ {-# LANGUAGE TypeFamilies, PolyKinds #-} class Foo a where type Bar a instance Foo Int where type Bar Int = Maybe instance Foo Bool where type Bar Bool = Double }}} We can see here that {{{Bar}}} is ill-kinded. When I try {{{:k Bar}}} in GHCi, I get an assertion failure, not unexpectedly. I will fix in ongoing work. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 15

[GHC] #8017: Empty instance
by GHC 27 Jun '13

27 Jun '13

#8017: Empty instance -----------------------+---------------------------------------------------- Reporter: wvv | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.6.3 | Keywords: Os: Windows | Architecture: x86 Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------+---------------------------------------------------- Progam {{{ module T1 where data T = T1 | T2 instance Eq T t :: T -> T -> Bool t = (==) }}} use ghci (Windows XP, 32 bit) {{{ GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :cd M:\Haskell Prelude> :load "T1.hs" [1 of 1] Compiling T1 ( T1.hs, interpreted ) Ok, modules loaded: T1. *T1> t T1 T2 *** Exception: stack overflow *T1> }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8017> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8016: case expression with mixed use of Num instances cause spurious overlap warning
by GHC 27 Jun '13

27 Jun '13

#8016: case expression with mixed use of Num instances cause spurious overlap warning ----------------------------------------------+----------------------------- Reporter: bscarlet | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: case overlap Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- {{{ newtype Whomp = Whomp Int deriving (Eq) instance Num Whomp where Whomp a + Whomp b = Whomp (a+b) Whomp a * Whomp b = Whomp (a*b) abs (Whomp a) = Whomp (abs a) signum (Whomp a) = Whomp (signum a) fromInteger = Whomp . fromInteger foo :: Whomp -> String foo cc = case cc of Whomp 0 -> "zero" 10 -> "ten" }}} produces {{{ Foo.hs:12:10: Warning: Pattern match(es) are overlapped In a case alternative: Whomp 0 -> ... }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5687: Friendly Interface for auto-completion of GHCi
by GHC 27 Jun '13

27 Jun '13

#5687: Friendly Interface for auto-completion of GHCi -------------------------------+-------------------------------------------- Reporter: linsumang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.2.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by hvr): @igloo: I've got a nicely working proof of concept implementation for Emacs (see http://youtu.be/06q-sCoqwEY for a short screencast demonstration). Implementing complete Read/Show serialization for strings wasn't that hard in Elisp, and the standard case, when no escaping is needed has a cheap code path. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5687#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7017: Rethink need for tarballs under "friendly" environment
by GHC 27 Jun '13

27 Jun '13

#7017: Rethink need for tarballs under "friendly" environment ---------------------------------+------------------------------------------ Reporter: FUZxxl | Owner: Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.4.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by nomeata): * cc: mail@… (added) Comment: I was just made aware of the tarballs with binary code in the “source” tarball. Theoretically, for Debian either the source of that code needs to be included as well, or the binaries removed. As we use none of the data in `ghc-tarballs`, we’d greatly appreciate a second tarball that contains just the GHC sources, and no third-party modules. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7017#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7902: Add support for byte endianness swapping exposed as a primops
by GHC 27 Jun '13

27 Jun '13

#7902: Add support for byte endianness swapping exposed as a primops -----------------------------+---------------------------------------------- Reporter: tab | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: bswap endianness Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Add support for W32 and W64 endianness swapping as a new primops (bSwap32# and bSwap64#), supported by code generator change in llvm and ncg to generate efficient code (i.e. X86's bswap instruction support). For other NCG architectures (powerpc, sparc) provide support by 2 ghc-prim C functions. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7902> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 20

[GHC] #8015: GHC is inconsistent about where LANGUAGE is unsupported.
by GHC 26 Jun '13

26 Jun '13

#8015: GHC is inconsistent about where LANGUAGE is unsupported. ----------------------------------------+----------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: parser Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Consider the following file: {{{ {-# LANGUAGE NOINLINE foo bar #-} module Main where main :: IO () main = return () }}} We'd expect this error to occur: {{{ $ ~/ghc/ghc-work/inplace/bin/ghc-stage2 --interactive /tmp/tester.hs GHCi, version 7.7.20130624: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. /tmp/tester.hs:1:14: Unsupported extension: NOINLINE Failed, modules loaded: none. Prelude> }}} Now consider: {{{ module Main where {-# LANGUAGE NOINLINE foo bar #-} main :: IO () main = return () }}} And: {{{ ~/ghc/ghc-work/inplace/bin/ghc-stage2 --interactive /tmp/tester.hs GHCi, version 7.7.20130624: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( /tmp/tester.hs, interpreted ) Ok, modules loaded: Main. *Main> }}} Something like this actually slipped into base and was fixed. See Gabor's commit 100c051 which fixed it. I was going to attempt to fix this myself but I (probably rightly) backed away a little as I understand the code more. This ticket can keep track of it, regardless of who fixes it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2110: Rules to eliminate casted id's
by GHC 26 Jun '13

26 Jun '13

#2110: Rules to eliminate casted id's ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nomeata): Oh well, merged everything into NewtypeWrappers. Should have searched first before typing away. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2110#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8014: Assertion failure when using multithreading in debug mode.
by GHC 26 Jun '13

26 Jun '13

#8014: Assertion failure when using multithreading in debug mode. -----------------------------+---------------------------------------------- Reporter: Maxander | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: x86 Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Using the -debug compiler option in search of a (hopefully unrelated) bug, I've begun to receive the following error message a few seconds after starting my program; {{{ Multi: internal error: ASSERTION FAILED: file rts/Schedule.c, line 1311 (GHC version 7.6.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} When I have time and if this site allows, I'll try to find what precisely in my code is generating the error and add that to this ticket. Until then, what information I can give: - Running the same executable in non-threaded mode (executing with "+RTS N1" rather than "+RTS N2" or greater) produces no error. - The program calls into C using the FFI interface, and there is also a callback from C back into Haskell. This would be happening around when the error occurs. - For reasons I presume to have to do with the C++ code, the program segfaults after extended execution; this is the hopefully unrelated bug I was after when I found this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0