July 2015 - ghc-tickets

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 26 Jul '15

26 Jul '15

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => base/tests/T8089 * os: Unknown/Multiple => Windows Comment: The issue around `threadDelay maxBound` on OS X is I think fixed. At least, #8089 added a test for it, which is supposedly passing on OS X. That makes this a Windows only problem now. Unexpected failures: . T8089 [bad exit code] (normal,hpc,optasm) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9982: cross building integer-gmp is running target program on build host
by GHC 26 Jul '15

26 Jul '15

#9982: cross building integer-gmp is running target program on build host -------------------------------------+------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Operating System: Linux Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I am trying to build ghc-7.8.4 as a cross compiler. After stage1 finishes and it tries to build libraries it detects that it can link against an existing -gmp and gmp.h (which is what I intended) and starts building the libraries/integer-gmp package against it. During the build it builds the inplace/lib/bin/mkGmpDerivedConstants binary for the target (genode) and then runs it on the build host (ubuntu linux), which leads to failure. The error emitted during the build is: "cp" -p libraries/integer- gmp/mkGmpDerivedConstants/dist/build/tmp/mkGmpDerivedConstants inplace/lib/bin/mkGmpDerivedConstants "rm" -f inplace/lib/mkGmpDerivedConstants echo '#!/bin/bash' >> inplace/lib/mkGmpDerivedConstants echo 'executablename="/u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib/bin/mkGmpDerivedConstants"' >> inplace/lib/mkGmpDerivedConstants echo 'datadir="/u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib"' >> inplace/lib/mkGmpDerivedConstants echo 'bindir="/u1/home/newsham/src/genode/ghc-7.8.4/inplace/bin"' >> inplace/lib/mkGmpDerivedConstants echo 'topdir="/u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib"' >> inplace/lib/mkGmpDerivedConstants echo 'pgmgcc="/u1/home/newsham/src/genode/ghc-7.8.4/wrapper-gcc"' >> inplace/lib/mkGmpDerivedConstants echo 'export LD_LIBRARY_PATH=":$LD_LIBRARY_PATH"' >> inplace/lib/mkGmpDerivedConstants echo 'exec "$executablename" ${1+"$@"}' >> inplace/lib/mkGmpDerivedConstants chmod +x inplace/lib/mkGmpDerivedConstants inplace/lib/mkGmpDerivedConstants > libraries/integer- gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h inplace/lib/mkGmpDerivedConstants: line 8: /u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib/bin/mkGmpDerivedConstants: No such file or directory make[1]: *** [libraries/integer- gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h] Error 127 make[1]: *** Deleting file `libraries/integer- gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h' make: *** [all] Error 2 my build environment is large and complex so I'm not providing all details here, but I will be happy to provide any supporting material needed, on request. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5916: runST isn't free
by GHC 26 Jul '15

26 Jul '15

#5916: runST isn't free -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_run/runST Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * testcase: => simplCore/should_run/runST -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5916#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 25 Jul '15

25 Jul '15

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, | evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D615 -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D615 Comment: In commit de9a836cd920722a4c28dcb464ff2c8d5905acb9: {{{ Author: Roman Cheplyaka <> Date: Mon Feb 9 13:44:03 2015 -0600 Clarify the documentation for 'evaluate' Summary: See: https://www.haskell.org/pipermail/ghc-devs/2015-January/007900.html https://ghc.haskell.org/trac/ghc/ticket/5129#comment:17 Reviewers: hvr, Mikolaj, austin Reviewed By: Mikolaj, austin Subscribers: ezyang, nomeata, thomie Differential Revision: https://phabricator.haskell.org/D615 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied
by GHC 25 Jul '15

25 Jul '15

#9267: Lack of type information in GHC error messages when the liberage coverage condition is unsatisfied -------------------------+------------------------------------------------- Reporter: | Owner: danilo2 | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Hello! The problem is not a bug related to proper code execution, but it affects the development in such way, we can treat it as a bug. Lets think about such simple code (it can be further simplified of course): {{{#!haskell {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} data UnsafeBase base err val = Value val | Error err | Other (base val) deriving (Show, Eq) class MagicMerge m1 m2 | m1 -> m2 where magicMerge :: m1 a -> m2 a instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase base err) where magicMerge ma = case ma of Value a -> Value a Error e -> Error e Other o -> o instance MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1) where magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma of Value a -> Value a Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) Other o -> case o of Value a -> Other $ magicMerge (Value a :: UnsafeBase base err2 a) Error e -> Error e Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base err2 a) main = print "help me world!" }}} When trying to compile it using GHC-7.8, we get following error message: {{{#!haskell Illegal instance declaration for ‘MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1)’ The liberal coverage condition fails in class ‘MagicMerge’ for functional dependency: ‘m1 -> m2’ Reason: lhs type ‘UnsafeBase (UnsafeBase base err1) err2’ does not determine rhs type ‘UnsafeBase dstBase err1’ In the instance declaration for ‘MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1)’ }}} Which is of course right, but it is completely unhelpfull! When we run the same program against GHC-7.6, we get another message: {{{#!haskell No instance for (MagicMerge (UnsafeBase base err2) dstBase) arising from a use of `magicMerge' Possible fix: add an instance declaration for (MagicMerge (UnsafeBase base err2) dstBase) In the second argument of `($)', namely `magicMerge (Error e :: UnsafeBase base err2 a)' In the expression: Other $ magicMerge (Error e :: UnsafeBase base err2 a) In a case alternative: Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) }}} And it contains a very helpfull information about inferred types. The information is very helpfull, especialy with more complex instances. What is VERY IMPORTANT, when we use the inferred type, the code starts working in both, GHC-7.8 and GHC-7.6. Right now I have to use both versions of GHC to be able to develop my instances faster. So If we add the inferred by GHC-7.6 premise: {{{#!haskell {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} data UnsafeBase base err val = Value val | Error err | Other (base val) deriving (Show, Eq) class MagicMerge m1 m2 | m1 -> m2 where magicMerge :: m1 a -> m2 a instance MagicMerge (UnsafeBase (UnsafeBase base err) err) (UnsafeBase base err) where magicMerge ma = case ma of Value a -> Value a Error e -> Error e Other o -> o instance (MagicMerge (UnsafeBase base err2) dstBase) => MagicMerge (UnsafeBase (UnsafeBase base err1) err2) (UnsafeBase dstBase err1) where magicMerge (ma :: UnsafeBase (UnsafeBase base err1) err2 a) = case ma of Value a -> Value a Error e -> Other $ magicMerge (Error e :: UnsafeBase base err2 a) Other o -> case o of Value a -> Other $ magicMerge (Value a :: UnsafeBase base err2 a) Error e -> Error e Other o' -> Other $ magicMerge (Other o' :: UnsafeBase base err2 a) main = print "help me world!" }}} The code compiles and works ok in both GHC-7.6 and GHC-7.8. In such cases, GHC-7.8 should inform about lacking premises. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10378: min/max for Double/Float instances are incorrect
by GHC 25 Jul '15

25 Jul '15

#10378: min/max for Double/Float instances are incorrect -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is similar to many other numeric issues around `Double`s and `Float`s. The IEEE754 requires `min` and `max` on floats to return the "other" number, if one of the arguments is `NaN`. The default definitions used in Haskell does not satisfy this property. Furthermore, the current definitions are not commutative, when given `NaNs` and `-0` arguments. The following cases demonstrate the issue with `max`, but `min` has the exact same problems. {{{#!hs Prelude> (0/0) `max` 5 NaN Prelude> 5 `max` (0/0) 5.0 Prelude> isNegativeZero ((-0) `max` 0) False Prelude> isNegativeZero (0 `max` (-0)) True }}} It wouldn't be hard to fix the definitions appropriately; here are reference implementations that are IEEE754 compliant: {{{#!hs maxH x y | isNaN x = y | isNaN y = x | x > y || (x == y && isNegativeZero y) = x | True = y minH x y | isNaN x = y | isNaN y = x | x < y || (x == y && isNegativeZero x) = x | True = y }}} Note that these reference implementations would be quite expensive if GHC were to use them directly. Luckily, IEEE754 compliant min/max operations are supported by all modern CPUs, so doing the "right" thing here is also the cheaper thing as well. (i.e., it'll even be faster than the current incorrect implementation.) On platforms that do not have hardware implementations, the above definitions can serve as the correct implementations, albeit they'll be slower. (Embedded devices, perhaps.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10546: conc034 is failing with a Core Lint error
by GHC 25 Jul '15

25 Jul '15

#10546: conc034 is failing with a Core Lint error -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ =====> conc034(threaded2) 78 of 99 [0, 0, 0] cd . && "/home/smarlow/ghc/inplace/bin/ghc-stage2" -o conc034 conc034.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -O -threaded -eventlog > conc034.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( conc034.hs, conc034.o ) *** Core Lint errors : in result of Simplifier *** <no location info>: warning: In the expression: seq @ e10_a1ZF @ (# State# RealWorld, () #) e2_a1ZN (# eta_X16, () #) Kinds don't match in type application: Type variable: b_13 :: * Arg type: (# State# RealWorld, () #) :: # xx # }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10313: ApiAnnotations : strings in warnings do not return SourceText
by GHC 25 Jul '15

25 Jul '15

#10313: ApiAnnotations : strings in warnings do not return SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `strings` used in a `WARNING` pragma are captured via {{{ strings :: { Located ([AddAnn],[Located FastString]) } : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) } .. }}} The `STRING` token has a method `getSTRINGs` that returns the original source text for a string. A warning of the form {{{#!hs {-# WARNING Logic , mkSolver , mkSimpleSolver , mkSolverForLogic , solverSetParams , solverPush , solverPop , solverReset , solverGetNumScopes , solverAssertCnstr , solverAssertAndTrack , solverCheck , solverCheckAndGetModel , solverGetReasonUnknown "New Z3 API support is still incomplete and fragile: \ \you may experience segmentation faults!" #-} }}} returns the concatenated warning string rather than the original source. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10313> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8327: Cmm sinking does not eliminate dead code in loops
by GHC 25 Jul '15

25 Jul '15

#8327: Cmm sinking does not eliminate dead code in loops ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Cmm code shown in #8326 is suboptimal. For this Haskell code: {{{ isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} we get Cmm that contains dead code in a loop: {{{ cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} Notice that `_sEV` is dead - we should optimize it away. This is a known deficiency in the Cmm sinking pass (i.e. it does not work for loops). I'm putting this on Trac so we have this documented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail
by GHC 25 Jul '15

25 Jul '15

#8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I have encountered a strange occurrence with GHC that was causing several GHC job failures on an SGE cluster. It turned out that there were other SGE users who needed an absurdly large stack size limit (set via 'ulimit -s') in the several gigabytes range. The default stack size limit had to be raised for the entire cluster. Any job that was run on a machine where the virtual memory limit was less than or equal to 2X the stack size limit, GHC would crash with the following message: ghc: failed to create OS thread: Cannot allocate memory I am running on GHC 7.6.3 with a 64-bit RedHat Enterprise OS, version 5.5. To reproduce the error, I was able to create the following test case: [ ~]$ ulimit -v unlimited [ ~]$ ulimit -s 10240 [ ~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 [ ~]$ ulimit -v 200000 [ ~]$ ulimit -s 100000 [ ~]$ ghc --version ghc: failed to create OS thread: Cannot allocate memory Several other programs work find using these settings, but GHC consistently has problems. Is this a fundamental issue with how GHC operates or can this be addressed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7