October 2015 - ghc-tickets

[GHC] #10944: powModInteger slower than computing pow and mod separately
by GHC 08 Oct '15

08 Oct '15

#10944: powModInteger slower than computing pow and mod separately -------------------------------------+------------------------------------- Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.3 Libraries | Keywords: integer-gmp | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- {{{#!hs module Foo where import GHC.Integer.GMP.Internals ( powModInteger ) test1, test2 :: Integer -> Integer -> Int -> Integer test1 a b c = (a ^ b) `mod` (2^c) test2 a b c = powModInteger a b (2^c) }}} I was expecting `test2` to perform better than `test1`, but I'm getting quite the opposite: the use of `powModInteger` seems to be several orders of magnitude slower. I have tested this with GHC 7.10.2 and integer-gmp 1.0.0.0 too, with similar results. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10939: Odditites regarding Any and typeclasses.
by GHC 07 Oct '15

07 Oct '15

#10939: Odditites regarding Any and typeclasses. -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- The typechecker seems to be unable to operate on contexts containing "naked" `Any`, for example: {{{#!hs x :: State [Any] () x = put [] }}} {{{ No instance for (MonadState [Any] (StateT [Any] Identity)) arising from a use of ‘put’ }}} A more minimal self-contained example would be: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} import GHC.Prim (Any) class Class a b where method :: a -> b instance Class a a where method = id x :: Any -> Any x = method }}} {{{ No instance for (Class Any Any) arising from a use of ‘method’ }}} It's quite obvious why this error happens (`Any` is not a datatype), however it also feels like it shouldn't happen. All of the above code seems to work in 7.8, which is back when `Any` was a datatype. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9058: System.IO.openTempFile does not scale
by GHC 07 Oct '15

07 Oct '15

#9058: System.IO.openTempFile does not scale ------------------------------------+------------------------------------- Reporter: slyfox | 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: | ------------------------------------+------------------------------------- In search of a bug in darcs http://bugs.darcs.net/issue2364 i've notice very bad property of openTempFile: it's pattern is very predictable and has O(n^2) of already created temp files. Predictability allows very fun bugs survive in buggy programs, like: {{{ thread1: (fn, fh) <- openTempFile "." "hello" renameFile fn "something" -- some time after when (some_rare_buggy_condition) $ -- oops, reused temp name, but too late, other thread killed it writeFileFile fn thread2: (fn, fh) <- openTempFile "." "hello" workWithFn fn -- nobody should touch it, right? }}} It's _very_ hard to debug data corruption when all temp files are named "foo${pid}" and sometimes "foo${pid+1}". And more serious bug: the more threads you have trying to create similar temps performance drops significantly: Attached program shows the following numbers: {{{ $ time ./bench-temps same 2000 real 0m2.795s user 0m1.516s sys 0m1.190s $ time ./bench-temps diff 2000 real 0m0.161s user 0m0.043s sys 0m0.115s }}} It's O(N^2) growing open() storm. https://github.com/ghc/ghc/blob/master/libraries/base/System/IO.hs#L465 {{{ FileExists -> findTempName (x + 1) }}} This is the source of the problem. I'd suggest always using random name for it. For portability reasons I suggest adding at least insecure random '''rand()''' value from C library. That way we will succeed in opening temp file at the first attempt. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8364: equip GHC with an accurate internal model of floating point
by GHC 07 Oct '15

07 Oct '15

#8364: equip GHC with an accurate internal model of floating point ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- currently there really isn't a systematic / portable story for doing compile time reduction / evaluation for floating point numbers. there are some folks in the larger haskell community who are working on high precision soft float implementations / modelling. Once that work becomes available, might be worth exploring having something like that for doing controlled high precision evaluation of intermediate expressions in ghc proper. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10687: Clang 3.6 fails with -g due to .file directive order
by GHC 07 Oct '15

07 Oct '15

#10687: Clang 3.6 fails with -g due to .file directive order -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On Mac Os X, compiling with `-g` will sometimes fail with an error like follows: {{{ /var/folders/yt/bmbchswn57nbmz1l67btd6p00000gn/T/ghc27418_0/ghc_1.s:6573:7: error: error: unassigned file number in '.loc' directive .loc 7 106 17 /* cast */ ^ }}} Which refers to the following code: {{{ [...] .file 7 "libraries/base/Data/Typeable.hs" .file 6 "libraries/ghc-prim/GHC/Classes.hs" [...] .loc 7 106 17 /* cast */ }}} So the file number is clearly assigned, we are just not assigning them "in order". This is okay for most compilers, but Clang 3.6 seems to disagree. The attached patch changes the code so `.file` directives are always generated in order. Could try to produce a testcase if required - it would be rather easy to check that `.file` directives appear in order in a given assembly file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7830: Error: operand out of range
by GHC 06 Oct '15

06 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Comment (by trommler): Sorry, I hope this is right now. The attached patch needs to be commited onto branch ghc-7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 06 Oct '15

06 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by trommler): * status: patch => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 06 Oct '15

06 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 06 Oct '15

06 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => * status: closed => new * resolution: fixed => Comment: Added patch for merge error in commit:e22d7dc. Please merge onto ghc-7.10 branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 06 Oct '15

06 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by trommler): * Attachment "0001-Fix-merge-error.patch" added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0