March 2014 - ghc-tickets

[GHC] #8855: LLVM backend needs to use `-globalopt` explicitly
by GHC 17 Mar '14

17 Mar '14

#8855: LLVM backend needs to use `-globalopt` explicitly ------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While `-O1` and `-O2` includes a `-globalopt` pass, for reasons I don't entirely understand the location of the pass is such that not all aliases are eliminated. My `ghc-7.8` branch includes a patch fixing this (as well as removing ARM from the dynamic linking blacklist)[1]. [1] https://github.com/bgamari/ghc/commits/ghc-7.8 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8855> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7874: segfault 11 on mac os x when building compiler for ghc 7.7.20130430
by GHC 17 Mar '14

17 Mar '14

#7874: segfault 11 on mac os x when building compiler for ghc 7.7.20130430 ----------------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by carter): * status: new => closed * resolution: => fixed Comment: I believe this is resolved. closing -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7874#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools)
by GHC 17 Mar '14

17 Mar '14

#8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools) ----------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I got the following panics when I ran the GHC test suite per ticket #8148 (using xcode 5 CLI dev preview tools released as of august 21st on OS X 10.8) =====> ghcilink003(normal) 889 of 3736 [8, 195, 0] cd ./ghci/linking && $MAKE -s --no-print-directory ghcilink003 </dev/null >ghcilink003.run.stdout 2>ghcilink003.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> EnumFromToP(normal) 564 of 3736 [0, 82, 0] cd ./dph/enumfromto && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c EnumFromToP.hs -O -fno-enable-rewrite-rules -package dph-lifted-vseg >EnumFromToP.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-22 16:09:56.000000000 -0400 +++ ./dph/enumfromto/EnumFromToP.comp.stderr 2013-08-22 16:11:18.000000000 -0400 @@ -0,0 +1,6 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20130822 for x86_64-apple-darwin): + DsMonad: uninitialised ds_parr_bi + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> jmp_tbl(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c jmp_tbl.hs -O -fasm -fPIC -O >jmp_tbl.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(hpc) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fhpc -hpcdir .hpc.T7574 -no- hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fasm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(normal) 102 of 3736 [0, 2, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8841: PatternSynonyms error gives wrong source locations
by GHC 17 Mar '14

17 Mar '14

#8841: PatternSynonyms error gives wrong source locations -------------------------+------------------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: 7.8.1 Priority: low | Version: 7.8.1-rc2 Component: | Operating System: Linux Compiler | Type of failure: Incorrect warning at Keywords: | compile-time PatternSynonyms | Test Case: Architecture: x86 | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Using an example from the [http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/syntax- extns.html GHC user's guide] but omitting the argument to `Maybe` {{{ {-# LANGUAGE PatternSynonyms #-} data Type = App String [Type] pattern Maybe = App "Maybe" [t] }}} gives the following error without the correct source locations {{{ ghci> :load /tmp/failure.hs [1 of 1] Compiling Main ( /tmp/failure.hs, interpreted ) /tmp/failure.hs:1:1: Right-hand side of bidirectional pattern synonym cannot be used as an expression App "Maybe" [t] Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8851: Standalone deriving and GND behave differently
by GHC 17 Mar '14

17 Mar '14

#8851: Standalone deriving and GND behave differently ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Sergey Tromimovich writes: Trying to build random packages with fresh ghc-7.8.1-rc2 I've come up with a strange bit: https://github.com/trofi/Idris- dev/commit/9f93122ba1aa075c2fa1555fea68a6c403697e04 Is it an intended behaviour that standalone deriving (A) {{{ deriving instance Parsing IdrisInnerParser }}} is capable of doing more, than a deriving clause (B) {{{ newtype IdrisInnerParser a = IdrisInnerParser { runInnerParser :: Parser a } deriving (Parsing) }}} where the class is defined thus {{{ class Alternative m => Parsing m where .... notFollowedBy :: (Monad m, Show a) => m a -> m () notFollowedBy p = try ((try p >>= unexpected . show) <|> pure ()) }}} The error message from the (B) is {{{ [50 of 75] Compiling Idris.ParseHelpers ( src/Idris/ParseHelpers.hs, dist/build/Idris/ParseHelpers.o ) src/Idris/ParseHelpers.hs:40:97: Could not coerce from ‘Monad Parser’ to ‘Monad IdrisInnerParser’ because the first type argument of ‘Monad’ has role Nominal, but the arguments ‘Parser’ and ‘IdrisInnerParser’ differ arising from the coercion of the method ‘notFollowedBy’ from type ‘forall a. (Monad Parser, Show a) => Parser a -> Parser ()’ to type ‘forall a. (Monad IdrisInnerParser, Show a) => IdrisInnerParser a -> IdrisInnerParser ()’ Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Parsing IdrisInnerParser) }}} Answer: no they should not behave differently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8858: Wrong maxStkSize calculation
by GHC 17 Mar '14

17 Mar '14

#8858: Wrong maxStkSize calculation ------------------------------------+------------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When fighting with #8839, I've found what I think is a bug in `maxStkSize` calculation: if `getPhysicalMemorySize` succeeds, we set `maxStkSize` in bytes, not words. It did not manifest itself yet, but I've decided to provide a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8878: Export runTcInteractive from TcRnDriver
by GHC 17 Mar '14

17 Mar '14

#8878: Export runTcInteractive from TcRnDriver -------------------------------------------+------------------------------- Reporter: holzensp | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- For people writing more involved code onto GHC than the normal API (GHC.hs) allows, this is a very useful function. In previous versions of GHC, it has always been unclear to me how I should run the type checker on, for example, a single expression, while keeping the context (i.e. when running the type checker again, the types derived in the former run should still be known in the latter). Simply having runTcInteractive exported does wonders for self-documentation purposes. (patch to follow shortly) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8878> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8888: Document Coercible in user's guide
by GHC 17 Mar '14

17 Mar '14

#8888: Document Coercible in user's guide ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As far as I can tell, there is no discussion of `Coercible` in the User's Guide. Although the interface to `coerce` is essentially a vanilla API, the generation of `Coercible` instances is a language feature, and I believe deserves to be included. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8888> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory
by GHC 17 Mar '14

17 Mar '14

#8839: 64 bit windows executables compiled with ghc-7.8rc2 segfault when allocate more than 4G of memory ----------------------------------+---------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Runtime System | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Consider this: {{{ -- t.hs import System.Environment main :: IO () main = do n <- fmap (read . head) getArgs print $ foldr (+) (0::Int) [0 .. n] }}} Compiled with ghc-7.6.3 and ran thus: {{{ ghc -O2 -rtsopts --make -o t.exe t.hs t.exe +RTS -K4G -RTS 250000000 }}} it works fine! But compiled with 7.8rc2 it segfaults when amount of memory allocated crosses 4G mark. I've discovered this trying to use Agda built with ghc-7.8rc2 but quickly understood this is a general problem and extremely nasty one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8826: Allow more coercions in Safe Haskell
by GHC 17 Mar '14

17 Mar '14

#8826: Allow more coercions in Safe Haskell ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Suppose we have {{{ newtype Age = MkAge Int }}} and we have `m :: Map String Int`. Is `coerce m :: Map String Age` allowed in Safe Haskell? Currently, no, because of the need to have `Map`'s constructor visible at the cite of the coercion. Why do we need this? In order to forestall any possible abstraction breaking. See [https://ghc.haskell.org/trac/ghc/ticket/8745#comment:3 this comment] for more information. But, it would seem that if the writer of `Map` supplies a role annotation, all should be forgiven. The author of the data structure is saying, with `type role Map nominal representational` that it is OK to coerce the second parameter. The annotation means that the author has considered roles and knows what the roles imply. So, I propose this: We allow coercions in Safe Haskell when the following algorithm permits it (and if the coercion is otherwise type-safe): Traverse down the tree of datatype definitions starting at the datatype to be coerced. At every datatype use, check if that datatype has a role annotation. If so, permit the coercion. Otherwise, require all constructors of the datatype to be in scope and recur on any datatypes mentioned in those constructors. Under that algorithm, we quickly discover that `Map` has a role annotation and permit (type-safe) coercions straightaway. This proposal is strictly a loosening of the current rules, and would allow strictly more programs to be accepted as Safe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8