April 2013 - ghc-tickets

[GHC] #7871: 7.6.3 failed to build with make -j12
by GHC 10 May '13

10 May '13

#7871: 7.6.3 failed to build with make -j12 --------------------------------+------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- This looks to be a missing dependency in the build system: {{{ HC [stage 1] compiler/stage2/build/TcSplice.o-boot HC [stage 1] compiler/stage2/build/CodeOutput.o HC [stage 1] compiler/stage2/build/RnHsDoc.o HC [stage 1] compiler/stage2/build/RnExpr.o-boot HC [stage 1] compiler/stage2/build/TcExpr.o-boot HC [stage 1] compiler/stage2/build/TcUnify.o-boot HC [stage 1] compiler/stage2/build/TcMatches.o-boot HC [stage 1] compiler/stage2/build/FloatIn.o HC [stage 1] libraries/bin-package-db/dist-install/build/libHSbin- package-db-0.0.0.0-ghc7.6.3.so Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. HC [stage 1] libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Haddock.p_o HC [stage 1] compiler/stage2/build/Rules.p_o HC [stage 1] compiler/stage2/build/HsExpr.p_o /usr/bin/ld: cannot find -lHSbin-package-db-0.0.0.0-ghc7.6.3 collect2: ld returned 1 exit status make[1]: *** [compiler/stage2/build/libHSghc-7.6.3-ghc7.6.3.so] Error 1 make[1]: *** Waiting for unfinished jobs.... "rm" -f libraries/haskeline/dist- install/build/libHShaskeline-0.7.0.2.a.contents "rm" -f libraries/haskeline/dist- install/build/libHShaskeline-0.7.0.2_p.a.contents "rm" -f libraries/Cabal/Cabal/dist- install/build/libHSCabal-1.16.0.a.contents make: *** [all] Error 2 }}} Re-running make without a -j option after this failure completes successfully. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7855: Use optimizer for more information about incomplete pattern matches
by GHC 10 May '13

10 May '13

#7855: Use optimizer for more information about incomplete pattern matches -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This mail gave me an idea that was too cute not to write down (though I don't expect it to be implemented any time soon), http://www.haskell.org/pipermail/haskell-cafe/2013-April/107775.html The observation is that the typechecking phase is not necessarily the best point in time to check for pattern coverage exhaustiveness: if we tentatively stub in a default case with an error, and after optimization passes, we find that this case has been eliminated, then in fact there was no pattern coverage incompleteness. So, the strategy would be to defer reporting certain coverage failures until we can do actually check if there are any problems later. Obviously if no predicates or view patterns (or similar things) are involved, then there is no point in attempting to defer it, but otherwise this could help reduce warnings in code that make heavy use of these features. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7855> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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

[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] #7839: After forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: failed (Operation not supported)"
by GHC 07 May '13

07 May '13

#7839: After forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: failed (Operation not supported)" ----------------------------------------+----------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: MacOS X | Architecture: x86 Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Investigating #7715 on the tn23 builder, which is {{{ $ uname -a Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 $ }}} I ran into: {{{ $ cat T7715O.hs import Control.Monad import Control.Concurrent import System.IO import System.Environment main' c d2 = do replicateM_ c $ forkIO $ do putStrLn "Hello, world!" threadDelay d2 mainArgsInterpret [cS,d2S] = main' (read cS) (read d2S) main :: IO () main = do hSetBuffering stdout NoBuffering hSetBuffering stderr NoBuffering args <- getArgs mainArgsInterpret args $ /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/inplace/bin /ghc-stage2 --make T7715O.hs -threaded -debug -rtsopts [1 of 1] Compiling Main ( T7715O.hs, T7715O.o ) Linking T7715O ... $ ./T7715O 25 10000000 Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! Hello, world! HeT7715O: <stdout>: hPutChar: failed (Operation not supported) T7715O: <stdout>: hPutChar: failed (Operation not supported) $ }}} This doesn't happen on {{{ $ uname -a Linux tn24 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux $ }}} Best regards Thorkil -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7773: Waiting on non-kqueue supported files on OS X
by GHC 06 May '13

06 May '13

#7773: Waiting on non-kqueue supported files on OS X ----------------------------------------+----------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Neither the old IO manager nor the new "parallel" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000798.html. Here is the gist of it: the IO manager uses kqueue to wait on files on OS X. kqueue does not support all files. For example, on older versions of OS X (10.5.8) it cannot wait on tty devices and on even on 10.8.2 it cannot wait on /dev/random. Both the old and parallel IO managers suffered from the problem, but the consequences were slightly different. With the old IO manager the situation was treated as the file being ready, which would just cause the waiting thread to run again. The parallel IO manager changed things slightly and now it just throws an exception and terminates the program. So the behavior when this happens in the parallel IO manager is not acceptable. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #7870: Compilation errors break the complexity encapsulation on DSLs, impairs success in industry
by GHC 05 May '13

05 May '13

#7870: Compilation errors break the complexity encapsulation on DSLs, impairs success in industry -----------------------------+---------------------------------------------- Reporter: agocorona | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: DSL, Error, Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- From the paper "Scripting the Type Inference Process" -Bastiaan Heeren Jurriaan Hage S. Doaitse Swierstra: ... Combinator languages are a means of deﬁning domain speciﬁc languages embedded within an existing programming language, using the abstraction facilities present in the latter. However, since the domain speciﬁc extensions are mapped to constructs present in the underlying language, all type errors are reported in terms of the host language, and not in terms of concepts from the combinator library. In addition, the developer of a combinator library may be aware of various mistakes which users of the library can make, something which he can explain in the documentation for the library, but which he cannot make part of the library itself. ...As a result, the beginning programmer is likely to be discouraged from pro-gramming in a functional language, and may see the rejection of programs as a nuisance instead of a blessing. The experienced user might not look at the messages at all. Definitively this is probably the biggest barrier for the acceptance of Haskell on Industry. We need to start with something not as sophisticated as the Helium paper "Scripting the Type Inference Process", but maybe a partial implementation of the techniques mentioned, so that the development can be enhanced in the future. Maybe some kind of library that permits postprocessing of GHC errors and/or the identification of points in the current type checker where some kind of rules can be defined by the programmer can be the first step. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7684: cgrun071 segfaults
by GHC 03 May '13

03 May '13

#7684: cgrun071 segfaults --------------------------+------------------------------------------------- Reporter: tibbe | Owner: tibbe Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I ran into this working on something unrelated today: {{{ =====> cgrun071(normal) 171 of 3449 [0, 0, 12] cd ./codeGen/should_run && '/Users/tibbe/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o cgrun071 cgrun071.hs >cgrun071.comp.stderr 2>&1 cd ./codeGen/should_run && ./cgrun071 </dev/null >cgrun071.run.stdout 2>cgrun071.run.stderr /bin/sh: line 1: 37450 Segmentation fault: 11 ./cgrun071 < /dev/null > cgrun071.run.stdout 2> cgrun071.run.stderr Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: *** unexpected failure for cgrun071(normal) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 03 May '13

03 May '13

#7854: Constrained method type accepted in Haskell 98 mode -----------------------------+---------------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- If I understand [http://www.haskell.org/ghc/docs/7.6.2/html/users_guide /type-class-extensions.html#class-method-types this paragraph] of the GHC manual correctly, the following code should be rejected in Haskell 98 mode: {{{ {-# LANGUAGE Haskell98 #-} module Main where class Compare a where comp :: Eq a => a -> a -> Bool }}} However, it compiles fine for me both with 7.4.2 and 7.6.1. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4