- ghc-tickets - Haskell.org

[GHC] #7668: Location in -fdefer-type-errors
by GHC 13 Apr '13

13 Apr '13

#7668: Location in -fdefer-type-errors -----------------------------+---------------------------------------------- Reporter: monoidal | 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: -----------------------------+---------------------------------------------- Consider {{{ x :: Char x = 'x' + 1 y :: Char y = 'y' + 1 }}} Run `ghci -fdefer-type-errors`: {{{ *Main> x *** Exception: G.hs:5:9: No instance for (Num Char) arising from a use of `+' In the expression: 'y' + 1 In an equation for `y': y = 'y' + 1 (deferred type error) *Main> y *** Exception: G.hs:5:9: No instance for (Num Char) arising from a use of `+' In the expression: 'y' + 1 In an equation for `y': y = 'y' + 1 (deferred type error) }}} The first exception is wrong. It seems that the missing `Num Char` instance is filled with the same error message in all places where the constraint should be supplied. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7667: Template Haskell fails to recognize type operator/function +
by GHC 13 Apr '13

13 Apr '13

#7667: Template Haskell fails to recognize type operator/function + --------------------------------------+------------------------------------- Reporter: andygill | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following message is issued for a valid TH program. {{{ Main.hs:7:1: Illegal type constructor or class name: `+' When splicing a TH declaration: type instance GHC.TypeLits.+ 1 2 = 3 Failed, modules loaded: Test1. }}} Code attached. The program is attempting to capture the name +, as used by Nat at the type level. The problem appears to be in Convert.hs {{{ -- Convert.hs okOcc :: OccName.NameSpace -> String -> Bool okOcc _ [] = False okOcc ns str@(c:_) | OccName.isVarNameSpace ns = startsVarId c || startsVarSym c | otherwise = startsConId c || startsConSym c || str == "[]" }}} + is rejected, by okOcc, even though it is acceptable, the symbol neither starts with upper-case, or ':'. I have tried using reify to extract the *actual* name from other sources (rather than use mkNameG_tc), and it fails in the same way. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7484: Template Haskell allows building invalid record fields/names
by GHC 13 Apr '13

13 Apr '13

#7484: Template Haskell allows building invalid record fields/names ---------------------------------+------------------------------------------ Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by igloo): See also #7667 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7484#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs
by GHC 13 Apr '13

13 Apr '13

#7666: excessive space and time usage for rendering (somewhat) deeply nested Docs -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Component: libraries/pretty Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I was running into serious performance problems when printing moderately sized Doc and Xml data (HaXml goes via Doc). Since pretty is shipped with ghc, this is potentially dangerous. Users will just assume that these core components are tried and tested, and working efficiently. More info: http://article.gmane.org/gmane.comp.lang.haskell.cafe/103210 See also: http://stackoverflow.com/questions/9761507/which-pretty-print-library Test case (builds an Xml tree with HaXml and renders it via the pretty library): https://github.com/jwaldmann/haskell-tpdb/blob/master/test/speed.hs -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7665: dynamicToo001 fails on Windows
by GHC 13 Apr '13

13 Apr '13

#7665: dynamicToo001 fails on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ `dynamicToo001` fails on Windows: {{{ =====> dynamicToo001(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory dynamicToo001 </dev/null >dynamicToo001.run.stdout 2>dynamicToo001.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Makefile:12: recipe for target `dynamicToo001' failed Stderr: A001.dyn_o:fake:(.text+0x2e): undefined reference to `__imp_stg_CAF_BLACKHOLE_info' A001.dyn_o:fake:(.text+0x5f): undefined reference to `__imp_newCAF' A001.dyn_o:fake:(.text+0x72): undefined reference to `__imp_stg_bh_upd_frame_info' A001.dyn_o:fake:(.text+0x87): undefined reference to `__imp_ghczmprim_GHCziTypes_Czh_con_info' c:/ghc64/git/cygwin/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: A001.dyn_o: bad reloc address 0x0 in section `.data' c:/ghc64/git/cygwin/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Invalid operation collect2: ld returned 1 exit status make[2]: *** [dynamicToo001] Error 1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7659: Add some latency nofib benchmarks
by GHC 13 Apr '13

13 Apr '13

#7659: Add some latency nofib benchmarks -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Component: NoFib benchmark suite Version: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- At the moment, GHC is heavily throughput oriented (e.g. scheduler choices, etc). However, applications like Cloud Haskell often would like to reduce latency, even if it is at the cost of some throughput. However, we have no good way of measuring when changes to the RTS improve latency. We should add some benchmark programs along these lines. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7659> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7655: 7.4.2 Segmentation Fault/Bus Error in large exponentation
by GHC 13 Apr '13

13 Apr '13

#7655: 7.4.2 Segmentation Fault/Bus Error in large exponentation -----------------------+---------------------------------------------------- Reporter: Doug310 | 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: -----------------------+---------------------------------------------------- Mac OS X 10.8.2. Haskell Platform 2012.4, 64-bit. GHCI 7.4.2. Large exponentations cause bus errors or segmentation faults. Examples: {{{ ~/src/haskell$ 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. Prelude> 12345678901234567890 ^ 12345 Bus error: 10 ~/src/haskell$ 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. Prelude> 2384729837498237^23455 Segmentation fault: 11 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7655> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7832: In function 'stg_ap_0_fast' 'debugBelch' undeclared
by GHC 13 Apr '13

13 Apr '13

#7832: In function 'stg_ap_0_fast' 'debugBelch' undeclared --------------------------------+------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc64 Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Attempting to build git HEAD on linux-powerpc64: {{{ "inplace/bin/ghc-stage1" -static -optc-DDEBUG -ticky -DTICKY_TICKY -H32m -O -Werror -Wall \ -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header \ -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts \ -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build \ -Irts/dist/build/autogen -O2 -O0 -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.debug_o \ /tmp/ghc32217_0/ghc32217_0.hc: In function 'stg_ap_0_fast': /tmp/ghc32217_0/ghc32217_0.hc:21:12: error: 'debugBelch' undeclared (first use in this function) /tmp/ghc32217_0/ghc32217_0.hc:21:12: note: each undeclared identifier is reported only once for each function it appears in /tmp/ghc32217_0/ghc32217_0.hc:24:12: error: 'printClosure' undeclared (first use in this function) /tmp/ghc32217_0/ghc32217_0.hc:31:12: error: 'checkStackFrame' undeclared (first use in this function) /tmp/ghc32217_0/ghc32217_0.hc: In function 'stg_PAP_entry': /tmp/ghc32217_0/ghc32217_0.hc:127:12: error: 'barf' undeclared (first use in this function) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7440: haddock : Declaration for $fEqInteger attempting to use module `ghc-prim:GHC.Classes' which is not loaded
by GHC 13 Apr '13

13 Apr '13

#7440: haddock : Declaration for $fEqInteger attempting to use module `ghc- prim:GHC.Classes' which is not loaded -------------------------+-------------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: Linux Architecture: powerpc | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Changes (by erikd): * status: infoneeded => new -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7440#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7440: haddock : Declaration for $fEqInteger attempting to use module `ghc-prim:GHC.Classes' which is not loaded
by GHC 13 Apr '13

13 Apr '13

#7440: haddock : Declaration for $fEqInteger attempting to use module `ghc- prim:GHC.Classes' which is not loaded -------------------------+-------------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: Linux Architecture: powerpc | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Comment(by erikd): > erikd, when you run make again, does it rerun that failing command, but this time succeed? Running make again allowed it to complete the compilation process, but I'm not sure if the failing command was re-run or not (eg, the target file may not have been deleted on failure). I never saw this on other platforms, not even powerpc. I'm now trying to build current HEAD and running into a bunch of other problems (eg #7830). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7440#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0