March 2014 - ghc-tickets

[GHC] #8600: ghc --help is outdated
by GHC 22 Mar '14

22 Mar '14

#8600: ghc --help is outdated ------------------------------------+------------------------------------- Reporter: Feuerbach | 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: | ------------------------------------+------------------------------------- {{{ To compile and link a complete Haskell program, run the compiler like so: ghc --make Main where the module Main is in a file named Main.hs (or Main.lhs) in the current directory. The other modules in the program will be located and compiled automatically, and the linked program will be placed in the file `a.out' (or `Main.exe' on Windows). }}} First, --make is no longer necessary. Second, ghc doesn't create a.out on Unix — instead, the file is named the same as the main module (Main in that example). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8884: Reifying closed type families is broken
by GHC 22 Mar '14

22 Mar '14

#8884: Reifying closed type families is broken ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | 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: | ------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies, PolyKinds #-} module Scratch where import Language.Haskell.TH type family Foo a where Foo x = x $( do FamilyI foo [] <- reify ''Foo runIO $ putStrLn $ show foo return [] ) }}} and compile, I see (with uniques suppressed) {{{ ClosedTypeFamilyD Scratch.Foo [KindedTV a (VarT k)] (Just (AppT (AppT ArrowT (VarT k)) (VarT k))) [TySynEqn [VarT k,VarT x] (VarT x)] }}} There are two problems here: 1. The return kind (the third parameter to `ClosedTypeFamilyD`) should be just that -- the return kind. In the output, we see the full kind of the type family. `k -> k`. 2. The equation includes the kind variable `k`, which should be implicit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8884> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8738: msys2 fails cabal01 test
by GHC 22 Mar '14

22 Mar '14

#8738: msys2 fails cabal01 test --------------------------+------------------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test | Version: 7.8.1-rc1 Suite | Operating System: Windows Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: cabal01 Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ msys2 with 64-bit GHC has an odd failure here: {{{ =====> cabal01(normal) 81 of 3859 [0, 0, 0] cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 VANILLA =--enable-library-vanilla PROF=--disable-library-profiling DYN=--disable- shared </dev/null >cabal01.run.stdout 2>cabal01.run.stderr Actual stdout output differs from expected: --- ./cabal/cabal01/cabal01.stdout-mingw32 2014-02-02 04:48:11.233000000 +0000 +++ ./cabal/cabal01/cabal01.run.stdout 2014-02-05 03:09:28.998400000 +0000 @@ -1,9 +1,9 @@ install1: bin -test-1.0 +x86_64-windows-ghc-7.9.20140205 install2: bin -test-1.0 +x86_64-windows-ghc-7.9.20140205 dist: build package.conf.inplace }}} This is because setup is selecting this directory as the location for the installation: {{{ /inplace/bin/ghc-pkg.exe' --package- db=local.db'C:/msys64/home/Administrator/ghc Configuring test-1.0... Warning: No 'build-type' specified. If you do not need a custom Setup.hs or ./configure script then use 'build-type: Simple'. Dependency base >=1.0: using base-4.7.0.0 "C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe" "--info" Using Cabal-1.18.1.3 compiled by ghc-7.9 Using compiler: ghc-7.9.20140205 Using install prefix: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install Binaries installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin Libraries installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Private binaries installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\test-1.0 Data files installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Documentation installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\doc\x86_64 -windows-ghc-7.9.20140205\test-1.0 Configuration files installed in: C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\etc Administrator@EZYANG-W2K8 ~/ghc/testsuite/tests/cabal/cabal01 $ ./setup.exe copy -v directory dist\doc\html\test does exist: False Installing library in C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Installing executable(s) in C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin Warning: The directory C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin is not in the system search path. creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0\B Installing dist\build\A.hi to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\A.hi Installing dist\build\B\A.hi to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\B\A.hi creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Installing dist\build\libHStest-1.0.a to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\libHStest-1.0.a creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64 -windows-ghc-7.9.20140205\test-1.0 Installing dist\build\HStest-1.0.o to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64 -windows-ghc-7.9.20140205\test-1.0\HStest-1.0.o creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\bin Installing executable dist\build\testA\testA.exe to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testA.exe C:\msys64\ghc-7.6.3\mingw\bin\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testA.exe creating C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\bin Installing executable dist\build\testB\testB.exe to C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testB.exe C:\msys64\ghc-7.6.3\mingw\bin\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testB.exe }}} Perhaps a cabal developer can stare at the relevant codepath and figure out why this directory name is being selected? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8738> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 22 Mar '14

22 Mar '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged in HEAD and 7.8 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 22 Mar '14

22 Mar '14

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by hvr): * status: closed => merge Comment: I'll mark this for merge (if not 7.8.1 then it might make it into 7.8.2) and let Austin decide -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 22 Mar '14

22 Mar '14

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by rwbarton): Any particular reason not to merge to 7.8? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 22 Mar '14

22 Mar '14

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by tibbe): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 22 Mar '14

22 Mar '14

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): I've applied rwbarton's patch, which means that we implement the semantics I described above, just like I originally intended (and just like the -msse4.2 version behaves). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 22 Mar '14

22 Mar '14

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by Johan Tibell <johan.tibell@…>): In [changeset:"ad9bf96815cb5a9bb4acc51c99eff20be3e50da3/ghc-prim"]: {{{ #!CommitTicketReference repository="ghc-prim" revision="ad9bf96815cb5a9bb4acc51c99eff20be3e50da3" Make argument types in popcnt.c match declared primop types On 64-bit Mac OS, gcc 4.2 (which comes with Xcode 4.6) generates code that assumes that an argument that is smaller than the register it is passed in has been sign- or zero-extended. But ghc thinks the types of the PopCnt*Op primops are Word# -> Word#, so it passes the entire argument word to the hs_popcnt* function as though it was declared to have an argument of type StgWord. Segfaults ensue. The easiest fix is to sidestep all this zero-extension business by declaring the hs_popcnt* functions to take a whole StgWord (when their argument would fit in a register), thereby matching the list of primops. Fixes #7684. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 22 Mar '14

22 Mar '14

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): I chatted a bit with rwbarton about the semantics of these primops. My intention is that all the primops work on all input sizes (much like the underlying assembly instruction) and the difference is just the number of bit we count. The code implements this behavior correctly, if it weren't for LLVM misbehaving. The reason I implemented the primops this way is that I wanted to avoid the narrowing. This means that even if we had a `Word8#` type, the primops would still operate on a `Word#`. Does that make sense? If so the right fix is to work around the LLVM bug in `popcnt.c`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0