February 2013 - ghc-tickets

[GHC] #7691: ghc.exe: internal error: evacuate: strange closure type 48880
by GHC 17 Feb '13

17 Feb '13

#7691: ghc.exe: internal error: evacuate: strange closure type 48880 -------------------------------+-------------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- While trying to install haskell-src-exts-1.13.5, the following message was displayed: ghc.exe: internal error: evacuate: strange closure type 48880 (GHC version 7.4.2 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug See the attached file for all messages. I issued command cabal install haskell-src-exts-1.13.5 after this; the command was successful. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7691> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo
by GHC 17 Feb '13

17 Feb '13

#7673: Windows: run "git config --global core.autocrlf false" before cloning the repo ---------------------+------------------------------------------------------ Reporter: morabbin | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: ---------------------+------------------------------------------------------ On my windows box, I experienced the following loop: {{{ GROOB:~/work $ git clone git@github.com:ghc/ghc.git Cloning into 'ghc'... remote: Counting objects: 223976, done. remote: Compressing objects: 100% (44932/44932), done. remote: Total 223976 (delta 179757), reused 222061 (delta 178061) Receiving objects: 100% (223976/223976), 67.25 MiB | 560 KiB/s, done. Resolving deltas: 100% (179757/179757), done. GROOB:~/work $ cd ghc GROOB:~/work/ghc $ ls ANNOUNCE SUBMAKEHELP config.sub* ghc.mk mk/ tarballs HACKING aclocal.m4 configure.ac ghc.spec.in packages utils/ LICENSE bindisttest/ distrib/ includes/ rts/ validate* MAKEHELP boot* docs/ install-sh* rules/ Makefile compiler/ driver/ libffi/ settings.in README config.guess* ghc/ libraries/ sync-all* GROOB:~/work/ghc $ ./sync-all get at ./sync-all line 287. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball ============================ ATTENTION! You have an old time package in your GHC tree! Please remove it (e.g. "rm -r libraries/time"), and then run "./sync-all get" to get the new repository. ============================ GROOB:~/work/ghc $ l libraries/time ./ ../ GROOB:~/work/ghc $ rm -rf libraries/time GROOB:~/work/ghc $ l libraries/time /bin/ls: libraries/time: No such file or directory GROOB:~/work/ghc $ ./sync-all get at ./sync-all line 287. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball ============================ ATTENTION! You have an old time package in your GHC tree! Please remove it (e.g. "rm -r libraries/time"), and then run "./sync-all get" to get the new repository. ============================ GROOB:~/work/ghc $ }}} Turns out the problem is solved by deleting the repo, running: {{{ git config --global core.autocrlf false }}} and checking out the repo again. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7673> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7690: iOS patch no 1: Select operating system
by GHC 17 Feb '13

17 Feb '13

#7690: iOS patch no 1: Select operating system ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- This is the first in a series of patches for adding cross-compile ability for iOS. For now, 'arm-apple-darwin10' will be interpreted as iOS. Later we will need to tweak this to detect the difference between the iOS simulator (with an i386 cpu) and the native Mac. I am creating a new logical OS name 'ios' because the differences between iOS and Mac can be quite significant. I thought it would we best not to introduce the idea of an OS variant (as we did with ARM cpus) for two reasons: 1. it's over-complicating the issue and 2. it would require some modification of cabal. Versioning: I'm submitting patch version 1a here. If I have to revise a patch, I'll bump the letter. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #7699: iOS patch no 2: remove obsolete CROSS_COMPILE variable
by GHC 17 Feb '13

17 Feb '13

#7699: iOS patch no 2: remove obsolete CROSS_COMPILE variable ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- This is the second iOS cross compile patch, though it isn't iOS-specific. The CROSS_COMPILE variable was used to turn on behaviour in certain modules, but is now obsolete. So let's remove it. With this patch applied, CROSS_COMPILE appears nowhere in the build tree. I also tested it by building an ARM-linux cross compiler. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 17 Feb '13

17 Feb '13

#5987: Too many symbols in ghc package DLL ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 3658 Related: | ---------------------------------+------------------------------------------ Changes (by rassilon): * cc: bill@… (added) Comment: Here's a pretty nutty idea: What if we split the DLL in parts by automatically forcing the .o files into partitions and create a .def file for each partition thus breaking the import library cycle. GHC already uses .def files to break the cycle between the RTS and the base DLLs. Then you would "just" modify Cabal to understand partitioned DLLs. Unfortunately, this might end up increasing the total number of partitions if you're not careful because internal symbols would now need to be exported from the partitions. :( -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5987#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5620: Dynamic linking and threading does not work on Windows
by GHC 17 Feb '13

17 Feb '13

#5620: Dynamic linking and threading does not work on Windows -------------------------------+-------------------------------------------- Reporter: Lennart | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Runtime System | Version: 7.2.1 Keywords: | Os: Windows Architecture: x86 | Failure: Runtime crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Changes (by rassilon): * cc: bill@… (added) Comment: Could we somehow abuse the delay load DLL functionality with a custom delay load helper function? Or, we could do something similar to what MinGW (If I recall correctly) does in order to be able to process dynamically loaded data relocations That seems like a really large hammer though. :( -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5620#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7688: :kind should do kind generalisation
by GHC 15 Feb '13

15 Feb '13

#7688: :kind should do kind generalisation ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Suppose you load this into GHCi: {{{ {-# LANGUAGE PolyKinds #-} module Test where data Proxy (t::k) = Proxy }}} Now you use `:kind` to see the kind of `Proxy`: {{{ ghci> :k Proxy Proxy :: * -> * }}} It is true that `Proxy` has that kind but it has a more polymorphic kind, and that's the one we'd like to see. The trouble is this. `Proxy` really does have a polymorphic kind. However, `:kind` takes a '''type''' (not a type constructor) as its argument, so you can say {{{ :kind (Maybe Int) }}} for example. So as usual we instantiate `Proxy` with fresh kind variables -- '''BUT''' `:kind` does not do kind generalisation, so we get a monomorphic instance. (And we default unbound kind variables to `*`. Conclusion: `:kind` should do kind-generalisation. See also #7586 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7511: Room for GHC runtime improvement >~5%, inlining related
by GHC 15 Feb '13

15 Feb '13

#7511: Room for GHC runtime improvement >~5%, inlining related ---------------------------------+------------------------------------------ Reporter: danielv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * cc: simonpj@… (removed) * difficulty: => Unknown Comment: Right! I think this loss of let-no-escapey-ness is precisely what can cause increased allocation when we inline. Daniel and I found this (hence the birth of this ticket), and I believe that the LNE thing was the sole cause we identified. One might solve this by making the code generator yet more clever, so that it can avoid allocation for non-escaping functions, even they aren't tail calls. But that is quite hard. More promising, I think, is to float that `j` function to top level altogether, and that is what Nick is working on. I'm hopeful that this'll solve much of the problem. See also #5075 which reports a similar difficulty with LNEs becoming non- LNEs. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7511#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7511: Room for GHC runtime improvement >~5%, inlining related
by GHC 15 Feb '13

15 Feb '13

#7511: Room for GHC runtime improvement >~5%, inlining related ------------------------------------+--------------------------------------- Reporter: danielv | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- Comment(by nfrisby): Just FYI, I've recently seen one example where more inlining caused an increase in allocation. Here's an abstraction: {{{ f a b = let-no-escape j = ... in ... j ... g x y = ... case f (...) (...) of ... }}} f got inlined and the j binding got floated out a bit. Thus j was no longer LNE, since the result of its call was scrutinized. This happened in puzzle; the StateType's == and /= methods were f and g, respectively. I had accidentally awarded a huge result discount to ==. Yell if you'd like more details. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7511#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2354: NOINLINE pragma ignored
by GHC 15 Feb '13

15 Feb '13

#2354: NOINLINE pragma ignored ------------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.9 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: typecheck/should_fail/T2354 | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T2354 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2354#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0