- ghc-tickets - Haskell.org

[GHC] #7707: iOS patch no 6: compatibility with iOS assembler
by GHC 02 Mar '13

02 Mar '13

#7707: iOS patch no 6: compatibility with iOS assembler ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- Small iOS assembler tweaks: the iOS assembler has never heard of the ARM's 'fp' register, and others. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7705: iOS patch no 4: correct options for hsc2hs by stage
by GHC 02 Mar '13

02 Mar '13

#7705: iOS patch no 4: correct options for hsc2hs by stage ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- Currently hsc2hs gets the same options for every stage. We need this refined for iOS. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7705> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7728: ghc-pkg does not build
by GHC 01 Mar '13

01 Mar '13

#7728: ghc-pkg does not build --------------------------------+------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Component: ghc-pkg Version: 7.6.2 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- I am experiencing build errors with HEAD. Steps to reproduce: {{{ git clone http://darcs.haskell.org/ghc.git ghc-working cd ghc-working/ ./sync-all get perl boot ./configure make }}} Build process terminates with an error: {{{ utils/ghc-pkg/Main.hs:881:3: No instance for (Bin.Binary (InstalledPackageInfo_ String)) arising from a use of `writeBinaryFileAtomic' Possible fix: add an instance declaration for (Bin.Binary (InstalledPackageInfo_ String)) In the first argument of `catchIO', namely `writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db))' ... }}} I'm using GHC 7.6.2.20130129 for bootstrapping. I'm stuck with development because of this :/ -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7728> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7708: sys/cpuset.h cannot be found on FreeBSD
by GHC 28 Feb '13

28 Feb '13

#7708: sys/cpuset.h cannot be found on FreeBSD --------------------------------+------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: FreeBSD | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Current "configure.ac" cannot detect "sys/cpuset.h" even if it exists on FreeBSD 9.1: {{{ checking sys/cpuset.h presence... yes configure: WARNING: sys/cpuset.h: present but cannot be compiled configure: WARNING: sys/cpuset.h: check for missing prerequisite headers? configure: WARNING: sys/cpuset.h: see the Autoconf documentation configure: WARNING: sys/cpuset.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/cpuset.h: proceeding with the compiler's result configure: WARNING: ## ----------------------------------------------- ## configure: WARNING: ## Report this to glasgow-haskell-bugs(a)haskell.org ## configure: WARNING: ## ----------------------------------------------- ## checking for sys/cpuset.h... no }}} This is because sys/param.h should be included in the test. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 28 Feb '13

28 Feb '13

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+-------------------------------------------- Reporter: cetinsert | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Keywords: R_X86_64_PC32 | Os: Windows Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by gmainland): I am seeing the same error on Win8 x64 with GHC 7.6.2 (x64). {{{ $ cabal install language-c-quote Resolving dependencies... [1 of 1] Compiling Main ( C:\Users\gmainlan\AppData\Local\Temp\language-c-quote-0.4.4-5516\language-c-quote-0.4.4\Setup.hs, C:\Users\gmainlan\AppData\Local\Temp\language-c-quote-0.4.4-5516\language-c-quote-0.4.4\dist\setup\Main.o ) Linking C:\Users\gmainlan\AppData\Local\Temp\language-c-quote-0.4.4-5516\language-c-quote-0.4.4\dist\setup\setup.exe ... Configuring language-c-quote-0.4.4... Building language-c-quote-0.4.4... Preprocessing library language-c-quote-0.4.4... unused terminals: 4 [ 1 of 15] Compiling Language.C.Syntax ( Language\C\Syntax.hs, dist\build\Language\C\Syntax.o ) [ 2 of 15] Compiling Language.C.Parser.Tokens ( Language\C\Parser\Tokens.hs, dist\build\Language\C\Parser\Tokens.o ) [ 3 of 15] Compiling Language.C.Parser.Monad ( Language\C\Parser\Monad.hs, dist\build\Language\C\Parser\Monad.o ) [ 4 of 15] Compiling Language.C.Parser.Lexer ( dist\build\Language\C\Parser\Lexer.hs, dist\build\Language\C\Parser\Lexer.o ) [ 5 of 15] Compiling Language.C.Pretty ( Language\C\Pretty.hs, dist\build\Language\C\Pretty.o ) [ 6 of 15] Compiling Language.C.Parser.Parser ( dist\build\Language\C\Parser\Parser.hs, dist\build\Language\C\Parser\Parser.o ) [ 7 of 15] Compiling Language.C.Parser ( Language\C\Parser.hs, dist\build\Language\C\Parser.o ) [ 8 of 15] Compiling Language.C.Quote.Base ( Language\C\Quote\Base.hs, dist\build\Language\C\Quote\Base.o ) [ 9 of 15] Compiling Language.C.Quote ( Language\C\Quote.hs, dist\build\Language\C\Quote.o ) [10 of 15] Compiling Language.C.Quote.C ( Language\C\Quote\C.hs, dist\build\Language\C\Quote\C.o ) [11 of 15] Compiling Language.C.Smart ( Language\C\Smart.hs, dist\build\Language\C\Smart.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package syb-0.3.7 ... linking ... done. Loading package symbol-0.1.4 ... linking ... done. Loading package srcloc-0.3.0 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package text-0.11.2.3 ... linking ... done. Loading package mainland-pretty-0.2.5 ... linking ... done. Loading package Win32-2.3.0.0 ... linking ... ghc.exe: internal error: R_X86_64_PC32: High bits are set in 7fcaf075d29 for DefDlgProcW (GHC version 7.6.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Failed to install language-c-quote-0.4.4 cabal.exe: Error: some packages failed to install: language-c-quote-0.4.4 failed during the building phase. The exception was: ExitFailure 3 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7134#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7671: No break spaces
by GHC 26 Feb '13

26 Feb '13

#7671: No break spaces -----------------------------+---------------------------------------------- Reporter: zenzike | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I thought I was going mad when the following code wasn't compiling: {{{ {-# LANGUAGE UnicodeSyntax #-} {-# LANGUAGE RankNTypes #-} type F f = forall x . f x }}} GHC was producing the following error message: {{{ mad.hs:4:21 Illegal symbol '.' in type Perhaps you intended -XRankNTypes or similar flag to enable explicit-forall syntax: forall <tvs>. <type> }}} It turns out that I had somehow inserted a unicode no break space, character code `U+00a0`, in the line importing RankNTypes, just after the first `#`. Baffling. This begs the question: should GHC treat this unicode space as an ordinary space when the `UnicodeSyntax` extension is enabled? If not should there have been some warning that I had inserted this symbol in a language pragma? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 25 Feb '13

25 Feb '13

#6084: Add stg_ap_pnnv and related call patterns ---------------------------------+------------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Yes the extra call patterns take up RTS code space, but that's an extremely minor matter -- and they do a good job for under and over- saturated calls as well as exactly-saturated ones. I'm all for your fix in addition, for the case where there is no RTS pattern. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6084#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 25 Feb '13

25 Feb '13

#6084: Add stg_ap_pnnv and related call patterns ---------------------------------+------------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): I don't think they're orthogonal: both ways avoid building the intermediate PAP(s). The tradeoffs are: * with extra call patterns, we have to predict which patterns we need, and we can easily get it wrong (e.g. we're talking here about needing `ppnnnv`, which is quite obscure) * extra call patterns take up static code space in the RTS whether we use them or not. * Generating the saturation check at the call site means extra code, but it works for any pattern, and you don't pay for it if you don't need it (the case in the codegen was not triggered at all in nofib, and was only triggered once in the codeGen tests, unless I did something wrong). The short-cut isn't the same as generating a fresh slow-call pattern at the call site. It only does the saturation check, and delegates everything else to the existing slow call patterns. I think it should be exactly what's needed in these cases, but I'd like to see some benchmarks. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6084#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5391: Better deriving for Typeable
by GHC 25 Feb '13

25 Feb '13

#5391: Better deriving for Typeable -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Yes, the polykinded Typeable is strictly better than the compromise offered here. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5391#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0