June 2014 - ghc-tickets

[GHC] #8626: Bad magic. Expected: feedfacf, got: feedface
by GHC 06 Nov '14

06 Nov '14

#8626: Bad magic. Expected: feedfacf, got: feedface ----------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- Loading package base-unicode-symbols-0.2.2.4 ... <interactive>: /Users/paulo/Library/Haskell/ghc-7.6.3/lib/base-unicode- symbols-0.2.2.4/lib/HSbase-unicode-symbols-0.2.2.4.o: Bad magic. Expected: feedfacf, got: feedface. ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): loadObj "/Users/paulo/Library/Haskell/ghc-7.6.3/lib/base-unicode- symbols-0.2.2.4/lib/HSbase-unicode-symbols-0.2.2.4.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9011: panic - interactiveUI:setBuffering2
by GHC 06 Nov '14

06 Nov '14

#9011: panic - interactiveUI:setBuffering2 ----------------------------------+------------------------------- Reporter: irneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- I've looked through some other tickets and tried installing libffi5, though in my distro (Kubuntu 13.10 x86-64) only libffi6 is available. Even after installing that I get the following: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): interactiveUI:setBuffering2 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9011> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9211: Untouchable type variable (regression from 7.6)
by GHC 04 Nov '14

04 Nov '14

#9211: Untouchable type variable (regression from 7.6) ------------------------------------+------------------------------------- Reporter: simonpj | 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: | ------------------------------------+------------------------------------- Oleg says: what used to type check in GHC 7.4.1 (and I think in 7.6.2, although I no longer have access to that version) fails in GHC 7.8.2. The following program type-checks with GHC 7.4.1 and GHC 7.8.2: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module T where foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] -- foo :: (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] foo tr x = tr x t = foo (fmap not) [True] }}} The following code (which differs only in the signature of foo) {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module T where -- foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] foo :: (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] foo tr x = tr x t = foo (fmap not) [True] }}} type-checks with 7.4.1 but not with 7.8.2. The latter reports the error {{{ Couldn't match type `b' with `Bool' `b' is untouchable inside the constraints (Functor f, g ~ f) bound by a type expected by the context: (Functor f, g ~ f) => g Bool -> g b at /tmp/t.hs:12:5-25 `b' is a rigid type variable bound by the inferred type of t :: [b] at /tmp/t.hs:12:1 Expected type: Bool -> b Actual type: Bool -> Bool Relevant bindings include t :: [b] (bound at /tmp/t.hs:12:1) In the first argument of `fmap', namely `not' In the first argument of `foo', namely `(fmap not)' }}} Giving `t` the type signature `[Bool]` fixes the problem. Alas, I come across the similar untouchable error in situations where giving the type signature is quite difficult (in local bindings, with quite large types). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9081: Template Haskell gets confused with scoped kind variables in a class declaration
by GHC 04 Nov '14

04 Nov '14

#9081: Template Haskell gets confused with scoped kind variables in a class declaration ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: | ------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TemplateHaskell, DataKinds, PolyKinds, TypeFamilies #-} module Bug where import Data.Proxy $( [d| class kproxy ~ 'KProxy => C (kproxy :: KProxy a) where type TF (x :: a) :: Bool |]) }}} I get {{{ /Users/rae/temp/Bug.hs:7:4: Kind variable also used as type variable: ‘a_asJA’ In the declaration for class C_asJy /Users/rae/temp/Bug.hs:7:4: The exact Name ‘kproxy_asJB’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful }}} The code in the TH quote compiles fine on its own. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8482: Permission denied when copying file to current directory with copyFile
by GHC 03 Nov '14

03 Nov '14

#8482: Permission denied when copying file to current directory with copyFile -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/directory | Operating System: Windows Keywords: copyFile | Type of failure: Incorrect result permission denied | at runtime Architecture: x86 | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- While the MS-DOS command {{{ C:\tmp\b>copy c:\tmp\a\x }}} runs successfully, the Haskell equivalent {{{ copyFile "c:\\tmp\\a\\x" "" }}} results in {{{ copyFile.hs: .\.copyFile584.tmp: copyFile: does not exist (Het systeem kan het opgegeven pad niet vinden.) }}} The Dutch explanation says: "The system can not find the specified path" {{{ copyFile "c:\\tmp\\a\\x" "." }}} results in {{{ copyFile.hs: .\.copyFile3960.tmp: copyFile: permission denied (Toegang geweigerd.) }}} The Dutch explanation says: "Access denied" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2
by GHC 03 Nov '14

03 Nov '14

#8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 -----------------------------------+--------------------------------------- Reporter: MichalGajda | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: cabal install hPDB Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- GHC 7.8 rc2 exhausts all memory on `Bio.PDB.EventParser.PDBEventParser` module in -O3 mode, but not in -O2 mode. The tail of ''-v3'' input seems to indicate that it dies during SpecConstr phase. The module successfully compiled with below 2GB RAM since GHC 6.12, so I wonder why the memory use exploded with the most recent version. *** SpecConstr: ==================== SpecConstr ==================== Result size of SpecConstr STEPS TO REPRODUCE: 1. `cabal install hPDB` RESULT EXPECTED: Successful compilation and installation CURRENT RESULT: Exhausts available memory and crashes when compiling `Bio.PDB.EventParser.PDBEventParser`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8819: Testsuite failures in 7.8 RC1
by GHC 03 Nov '14

03 Nov '14

#8819: Testsuite failures in 7.8 RC1 ------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | ------------------------------------+------------------------------------- With the recent patches applied to RC1 I managed to bootstrap an unregisterised ghc. Running the testsuite I get the following failures on Linux x86_64: {{{ Unexpected failures: ../../libraries/base/tests fixed [bad stdout] (normal) ../../libraries/base/tests/Numeric num010 [bad stdout] (normal) ../../libraries/process/tests process007 [bad exit code] (normal) codeGen/should_compile T7574 [stderr mismatch] (normal) codeGen/should_gen_asm memcpy [asm mismatch] (normal) codeGen/should_gen_asm memcpy-unroll [asm mismatch] (normal) codeGen/should_gen_asm memcpy-unroll-conprop [asm mismatch] (normal) codeGen/should_run T2838 [bad stdout] (normal) lib/integer integerBits [bad stdout] (normal) lib/integer integerConversions [bad stdout] (normal) numeric/should_run T8726 [bad exit code] (normal) numeric/should_run arith002 [bad stdout] (normal) numeric/should_run arith003 [bad stdout] (normal) numeric/should_run arith004 [bad stdout] (normal) numeric/should_run arith005 [bad stdout] (normal) numeric/should_run arith011 [bad stdout] (normal) numeric/should_run arith012 [bad stdout] (normal) numeric/should_run arith014 [bad stdout] (normal) parser/should_run readRun002 [bad stdout] (normal) perf/compiler T1969 [stat too good] (normal) perf/compiler T3064 [stat too good] (normal) perf/compiler T783 [stat too good] (normal) perf/should_run T3736 [bad stderr] (normal) rts T5423 [bad stderr] (normal) rts T7815 [bad exit code] (threaded1) safeHaskell/check/pkg01 safePkg01 [bad stderr] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8849: Unregisterised compiler: arithmetic failure
by GHC 03 Nov '14

03 Nov '14

#8849: Unregisterised compiler: arithmetic failure --------------------------+------------------------------------------------ Reporter: | Owner: trommler | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: arith005 Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #8819 | --------------------------+------------------------------------------------ Compiling the following with RC2 on powerpc 64 downloaded from haskell.org: {{{ main = putStr $ show (-1.0000000001 :: Double) }}} Setting {{{-O}}} yields: {{{ 0.0 }}} Without optimization the correct result is displayed. I prepared an unregisterised compiler on amd64 and see the same issue and more arithmetic tests fail in testsuite. In fact I took the above from arith005. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8849> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9246: GHC generates poor code for repeated uses of min/max
by GHC 02 Nov '14

02 Nov '14

#9246: GHC generates poor code for repeated uses of min/max ------------------------------+-------------------------------------------- Reporter: arotenberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #6135 | ------------------------------+-------------------------------------------- Consider the following module, which intends to implement a [http://tavianator.com/2011/05/fast-branchless-raybounding-box- intersections/ branchless ray-AABB intersection test]: {{{ module SimpleGeom where data Vec3 = Vec3 {-# UNPACK #-} !Double {-# UNPACK #-} !Double {-# UNPACK #-} !Double data Ray = Ray !Vec3 !Vec3 !Vec3 data AABB = AABB !Vec3 !Vec3 testRayAABBIntersection :: Ray -> AABB -> Bool testRayAABBIntersection (Ray (Vec3 ox oy oz) _ (Vec3 invDx invDy invDz)) (AABB (Vec3 minX minY minZ) (Vec3 maxX maxY maxZ)) = let tx1 = (minX - ox) * invDx tx2 = (maxX - ox) * invDx ty1 = (minY - oy) * invDy ty2 = (maxY - oy) * invDy tz1 = (minZ - oz) * invDz tz2 = (maxZ - oz) * invDz tmin = min tx1 tx2 `max` min ty1 ty2 `max` min tz1 tz2 tmax = max tx1 tx2 `min` max ty1 ty2 `min` max tz1 tz2 in tmax >= max 0 tmin }}} Everything is strict primitive operations, so GHC should generate very simple, fast code, right? But upon compiling with {{{ghc -O -ddump-simpl -ddump-to-file SimpleGeom}}}, I found a mess of nested local lambdas and similar performance-killing expression forms. (See the attached output file.) There are two possible issues I can see here. 1. GHC is trying to expand out all of the branches recursively (I would presume via case-of-cases transformation), which is a bad idea in this instance compared to just performing the cases sequentially and storing their results. 1. GHC is generating branches for floating-point min/max. Instruction sets like SSE2 include non-branching floating-point min/max instructions, which is exactly what this algorithm was designed to exploit, but GHC does not generate code that could take advantage of these instructions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9246> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8261: Windows Testsuite stuck at configuring timeout
by GHC 02 Nov '14

02 Nov '14

#8261: Windows Testsuite stuck at configuring timeout ------------------------------+--------------------------------- Reporter: leroux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+--------------------------------- When running the testsuite, it gets stuck at {{{Configuring timeout-1...}}}. I tried adding a verbosity flag to the ENV vars, but they didn't make any affect on the {{{./Setup}}} args. Relating to my development setup...I've followed the instructions from http://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows (using MinGW). I was rather surprised when I was building GHC, it threw an error saying that "libmpfr-3.dll" was missing, so I fetched that from a cygwin mirror and threw it in {{{msys/bin}}}, but even after doing that, I got errors saying that it could find certain cygwin libraries ({{{cyg*.dll}}}). So I just installed the entirety of cygwin and it started working fine. The only ticket I found that is related to this is #1599, but I'm not sure. ---- System details: {{{ # Windows 7 x86 (32-bit) $ uname -a MINGW32_NT-6.1 LEROUX-WINBUILD 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys $ echo $PATH /c/MinGW/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files/Haskell/bin:/c/Program Files/Haskell Platform/2013.2.0.0/lib/extralibs/bin:/c/ Program Files/Haskell Platform/2013.2.0.0/bin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v 1.0/:/c/Program Files/Haskell Platform/2013.2.0.0/mingw/bin:/c/Program Files/Git/cmd:/c/Users/leroux/AppData/Roaming/cabal/bin:/mingw/bin:/us r/bin:/c/cygwin/bin }}} ---- Here's the testsuite run: {{{ $ make test WAY=normal make -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt fast make[1]: Entering directory `/home/leroux/devel/ghc- validate/testsuite/tests' make fast=YES make[2]: Entering directory `/home/leroux/devel/ghc- validate/testsuite/tests' Looks like you don't have timeout, building it first... make -C ../timeout all make[3]: Entering directory `/home/leroux/devel/ghc- validate/testsuite/timeout' rm -rf install-inplace 'C:/MinGW/msys/1.0/home/leroux/devel/ghc-validate/inplace/bin/ghc- stage2.exe' --make Setup ./Setup configure --with-compiler='C:/MinGW/msys/1.0/home/leroux/devel /ghc-validate/inplace/bin/ghc-stage2.exe' \ --with-hc- pkg='C:/MinGW/msys/1.0/home/leroux/devel/ghc-validate/inplace/bin/ghc- pkg.exe' \ --with- hsc2hs='C:/MinGW/msys/1.0/home/leroux/devel/ghc- validate/inplace/bin/hsc2hs.exe' \ \ --ghc-option=-threaded --prefix='C:/MinGW/msys/1.0/home/leroux/devel/ghc- validate/testsuite/timeout/install-inplace ' Configuring timeout-1... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11