- ghc-tickets - Haskell.org

Re: [GHC] #7316: GHC segfaults on ARM
by GHC 11 May '13

11 May '13

#7316: GHC segfaults on ARM -------------------------+-------------------------------------------------- Reporter: laney | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.4.2 Keywords: | Os: Unknown/Multiple Architecture: arm | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 3658 | Blocking: 7623 Related: | -------------------------+-------------------------------------------------- Changes (by igloo): * blockedby: => 3658 Comment: This should be fixed by using dynamic libraries to implement GHCi. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7316#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7373: When building GHC: Failed to load interface for `GHC.Fingerprint'
by GHC 11 May '13

11 May '13

#7373: When building GHC: Failed to load interface for `GHC.Fingerprint' -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: T7373 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * testcase: => T7373 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7373#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7373: When building GHC: Failed to load interface for `GHC.Fingerprint'
by GHC 11 May '13

11 May '13

#7373: When building GHC: Failed to load interface for `GHC.Fingerprint' -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by igloo): I've added a test `T7373` which shows what is going on. Currently it fails with: {{{ +/home/ian/ghc/git/ghc/testsuite/tests/driver/T7373/pkg/dist/build/C.hi +Declaration for mkTyConApp +Unfolding of C.mkTyConApp: + Failed to load interface for ‛B’ + There are files missing in the ‛pkg-0’ package, + try running 'ghc-pkg check'. + Use -v to see a list of the files searched for. }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7373#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5925: Add inline version of newArray#
by GHC 10 May '13

10 May '13

#5925: Add inline version of newArray# ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | 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: 4258 | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Replying to [comment:9 tibbe]: > For the known case you say I should "compile those directly", but I have no idea what that actually means. Behave just like `StgCmmHeap.allocDynClosure`. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5925#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5925: Add inline version of newArray#
by GHC 10 May '13

10 May '13

#5925: Add inline version of newArray# ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | 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: 4258 | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by tibbe): My use case looks something like: {{{ f c = case c of C1 -> newArray# <known small size> C2 -> newArray# <unknown small size> }}} Simon M, will the unknown small size case work in the implementation you suggest (i.e. spot the known case and hoist its heap check to the top of `f`)? For the known case you say I should "compile those directly", but I have no idea what that actually means. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5925#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5925: Add inline version of newArray#
by GHC 10 May '13

10 May '13

#5925: Add inline version of newArray# ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | 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: 4258 | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): I agree with Simon. What I'd do here is look for a `newArray#` applied to a compile-time constant within a certain range (probably less than 1KB or so), and compile those directly. There's no need to generate a heap check, the heap allocation will be automatically aggregated into the enclosing context and included in the heap check at the enclosing function or case alternative. For arrays of unknown size you could make a call to the out-of-line `allocate()` function to allocate the memory for the array, and then just inline the code for the `newArray#` primop, heap check and all. It's not at all clear that this would ever be worth doing though. I'd go for optimising the known-small-size case only. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5925#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7874: segfault 11 on mac os x when building compiler for ghc 7.7.20130430
by GHC 10 May '13

10 May '13

#7874: segfault 11 on mac os x when building compiler for ghc 7.7.20130430 --------------------------------+------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- I'm trying to build ghc head from the repo head as of today, and i'm getting the following error in the stage 2 build carter repoScratcher/ghc ‹master› » make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fllvm -package-name old-time-1.1.0.1 -hide-all-packages -i -ilibraries /old-time/. -ilibraries/old-time/dist-install/build -ilibraries/old-time /dist-install/build/autogen -Ilibraries/old-time/dist-install/build -Ilibraries/old-time/dist-install/build/autogen -Ilibraries/old- time/include -optP-include -optPlibraries/old-time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package old- locale-1.0.0.5 -XHaskell98 -XCPP -XForeignFunctionInterface -O -fllvm -no-user-package-db -rtsopts -odir libraries/old-time/dist- install/build -hidir libraries/old-time/dist-install/build -stubdir libraries/old-time/dist-install/build -dynamic-too -c libraries/old-time /dist-install/build/System/Time.hs -o libraries/old-time/dist- install/build/System/Time.o -dyno libraries/old-time/dist- install/build/System/Time.dyn_o make[1]: *** [libraries/old-time/dist-install/build/System/Time.o] Segmentation fault: 11 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7874> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #7901: Bad error message when using UnicodeSyntax ∀ without ExplicitForall
by GHC 10 May '13

10 May '13

#7901: Bad error message when using UnicodeSyntax ∀ without ExplicitForall ----------------------------------------------+----------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- This code {{{ {-# LANGUAGE UnicodeSyntax #-} id' :: ∀ a. a → a id' a = a }}} produces following error {{{ /tmp/id.hs:4:8: parse error on input `∀' }}} However, equivalent code without unicode syntax gives a much better error message: {{{ id' :: forall a. a → a id' a = a }}} {{{ /tmp/id.hs:4:16: Illegal symbol '.' in type Perhaps you intended -XRankNTypes or similar flag to enable explicit-forall syntax: forall <tvs>. <type> }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7476: -ddump-minimal-imports confused if first line is an import
by GHC 09 May '13

09 May '13

#7476: -ddump-minimal-imports confused if first line is an import ------------------------------------------+--------------------------------- Reporter: dag | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: parser/should_compile/T7476 | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by simonpj): * testcase: => parser/should_compile/T7476 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7476#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7899: Strange behavior of -ddump-minimal-imports
by GHC 09 May '13

09 May '13

#7899: Strange behavior of -ddump-minimal-imports ----------------------------------------+----------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- The following two line module: {{{ import System.Exit main = undefined >>= undefined }}} when compiled with {{{ghc -c -ddump-minimal-imports Test.hs}}} produces the following in Main.imports: {{{ import System.Exit ( (>>=), undefined ) }}} Those symbols are not exported by System.Exit. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1