May 2013 - ghc-tickets

[GHC] #7840: Abort and Seg fault on Mac OS X
by GHC 10 May '13

10 May '13

#7840: Abort and Seg fault on Mac OS X -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.4.2 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------+---------------------------------------------------- Actually this is 3 bugs ghci often segfaults on startup... rerunning usually gets to the Prelude> prompt. : dt ; ghci GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Segmentation fault I just got this one today: : dt ; ghci GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ghc: internal error: evacuate: strange closure type 0 (GHC version 7.4.2 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap 3rd problem is that it has crashed my *SYSTEM* twice... forcing a power- cycle. Have reported it to Apple as they requests. This is Snowleopard dmason(a)ryerson.ca if you want to contact me -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7840> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7814: panic in PPC NCG
by GHC 10 May '13

10 May '13

#7814: panic in PPC NCG --------------------------------+------------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- I get panics in the NCG PPC register allocator while compiling these files: rts_dist_HC rts/dist/build/StgStdThunks.dyn_o rts_dist_HC rts/dist/build/StgStdThunks.thr_dyn_o rts_dist_HC rts/dist/build/StgStdThunks.l_dyn_o rts_dist_HC rts/dist/build/StgStdThunks.thr_l_dyn_o HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Classes.o HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/CString.o HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o The panic message is like this: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20130405 for powerpc-montavista-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_nff }}} This makes the bootstapping of PPC cross compiler, ehm, delicate. There is a comment in compiler/nativeGen/RegAlloc/Linear/Main.hs:756 Nothing | reading -> pprPanic "allocateRegsAndSpill: Cannot read from uninitialized register" (ppr r) -- NOTE: if the input to the NCG contains some -- unreachable blocks with junk code, this panic -- might be triggered. Make sure you only feed -- sensible code into the NCG. In CmmPipeline we -- call removeUnreachableBlocks at the end for this -- reason. So we have a 'junk code' issue here. Any hints how I can debug this? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

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

10 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 10 May '13

10 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 10 May '13

10 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 09 May '13

09 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