January 2014 - ghc-tickets

Re: [GHC] #661: Serious Data.HashTable bug
by GHC 12 Jan '14

12 Jan '14

#661: Serious Data.HashTable bug -------------------------------------+--------------------------------- Reporter: jwr@… | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.4.2 Component: libraries/base | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | -------------------------------------+--------------------------------- Comment (by Simon Marlow <simonmar@…>): In [changeset:"418362a2409919eb65eb3d668aaafea74cc7dedf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="418362a2409919eb65eb3d668aaafea74cc7dedf" add test for bug #661 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/661#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #685: Panic splitTyConApp a{tv a1nD} when dealing with GADTs in optimizing mode
by GHC 12 Jan '14

12 Jan '14

#685: Panic splitTyConApp a{tv a1nD} when dealing with GADTs in optimizing mode ------------------------------+----------------------- Reporter: alcremi@… | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Difficulty: Unknown | ------------------------------+----------------------- Comment (by simonpj <simonpj@…>): In [changeset:"ba72db2f52ff87be17342464228f4dd2f9140544/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ba72db2f52ff87be17342464228f4dd2f9140544" Add test for bug 685 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/685#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #441: GHCi doesn't run computations in a new thread
by GHC 12 Jan '14

12 Jan '14

#441: GHCi doesn't run computations in a new thread -------------------------------------+--------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.4.2 Component: GHCi | Version: 6.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | -------------------------------------+--------------------------------- Comment (by simonmar <unknown>): In [changeset:"2e8bfab959f929ac795d0d2ac64c0446c19e183e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2e8bfab959f929ac795d0d2ac64c0446c19e183e" [project @ 2006-01-12 16:03:21 by simonmar] add test from ticket #441 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/441#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5916: runST isn't free
by GHC 11 Jan '14

11 Jan '14

#5916: runST isn't free -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Replying to [comment:15 simonpj]: > Also it occurs to me that the C-- code for these two code fragments will be nearly identical > {{{ > (1) case st_rep s of (# _, r #) -> r > (2) st_rep s > }}} > The latter will be a tail call; the former will push a return frame, call, and then simply return after that. So we could maybe code-gen (1) just like (2). Not exactly: (1) evaluates `r`, but (2) doesn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5916#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #393: functions without implementations
by GHC 11 Jan '14

11 Jan '14

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type | Version: None checker) | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Unknown/Multiple | Difficulty: Moderate (less Type of failure: None/Unknown | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonmar): I think that this is another kind of "deferred error", in the same sense of `-fdefer-type-errors`, and there are lots of other kinds of errors that we want to defer (e.g. out-of-scope identifiers). So all I'm suggesting is that we should bear this in mind, and perhaps use a consistent naming convention for flags, e.g. this particular one could be `-fdefer-missing- decl-errors`, which would eventually become part of `-fdefer-renamer- errors`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
by GHC 11 Jan '14

11 Jan '14

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by goldfire): This looks nice -- I can easily believe it works. Here is some feedback I have on the code: * I would want to see this handle `IrredPred` predicates, as well as tuples. That way, synonyms built with !ConstraintKinds would be fully supported by TH. I don't think this should be too much work beyond what you've already done. * I still think a change to !DsMeta is warranted. For example, I would imagine code like `[t| (Show a, (Read a, Num a)) => a -> a |]` would fail to compile, even though TH would now be able to represent such a predicate. * The functions `classP` and `equalP` in the `Lib` module are meant to echo the constructors of `Pred`. I would say that, now that `Pred` is a synonym, `classP` and `equalP` should be removed. (It took me a while to understand why all those functions are there in `Lib` -- the answer is that !DsMeta is ''much'' easier to write with those functions there.) Leaving `classP` and `equalP` doesn't cause anyone any real harm, but it would just be a small wart on the design that could easily be eliminated. * Along similar lines, you will probably find that you need an `equalityT` function in `Lib` when updating !DsMeta. * It looks like you left the old `Pred` commented-out in `Syntax`. * While it is probably too late now (and I don't think worth going back to fix), it's best to do whitespace changes in separate commits from substantive changes. Perhaps before editing a new file, removing the trailing whitespace, make a commit, and then go back and to the real changes. You can always then rebase at the end of your session to lump together all the whitespace commits. Continued thanks for working on this! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 11 Jan '14

11 Jan '14

#7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623, 8664 Blocking: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kgardas): Good! So this LLVM bug above shows only on PrimoptWrappers and I've been able to compile this file without -fllvm as Carter points out above. So here is bindist's HelloWorld running on AArch64/ARM64 platform: {{{ root@localhost:~# ./HelloWorld Hello world!root@localhost:~# file HelloWorld HelloWorld: ELF 64-bit LSB executable, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.7.0, BuildID[sha1]=0x5301662c82ccd3fe7c3f1486ac10d0f13b2f54c9, not stripped root@localhost:~# uname -m aarch64 root@localhost:~# }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7021: Tuple (and other exotic predicates) not yet handled in Template Haskell
by GHC 11 Jan '14

11 Jan '14

#7021: Tuple (and other exotic predicates) not yet handled in Template Haskell -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: | Milestone: 7.8.1 feature request | Version: 7.5 Priority: | Keywords: ConstraintKinds normal | TemplateHaskell Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by yoeight): Surprisingly, I didn't have to modify `DsMeta.lhs` but I had to change a couple of test files that I've forgot in my sum up (respectively `T8625.stdout` and `TH_genExLib.hs`) I did run the testsuite and everything is working properly Patches can be found [https://gist.github.com/YoEight/8370987 here]. Unfortunately, there were trailing whitespaces in some files -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7021#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 11 Jan '14

11 Jan '14

#7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: kgardas Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623, 8664 Blocking: | Related Tickets: --------------------------------------------+------------------------------ Changes (by kgardas): * blockedby: 7623 => 7623, 8664 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8661: Segfault on System.Time during validate
by GHC 11 Jan '14

11 Jan '14

#8661: Segfault on System.Time during validate ----------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- I was running ‘sh validate’ today (commit d4f0fcf368765ae4aa7ebe914bc2f254026694c8) and I ended up with this error: {{{ cat ghc/ghc.wrapper >> inplace/bin /ghc-stage2 chmod +x inplace/bin /ghc-stage2 "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name old-time-1.1.0.2 -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.6 -Wall -XHaskell2010 -O2 -O -dcore-lint -fno-warn-amp -fno- warn-deprecated-flags -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 gmake[1]: *** [libraries/old-time/dist-install/build/System/Time.o] Segmentation fault gmake[1]: *** Waiting for unfinished jobs.... Writing docs/users_guide/users_guide/ix01.html for index Writing docs/users_guide/users_guide/index.html for book(users-guide) cp mk/fptools.css docs/users_guide/users_guide/ gmake: *** [all] Error 2 }}} It built fine when I ran validate just the other day (at least after commit 32002b3dfdfd6a3c6a1a1eb52d8a257b42e17e51). 32-bit Linux Linux misaki 3.12.3-gentoo `#2` SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux Attaching full build log. This is a tree without any local changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7