October 2014 - ghc-tickets

[GHC] #8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX
by GHC 21 Jan '16

21 Jan '16

#8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX ----------------------------------+---------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Target is `x86_64-pc-linux`. I'm using the toolchain from http://crossgcc .rts-software.org/doku.php, and configured `--with-target=x86_64-pc- linux`. {{{ ===--- building phase 0 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=1 phase_1_builds utils/unlit/ghc.mk:18: utils/unlit/dist/build/.depend.c_asm: No such file or directory utils/hp2ps/ghc.mk:24: utils/hp2ps/dist/build/.depend.c_asm: No such file or directory includes/ghc.mk:146: includes/dist-derivedconstants/build/.depend.c_asm: No such file or directory includes/ghc.mk:184: includes/dist-ghcconstants/build/.depend.c_asm: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.haskell: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.c_asm: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.haskell: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist- boot/build/.depend-v.haskell: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.haskell: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist- boot/build/.depend-v.haskell: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/build/.depend-v.c_asm: No such file or directory compiler/ghc.mk:450: compiler/stage1/build/.depend-v.haskell: No such file or directory HC [stage 0] includes/dist-ghcconstants/build/mkDerivedConstants.o In file included from rts/Capability.h:25, from includes/mkDerivedConstants.c:27:0: rts/Task.h:238:0: error: thread-local storage not supported for this target make[1]: *** [includes/dist-ghcconstants/build/mkDerivedConstants.o] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse..
by GHC 21 Jan '16

21 Jan '16

#8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse.. ------------------------------------+------------------------------------- Reporter: PaulJohnson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The ReadP monad maintains all possible parses of its input, rather than being left-biased as most parsers are. However this is not always quite the Right Thing. I maintain the Data.Decimal library. The Read instance for Data.Decimal up to 0.3.1 had the following behaviour: reads "34.567e8 foo" :: [(Decimal, String)] = [(34.0,".567e8 foo"),(34.567,"e8 foo"),(3.4567e9," foo")] Clearly only the last parse in the list is the Right Thing, and any parser which returns "34.0" when given "34.567" is doing it wrong. The problem came from the implementation of "optional". In numbers only the integer part is mandatory, with the fractional and exponent parts being optional. So I wrote my parser with the fractional part parsed like this: fractPart <- optional "" $ do _ <- char '.' munch1 isDigit The problem is that "optional" uses the symmetric choice operator (+++). I wrote this to work around the problem: myOpt d p = p <++ return d This uses the left-biased choice, so as soon as the parser sees the "." it commits to the fractional part. However this still isn't the Right Thing. reads "34." :: [(Double, String)] = [(34.0, ".")] but the parser above will fail to read it. Furthermore there are a number of combinators built on "+++" in ReadP, and it seems wrong to have left- biased variants of all of them. So what seems to be needed is some kind of "cut" operator, analogous to the Prolog "!" cut, which says that if you have got this far then you should commit to this parse and forget all the others. But it would have to be delimited because I only want that cut to apply to my Decimal type: if someone calls my Decimal parser then I don't want their parser to commit to an entire parse just because I have. So I think the feature I'm looking for is a delimited back-track akin to "prompt" in delimited continuations. But my monad-fu isn't good enough to design it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind"
by GHC 21 Jan '16

21 Jan '16

#8946: Using hdevtools caused "Evaluated the place holder for a PostTcKind" ----------------------------------+--------------------------------- Reporter: tbelaire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I was tying to get hdevtools to work, and cloned it and pulled in a bunch of the open pull requests. You can see the state it's in at github.com/tbelaire/hdevtools. {{{ git clone git@github.com:tbelaire/hdevtools cd hdevtools cabal sandbox init cabal install cd .. }}} I could not reproduce the problem on a small test file, so I'm afraid I'll have to demonstrate it on my vinyl-json package. {{{ git clone git@github.com:tbelaire/vinyl-json cd vinyl-json/ cabal sandbox init cabal install hdevtools type src/Data/Vinyl/JSON.hs 42 15 panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-apple-darwin): Evaluated the place holder for a PostTcKind Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I also get hpc has closed due to a problem a lot when compiling things, but I think that's unrelated. The dynamic lib seems to be gone. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8947: Depending on hint/ghc API fixes the binary version I can use
by GHC 21 Jan '16

21 Jan '16

#8947: Depending on hint/ghc API fixes the binary version I can use ----------------------------+---------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- When I `build-depend` on hint-0.4.0.0 with GHC 7.6.3, I get {{{ % cabal configure Resolving dependencies... cabal: Could not resolve dependencies: trying: pointcloudviewer-0.1.0 (user goal) trying: hint-0.4.0.0/installed-cf3... (dependency of pointcloudviewer-0.1.0) trying: ghc-7.6.3/installed-494... (dependency of hint-0.4.0.0/installed-cf3...) trying: bin-package-db-0.0.0.0/installed-608... (dependency of ghc-7.6.3/installed-494...) trying: GLUtil-0.7.4/installed-223... (dependency of pointcloudviewer-0.1.0) next goal: linear (dependency of GLUtil-0.7.4/installed-223...) rejecting: linear-1.6/installed-300... (conflict: bin-package-db => binary==0.5.1.1/installed-72e..., linear => binary==0.7.1.0/installed-a33...) }}} This fails because `linear` uses a `binary > 0.5.1.1`, but through my use of `hint` which depends on `ghc` (`hint` does not directly depend on `binary`), I pull in a constraint `binary == 0.5.1.1`. I believe this is bad, because depending on the GHC API in any way fixes the binary version I can use, which immediately makes a range of newer libraries unavailable to my program. Probably GHC should somehow hide the fact that binary is used inside, and let the rest of my program use whatever binary it likes. ---- I am aware that this might not be immediately easy, since the GHC API might expose some `binary` types to my program that I could try use with my newer binary version, which of course would be illegal. Maybe it is possible to implement such a check into actual typechecking, and let it pass if I don't actually use types from the old version with functions from the new library. I actually believe I have seen compiler errors in the past where two identical types where not unified because one was from a different version, so maybe infrastructure for this is already in place? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8947> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8992: Instructions for using gdb with GHC on Windows
by GHC 21 Jan '16

21 Jan '16

#8992: Instructions for using gdb with GHC on Windows ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- gdb remains a useful tool for debugging executables on Windows, but getting it setup can be tricky, since modern gdb requires Python, which means you will end up installing MSYS Python alongside native Python. Unfortunately, MSYS Python doesn't work with the test suite, so one is in the delicate situation where you want your path to have MSYS Python if you're running gdb, but Windows Python if you're running the test suite. While one can work around this with modest annoyance (the easiest thing I've found is to just uninstall gdb/python when I'm not using it), it would be better if we removed this friction in some way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9037: Add option to make selected warnings errors
by GHC 21 Jan '16

21 Jan '16

#9037: Add option to make selected warnings errors ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It would be great if GHC offered a `-ferror-*` flag for every `-fwarn-*` flag, that turns the given type of warning into an error. For example, I would like to always error on uninitialized record fields, but don't want to go full `-Werror`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9357: Kind-polymorphic type family accepts unlifted type arguments
by GHC 21 Jan '16

21 Jan '16

#9357: Kind-polymorphic type family accepts unlifted type arguments -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | accepts invalid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code is accepted by ghc-7.8.2 and ghc-7.6.3: {{{#!hs {-# LANGUAGE TypeFamilies, MagicHash, PolyKinds #-} import GHC.Exts type family F (a :: k) :: * type instance F Int# = () }}} In nearly all other places, it seems that unlifted types are explicitly forbidden. I'm also not allowed to actually apply `F` to `Int#` after defining the type family like this. So I think the compiler should probably reject the `type instance`. (BTW, is it actually clear that using `#` as an argument kind to a type family or as an index kind for a GADT is in any way harmful?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link
by GHC 21 Jan '16

21 Jan '16

#9215: GHC 7.8.2 mingw-w64: symbol not found in link ------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This includes calls such as strdup, stat, , and snprintf. These calls are not available in the 64 bit libraries (though 64 bit versions are such as _strdup, _snprintf) These problems have occurred in building yaml and unix-compat. They also occurred in system-fileio but jmilikin generated a patch for that library -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9182: Empty case analysis for function clauses
by GHC 20 Jan '16

20 Jan '16

#9182: Empty case analysis for function clauses ------------------------------------+------------------------------------- Reporter: dfranke | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Thanks to `-XEmptyCase`, the following is legal: {{{ module Empty where data Empty empty :: Empty -> a empty x = case x of { } }}} However, if I leave off the last line, GHC will complain that `The type signature for ‘empty’ lacks an accompanying binding`. I think this program should be accepted. It isn't that I'm not giving a definition for `empty`; it's that I'm defining it to be a function with no accompanying equations, as could be represented in Template Haskell by $(return [FunD (mkName "empty") []]) Currently, this too is rejected, with GHC complaining `Function binding for ‘empty’ has no equations`. I think this should be legal, with an empty list of clauses in a function definition being treated the same way as an empty list of matches in a case expression. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9202: Strange Closure Type
by GHC 20 Jan '16

20 Jan '16

#9202: Strange Closure Type -------------------------------------+------------------------------------- Reporter: athanclark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: strange-closure- | Operating System: Linux type | Type of failure: Compile-time Architecture: x86_64 (amd64) | crash Difficulty: Project (more | Test Case: than a week) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Hello masters of the universe, I am here with a plea. I have recently installed GHC 7.8.2 and cabal-install 1.20.0.0 (following [https://gist.github.com/wting/8498731 this] guide), and have ran into a fun road block on the way to installing yesod-platform. I have had a few incidents of the 'strange closure type ###' error on this machine before, on the 7.6.x version available in Ubuntu's repository. I believe this failure is occuring when installing text, because that was the error that I got when installing attoparsec alone, but without a sandbox. I know (barely) better now, so when I went to install yesod-platform, I did a {{{cabal unpack $1 && cd $1* && cabal sandbox init && cabal install --only-dependencies && cabal build}}}, but I failed at preventing the error, still :( I've attached the output as output.txt, and I've also included my `lspci` and `lshw` outputs just for giggles :) I hope someone can direct me in the right direction, I would appreciate it tremendously. Thank you! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9