June 2013 - ghc-tickets

[GHC] #8021: Multiple constraint classes - the alternative to superclass
by GHC 07 Jul '13

07 Jul '13

#8021: Multiple constraint classes - the alternative to superclass -----------------------------+---------------------------------------------- Reporter: wvv | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This is alternative to SuperClasses - multiple constraint Classes Now: {{{ class Monoid a where ... class Monad m => MonadPlus m where ... }}} It could be: {{{ class Monoid a where ... class Monad m => Monoid m where ... class Arrow c => Monoid c where ... foo :: Monad m => Monoid m => m a }}} all classes must have same functions with same kind. And if you wish to write superclass, it would be easy to write {{{ class BeforeNum a where .... class BeforeNum a => Num a where ... foo :: BeforeNum a => Num a => a }}} '''Backward compatibility''' If class have single constraint, you could write without it. If class have many constrains, you could write without it, if it is empty one. {{{ bar :: MonadPlus m => m a <<==>> bar :: Monad m => MonadPlus m => m a foo :: Monoid a => a <<==>> foo :: () => Monoid a => a }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7574: Register allocator chokes on certain branches with literals
by GHC 05 Jul '13

05 Jul '13

#7574: Register allocator chokes on certain branches with literals -----------------------------+---------------------------------------------- Reporter: thoughtpolice | 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: 7571, 7573 -----------------------------+---------------------------------------------- While running the test for #7571 (test is in #7573,) under '''WAY=normal''' instead of '''WAY=llvm''', I encountered this bug in the native backend: {{{ =====> T7571(normal) 6 of 6 [0, 0, 0] cd . && '/Users/a/code/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -no-hs-main >T7571.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130113 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c7 }}} The test in question is: {{{ #include "Cmm.h" testLiteralBranch (W_ dst, W_ src) { if (1) { prim %memcpy(dst, src, 1024, 4); } else { prim %memcpy(dst, src, 512, 8); } return (); } }}} If you comment out the branch conditionals, the test passes, so clearly something fishy is going on here. The test also fails if you change the condition to ```if (1 == 1)``` I have absolutely no idea how this did not trip the profiling-based build in StgStdThunks.cmm, like in the LLVM build c.f. #7571 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

[GHC] #7940: Building GHC 7.7.20130526 for Windows x86_64 fails with Cmm lint error
by GHC 03 Jul '13

03 Jul '13

#7940: Building GHC 7.7.20130526 for Windows x86_64 fails with Cmm lint error --------------------------------+------------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Windows | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Building GHC 7.7.20130526 for Windows x86_64 fails with the following error: {{{ "inplace/bin/ghc-stage1.exe" -static -optc-DDEBUG -ticky -DTICKY_TICKY -O -H256m -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0 -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.debug_o Cmm lint error: in basic block cf in MachOp application: I32[ALLOC_PRIM_adm] + (8 + 8) op is expecting: [W32, W32] arguments provide: [I32, I64] Program was: {offset cc: _cd::I64 = R1; if (I64[CurrentNursery + 16] == 0) goto cg; else goto ci; ci: if (I64[I64[g0] + 56] >= %MO_SS_Conv_W32_W64(I32[large_alloc_lim])) goto cg; else goto ch; cg: HpAlloc = 0; R9 = stg_newByteArrayzh; R1 = _cd::I64; call stg_gc_prim_n(R1) args: 8, res: 0, upd: 8; ch: _cj::I64 = (_cd::I64 + 8 - 1) / 8; _cn::I64 = (8 + 8) / 8 + _cj::I64; _cm::I64 = allocate; _cl::I64 = BaseReg - 24; _ck::I64 = _cn::I64; (_ce::P64) = call "ccall" arg hints: [PtrHint,] result hints: [PtrHint] (_cm::I64)(_cl::I64, _ck::I64); I32[ALLOC_PRIM_ctr] = I32[ALLOC_PRIM_ctr] + 1 :: W32; I32[ALLOC_PRIM_adm] = I32[ALLOC_PRIM_adm] + (8 + 8); I32[ALLOC_PRIM_gds] = I32[ALLOC_PRIM_gds] + _cj::I64 * 8; I32[ALLOC_PRIM_slp] = I32[ALLOC_PRIM_slp] + 0; I64[_ce::P64] = stg_ARR_WORDS_info; I64[_ce::P64 + 8 + 0] = _cd::I64; R1 = _ce::P64; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; } <no location info>: Compilation had errors }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 7

[GHC] #7970: Thread GC frees roots before thread actually finishes
by GHC 03 Jul '13

03 Jul '13

#7970: Thread GC frees roots before thread actually finishes -----------------------------+---------------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: 7170 -----------------------------+---------------------------------------------- In the following program, an IORef is garbage collected after a `NonTermination` exception, but is subsequently accessed: {{{ import Control.Exception as E import Data.IORef import System.Mem.Weak main :: IO () main = do ref <- newIORef 'x' weak <- mkWeakIORef ref $ putStrLn "IORef finalized" let check = deRefWeak weak >>= \m -> case m of Nothing -> putStrLn "IORef was GCed" Just ref' -> do x <- readIORef ref' putStrLn $ "IORef still alive, and contains " ++ show x let loop = loop check loop `catch` \ex -> do putStrLn $ "caught exception: " ++ show (ex :: SomeException) check readIORef ref >>= print }}} Output: {{{ IORef still alive, and contains 'x' IORef finalized caught exception: <<loop>> IORef was GCed 'x' }}} The same happens with other thread deadlocks, such as: * newEmptyMVar >>= takeMVar * atomically retry It does not happen when a `StackOverflow` or `UserInterrupt` exception is caught. This also affects `ForeignPtr`; see the attached "database" example. This is what really triggered #7170. I marked this "Runtime crash" because it can lead to a `ForeignPtr` being accessed after the garbage collector finalized it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 02 Jul '13

02 Jul '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -----------------------------+---------------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The section 4.8 of 'The Glorious Glasgow Haskell Compilation System User's Guide, Version 7.6.3' says: {{{-fwarn-lazy-unlifted-bindings:}}} ... This will be an error, rather than a warning, in GHC 7.2. I guess the above sentence should be removed. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7979: ./configure script does not properly detect missing header files
by GHC 02 Jul '13

02 Jul '13

#7979: ./configure script does not properly detect missing header files -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I was trying to compile GHC on a fresh installation of Debian Wheezy and I got this compilation error: {{{ CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/dane/download/ghc-7.6.3/inplace/bin/ghc-stage1" --with-ghc-pkg="[9/1856] wnload/ghc-7.6.3/inplace/bin/ghc-pkg" --enable-library-profiling --enable-shared --enable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" --with-alex="/usr /bin/alex" --with-happy="/usr/bin/happy" -- dist-install libraries/terminfo Configuring terminfo-0.3.2.4... configure: WARNING: unrecognized options: --with-compiler, --with-gcc checking for gcc... /usr/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking how to run the C preprocessor... /usr/bin/gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking curses.h usability... no checking curses.h presence... no checking for curses.h... no configure: error: in `/dane/download/ghc-7.6.3/libraries/terminfo': configure: error: curses headers could not be found, so this package cannot be built See `config.log' for more details make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 }}} Which means that `./configure` did not detect that ncurses header files are missing from the system. I think that in this situation `./configure` should fail and inform the user that required header files are missing. Also, I noticed that when Alex and Happy are missing from the system then `./configure` will also not complain. I admit I didn't try to build with these two binaries missing, but I suspect that building would fail. If so, then `./configure` script should also fail in this situation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7979> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #7830: Error: operand out of range
by GHC 02 Jul '13

02 Jul '13

#7830: Error: operand out of range ----------------------------------+----------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Installing GHC failed | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Compiling on linux-powerpc and linux-powerpc64 I get: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall \ -H64m -O0 -package-name time-1.4.0.2 -hide-all-packages -i -ilibraries/time/. \ -ilibraries/time/dist-install/build -ilibraries/time/dist- install/build/autogen \ -Ilibraries/time/dist-install/build -Ilibraries/time/dist- install/build/autogen \ -Ilibraries/time/include -optP-DLANGUAGE_Rank2Types -optP \ DLANGUAGE_DeriveDataTypeable -optP-DLANGUAGE_StandaloneDeriving -optP- include \ -optPlibraries/time/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 \ -package deepseq-1.3.0.2 -package old-locale-1.0.0.5 -Wall -XHaskell2010 -XRank2Types \ -XDeriveDataTypeable -XStandaloneDeriving -XCPP -O2 -O -dcore-lint \ -fno-warndeprecated-flags -no-user-package-db -rtsopts -fno-warn- unused-do-bind \ -fno-warn-deprecations -fno-warn-unused-imports -fno-warn-identities -odir \ libraries/time/dist-install/build -hidir libraries/time/dist- install/build -stubdir \ libraries/time/dist-install/build -dynamic-too -c libraries/time/./Data/Time/Format.hs \ -o libraries/time/dist-install/build/Data/Time/Format.o -dyno \ libraries/time/dist-install/build/Data/Time/Format.dyn_o /tmp/ghc2806_0/ghc2806_1.s: Assembler messages: /tmp/ghc2806_0/ghc2806_1.s:51766:0: Error: operand out of range (0x000000000000adf8 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghc2806_0/ghc2806_1.s:51798:0: Error: operand out of range (0x000000000000ad90 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghc2806_0/ghc2806_1.s:51830:0: Error: operand out of range (0x000000000000ad28 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghc2806_0/ghc2806_1.s:51908:0: Error: operand out of range (0x000000000000ac1c is not between 0xffffffffffff8000 and 0x0000000000007fff) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 11

[GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved
by GHC 01 Jul '13

01 Jul '13

#8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved ----------------------------------------------+----------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.3 | Keywords: Os: MacOS X | Architecture: x86 Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- Building the included project with {{{ cabal configure && cabal build --ghc-options="-fforce-recomp -Wall -fno- code" }}} results in the following typechecker error: {{{ ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: supabugzm0zi1zi0_A_makeLenseszq_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8024: Illegal instruction in cr_str
by GHC 30 Jun '13

30 Jun '13

#8024: Illegal instruction in cr_str --------------------------------+------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- During the process of coming up for a fix for ticket #7830 (which left GHC un-buildable for many months) I ran into this problem. After coming up with a fix for #7830 I ran into this problem where the first executable (compiled with the stage1 compiler) to run crashes with an illegal instruction: {{{ (gdb) bt #0 0x0f3f2e24 in cr_str () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #1 0x0f3de490 in stg_catchzh () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #2 0x0f3cc01c in scheduleWaitThread () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #3 0x0f3c63dc in rts_evalLazyIO () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #4 0x0f3c8300 in hs_main () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #5 0x10006ae4 in main () }}} Disassmbling the function gives: {{{ Dump of assembler code for function cr_str: 0x0f3f2dec: rlwimi r1,r2,10,0,16 0x0f3f2df0: xoris r2,r27,27237 0x0f3f2df4: ori r20,r27,8293 0x0f3f2df8: xoris r20,r19,25970 0x0f3f2dfc: oris r4,r11,8448 0x0f3f2e00: .long 0xfffeae2c 0x0f3f2e04: .long 0xfffeae2c 0x0f3f2e08: .long 0xfffeae2c 0x0f3f2e0c: .long 0xfffeae2c 0x0f3f2e10: .long 0xfffeae2c 0x0f3f2e14: .long 0xfffeae2c 0x0f3f2e18: .long 0xfffeae2c 0x0f3f2e1c: .long 0xfffeae2c 0x0f3f2e20: .long 0xfffeae2c => 0x0f3f2e24: .long 0xfffeae20 0x0f3f2e28: .long 0xfffeae20 0x0f3f2e2c: .long 0xfffeae20 0x0f3f2e30: .long 0xfffeae20 }}} However function stg_catchzh() in rts/Exception.cmm does not call cr_str(). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7647: UNPACK polymorphic fields
by GHC 30 Jun '13

30 Jun '13

#7647: UNPACK polymorphic fields ------------------------------------+--------------------------------------- Reporter: liyang | Owner: simonpj Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: 3990 ------------------------------------+--------------------------------------- comment:9:ticket:3990 mentions the possibility of unpacking polymorphic fields. To quote: […] What I mean by "polymorphic unpack" is this: {{{ data Poly a = MkP Bool {-# UNPACK #-} a data Mango = MkMango {-# UNPACK #-} (Poly Int) }}} Now a value of type Poly t would be represented using two pointer fields, as usual (ie the UNPACK would have no direct effect on Poly). But a Mango value would be represented thus: {{{ data Mango = MkMangoRep Bool Int# MkMango :: Poly Int -> MangoRep MkMango (MkP b (I# i)) = MkMangoRep b i -- Pattern match (MkMango p -> rhs) -- is transformed to (MkMangoRep b i -> let p = MkP b (I# i) in rhs }}} Something like that would be rather nice. This ticket is just a reminder. Thanks,[[br]] /Liyang -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 3