July 2015 - ghc-tickets

[GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs
by GHC 19 Oct '15

19 Oct '15

#9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Like many programming language environments, GHC offers a handy `-e` option for evaluating an expression, then returning to the shell. {{{ $ ghc -e '2 + 2' 4 }}} One would expect the interpreter, GHCi, to offer a similar flag, but it surprisingly rejects it. {{{ ghci -e '2 + 2' ghc: on the commandline: cannot use `--interactive' with `-e' Usage: For basic information, try the `--help' option. }}} I think this behavior is quite unintuitive--when I pass `-e <exp>` to ghci, or pass `--interactive -e <exp>` to ghc, I expect the expression to be evaluated as the leading expression in an interactive interpreter session. Could we please tweak ghc like this to make it slightly more intuitive when these flags are used together? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10714: After implementing new installed package ID (hash of sdist), get rid of package keys
by GHC 15 Oct '15

15 Oct '15

#10714: After implementing new installed package ID (hash of sdist), get rid of package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.10.2 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC tracking bug for https://github.com/haskell/cabal/issues/2745 Externally, GHC's flags do not have to change much; a user simply passes the installed package ID to the flag currently named `-this-package-key` (but perhaps we should rename this.) Internally, if we can assume that `PackageKey == InstalledPackageId`, we can do away with the `InstalledPackageId` map and get rid of the level of indirection between the bin-pkg-db (which records installed package IDs`) and GHC's guts (which record package keys). Blocked on Cabal not actually using ABI hashes to identify packages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10216: Allow arr ∧ (first ∨ (***)) as minimal definition of Arrow instance
by GHC 13 Oct '15

13 Oct '15

#10216: Allow arr ∧ (first ∨ (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10611: Runtime crash while running psc
by GHC 12 Oct '15

12 Oct '15

#10611: Runtime crash while running psc -------------------------------------+------------------------------------- Reporter: qxjit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Got a runtime crash while running the purescript compiler: psc: internal error: evacuate(static): strange closure type 6647784 (GHC version 7.8.3 for x86_64_unknown_linux) As yet I have not be able to reproduce it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts
by GHC 10 Oct '15

10 Oct '15

#10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts -------------------------------------+------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- For numbers other than 1, anyway. {{{ $ ghc -e 'Data.Bits.shiftL 1 (-1)' -9223372036854775808 $ ghc -e 'Data.Bits.shiftL 2 (-1)' zsh: segmentation fault ghc -e 'Data.Bits.shiftL 2 (-1)' $ ghc -e 'Data.Bits.shiftL 100 (-1)' zsh: segmentation fault ghc -e 'Data.Bits.shiftL 100 (-1)' }}} This also happens with a compiled program. It doesn't with {{{shiftR}}} in either case though. Side notes: - On OS X, when the first operand is also negative, I get a {{{bus error}}} instead of a {{{segmentation fault}}}. Linux gives {{{segmentation fault}}} on both. - On Linux, you have to use {{{ghci}}} instead of {{{-e}}}, for some (probably unrelated?) reason). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9319: nofib-analyze doesn’t provide per-benchmark compile time/alloc numbers
by GHC 08 Oct '15

08 Oct '15

#9319: nofib-analyze doesn’t provide per-benchmark compile time/alloc numbers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.8.2 suite | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- The compile time and allocation numbers calculated by nofib are only available per module. While this is useful to find the cause of problems, it would be nice if these numbers were also accumulated for each benchmark, for easy of general analysis and uniformity, especially with automated monitoring of benchmark numbers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10153: GHC mode for converting files to explicit layout
by GHC 08 Oct '15

08 Oct '15

#10153: GHC mode for converting files to explicit layout -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- One area where GHC is a little less friendly to newcomers is its Byzantine whitespace layout rules. Once you've gotten used to using GHC you can usually get what you want by abiding certain style, but before then it might be useful to see how GHC is inserting semicolons to your document. I don't think this would be too hard to do. The idea is to get the token stream and look for virtual curlies with no location. Once you have a list of them, you can go over the original buffer again and insert a brace or semicolon whenever you see a token like this. Might be a good beginner task. This function would also be useful for debugging layout, since knowing if semicolons are being inserted is useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10153> 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