September 2013 - ghc-tickets

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 04 Sep '13

04 Sep '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): Replying to [comment:43 parcs]: > I haven't tested `cabal` with my branch but I don't think my changes are causing the errors you're experiencing. I'm willing to bet that it's due to recent changes pushed to master. (Or maybe you forgot to do `git submodule update` after checking out my branch?) > I'm pretty sure I updated the submodules, but I'll do a fresh build to double check. Except for the excessive system-time the parallel make actually works for me, as long as I don't do `cabal -j`. I can even install packages with parallel GHC / non-parallel cabal. Could I get a fix on what other people who are testing this branch are seeing? Are you able to install packages with `cabal -j`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8210: Make fails for Building a GHC cross-compiler for Apple iOS target (i386-apple-darwin11)
by GHC 04 Sep '13

04 Sep '13

#8210: Make fails for Building a GHC cross-compiler for Apple iOS target (i386 -apple-darwin11) ----------------------------------+---------------------------------------- Reporter: alen_ribic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I followed the instructions for '''Building a GHC cross-compiler for Apple iOS targets''' (http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS) I ran the '''./configure --target=i386-apple-darwin11 --prefix=/usr/local /ghc-ios-sim/''' which ran successfully. However, '''make''' failed with the below error: {{{ /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:145:0: no such instruction: `vmovss 40(%ebx), %xmm0' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:146:0: no such instruction: `vmovss %xmm0, -4(%ebp)' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:155:0: no such instruction: `vmovsd 64(%ebx), %xmm0' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:156:0: no such instruction: `vmovsd %xmm0, -8(%ebp)' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:165:0: no such instruction: `vmovsd 208(%ebx), %xmm0' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:166:0: no such instruction: `vmovsd %xmm0, -8(%ebp)' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:663:0: no such instruction: `vmovss 4(%ebp), %xmm0' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:664:0: no such instruction: `vmovss %xmm0, 40(%ebx)' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:681:0: no such instruction: `vmovsd 4(%ebp), %xmm0' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:682:0: no such instruction: `vmovsd %xmm0, 64(%ebx)' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:699:0: no such instruction: `vmovsd 4(%ebp), %xmm0' /var/folders/cv/1jdvk8bj2sjd_zz5x0d9w05h0000gn/T/ghc50871_0/ghc50871_0.s:700:0: no such instruction: `vmovsd %xmm0, 208(%ebx)' make[1]: *** [rts/dist/build/HeapStackCheck.o] Error 1 make: *** [all] Error 2 }}} Setup details my end: GCC: head Mac OS X version: 10.8.4 GCC: 4.2.1 LLVM: 3.2svn XCode: 4.6.3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #8039: RTS linker: unloadObj() does not actually unload the code
by GHC 04 Sep '13

04 Sep '13

#8039: RTS linker: unloadObj() does not actually unload the code --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: rts/linker_unload | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by heisenbug): Replying to [comment:16 simonmar]: > The big missing piece with unloading of .so's is knowing their boundaries in memory [http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared- libraries Eli Bendersky's article] suggests to use the [http://linux.die.net/man/3/dl_iterate_phdr dl_iterate_phdr] function for finding information about loaded libraries. Seems to be linux only. There is a [http://stackoverflow.com/questions/10009043/dl-iterate-phdr- equivalent-on-mac workaround on OSX], though, on !StackOverflow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8039#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 04 Sep '13

04 Sep '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------------------+--------------------------------- Reporter: edsko | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: quasiquotation/T7918 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Changes (by edsko): * status: new => merge Comment: I think this is now fixed; added config.ghc_th_way_flags to the test (copied from other TH tests). Not sure why that wasn't necessary on OSX or why the other tests in quasiquotation don't need but, it it does seem to fix the problem (inserts -dynamic). Closing the issue again; please reopen if it turns out not to be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 04 Sep '13

04 Sep '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------------------+--------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: quasiquotation/T7918 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Comment (by jstolarek): Test also fails for me on x86_64 Linux. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8221: Type checker hangs
by GHC 04 Sep '13

04 Sep '13

#8221: Type checker hangs ----------------------------+---------------------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: hangs | Operating System: MacOS X Architecture: arm | Type of failure: GHC rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------------- The following program gets GHC stuck in Renamer/typechecker. This compiles correctly in 7.6.3. {{{ {-# LANGUAGE DeriveDataTypeable #-} module Type.Type where import Data.Data import qualified Data.UnionFind.IO as UF data SrcSpan = Span String | NoSpan String deriving (Eq, Ord, Data, Typeable) data Located e = L SrcSpan e deriving (Eq, Ord, Data, Typeable) }}} Removing either the: {{{ import qualified Data.UnionFind.IO as UF }}} or {{{ data Located e = L SrcSpan e deriving (Eq, Ord, Data, Typeable) }}} or Removing the Eq Ord from Located: {{{ data Located e = L SrcSpan e deriving (Data, Typeable) }}} will allow it to terminate. ddump-tc-trace shows it is related to the derived typeable instance. The log is attached. I am compiling with: {{{ arm-apple-darwin10-ghc -staticlib -ddump-tc-trace Type/Type.hs -v -threaded }}} I don't have a x86 build of HEAD handy, I think if someone could try this program in HEAD then we will know if it is ARM / GHC iOS / stage1 specific or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #8039: RTS linker: unloadObj() does not actually unload the code
by GHC 04 Sep '13

04 Sep '13

#8039: RTS linker: unloadObj() does not actually unload the code --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: rts/linker_unload | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by simonmar): The big missing piece with unloading of .so's is knowing their boundaries in memory so that the GC can detect whether there are any references left. I don't know of a way to do that with the system linker, if anyone knows of a way then I'd be happy to add support for unloading .so's. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8039#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8214: 'Untouchable' error in list comprehension
by GHC 04 Sep '13

04 Sep '13

#8214: 'Untouchable' error in list comprehension -------------------------------------------+------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Hi, I think this program should compile but it doesn't: {{{ {-# LANGUAGE GADTs #-} data X a where X :: X Int foo :: Bool foo = null [ () | X <- [] ] }}} It fails with: {{{ Couldn't match expected type `a0' with actual type `()' `a0' is untouchable inside the constraints (t_g ~ Int) bound at a pattern with constructor X :: X Int, in a pattern binding in list comprehension In the pattern: X In a stmt of a list comprehension: X <- [] In the first argument of `null', namely `[() | X <- []]' }}} If I remove the type declaration GHC compiles without errors and happily infers {{{foo :: Bool}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve'
by GHC 04 Sep '13

04 Sep '13

#7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' ----------------------------+---------------------------------------------- Reporter: songpp | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: #2487, #7103 Blocking: | ----------------------------+---------------------------------------------- Changes (by simonmar): * priority: high => highest -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7056#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 04 Sep '13

04 Sep '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------------------+--------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: quasiquotation/T7918 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Changes (by simonmar): * owner: edsko => * status: closed => new * resolution: fixed => Comment: The test is failing for me: {{{ =====> T7918(normal) 10 of 13 [0, 0, 0] cd . && '/home/simon/code-all/work/ghc-validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o T7918 T7918.hs -package ghc >T7918.comp.stderr 2>&1 cd . && ./T7918 "/home/simon/code-all/work/ghc-validate/inplace/lib" </dev/null >T7918.run.stdout 2>T7918.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: T7918: <command line>: can't load .so/.DLL for: /home/simon/code-all/work /ghc-validate/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.3.1.0-ghc7.7.20130904.so (/home/simon/code-all/work/ghc- validate/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.3.1.0-ghc7.7.20130904.so: undefined symbol: stg_forkOnzh) *** unexpected failure for T7918(normal) }}} My guess is that the test itself is linked statically, but the GHC package is expecting to be linked dynamically, so it tries to load the shared libraries rather than the static ones. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0