March 2018 - ghc-tickets

Re: [GHC] #4442: Add unaligned version of indexWordArray#
by GHC 10 Mar '18

10 Mar '18

#4442: Add unaligned version of indexWordArray# -------------------------------------+------------------------------------- Reporter: tibbe | Owner: reinerp Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14447 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by reinerp): * owner: (none) => reinerp -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4442#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14769: The RecompBecause [TH] check is not resume-build-safe
by GHC 09 Mar '18

09 Mar '18

#14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #481 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ghc --make` aims to make compilation behave correctly and produce up-to- date, no matter whether it completes or is interrupted (e.g. with Ctrl+C) and later resumed At no point should interrupting a build and running it again produce "less correct" outputs than running it to the end; specifically interrupting shouldn't result in necessary build steps to be "forgotten". However, this seems to be the case with the `[TH]` check introduced in #481. Minimal test case with 3 files: https://github.com/nh2/th-recomp-test Good behaviour when running without interrupting: {{{ % touch A.hs && ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [TH] [3 of 3] Compiling Main ( Main.hs, Main.o ) [TH] Linking Main ... }}} Bad behaviour when interrupting and running again: {{{ % touch A.hs; timeout 0.1 ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs; ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [TH] Linking Main ... }}} As you can see, when interrupting, the step `Compiling Main ( Main.hs, Main.o ) [TH]` went missing. This suggests to me that either: * the `[TH]`s are unnecessary in the first place (unlikely and I buy into the reason explained by #481 that changed values may be picked up by TH in higher-level modules) * the resumed `ghc --make` invocation may potentially produce wrong / not- up-to-date outputs (most likely) * re-running somehow retrieves the information that in fact recompiling `Main` is not necessary for a correct build (if this is the case, then I'd really like to know how that works and we should document it, likely also try to use that way to avoid recompiling `Main` in the uninterrupted run) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #4009: can newtype be extended to permit GADT-like declarations
by GHC 09 Mar '18

09 Mar '18

#4009: can newtype be extended to permit GADT-like declarations -------------------------------------+------------------------------------- Reporter: nr | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: 7.0.1 Component: Compiler (Type | Version: 6.12.1 checker) | Resolution: invalid | Keywords: newtype GADT Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): In ghc-8.2.1 and ghc-head, `newtype` definition in comment:2 is disallowed. But The following definition is accepted by GHC: {{{#!hs newtype T a where MkT :: a -> T a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4009#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14900: Calling isByteArrayPinned# on compact ByteArray
by GHC 09 Mar '18

09 Mar '18

#14900: Calling isByteArrayPinned# on compact ByteArray -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation explaining the relationship between pinnedness and compact regions is incomplete. From `Data.Compact`: > Pinned ByteArray# objects cannot be compacted. This is for a good reason: the memory is pinned so that it can be referenced by address (the address might be stored in a C data structure, for example), so we can't make a copy of it to store in the Compact. This is half-way true since it only considers one a the ways in which the GHC runtime tracks the pinnedness of an object. From experimenting with compact regions, it seems like there are two different notions of pinnedness: 1. Did the user explicitly ask for the `ByteArray` to be pinned? 2. Is the `ByteArray` pinned? If (1) is true, then (2) must always be true, but if (1) is false, then could be true or false. `ByteArray`s over 3KB are pinned, and `ByteArray`s under 3KB are not (or somewhere around that number). With that background information in place, here's the scenario I've encountered: {{{ {-# LANGUAGE MagicHash #-} import Data.Primitive import Data.Compact import GHC.Int import GHC.Prim main :: IO () main = do ByteArray arr1# <- fmap getCompact $ newByteArray 65000 >>= unsafeFreezeByteArray >>= compact ByteArray arr2# <- newByteArray 65000 >>= unsafeFreezeByteArray print (I# (isByteArrayPinned# arr1#)) print (I# (isByteArrayPinned# arr2#)) putStrLn "Finished" }}} When compiled and run, this gives: {{{ 0 1 Finished }}} We can see that the 65KiB `ByteArray` that was not compacted let's the user know that it is pinned. The compacted `ByteArray` claims to not be pinned, but this is not true. The docs in `Data.Compact` claim: > Data in a compact doesn't ever move, so compacting data is also a way to pin arbitrary data structures in memory. I propose that the behavior of `compact` be modified to accurately convey the pinnedness of the `ByteArray`s that copies. This would mean that even small, previously unpinned, `ByteArray`s would also be designated as pinned. It's a small change, but it makes the information the runtime gives us more accurate. This is occasionally handy when dealing with the FFI. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #3353: Add CLDouble support
by GHC 08 Mar '18

08 Mar '18

#3353: Add CLDouble support -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by claude): Replying to [comment:8 simonmar]: > As a workaround, code that needs `CLDouble` can go via a C wrapper that takes a `CLDouble *`. Avoid manipulating `CLDouble` directly in Haskell, just talk in terms of pointers to `CLDouble`. I recently had such a need, so wrote a small package to help: https://hackage.haskell.org/package/long-double -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3353#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14335: Annotations aren't supported with -fexternal-interpreter
by GHC 08 Mar '18

08 Mar '18

#14335: Annotations aren't supported with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that using `{-# ANN #-}` pragmas from a plugin cause GHC to crash when run with `-fexternal-interpreter` with {{{ ghc: this operation requires -fno-external-interpreter }}} It seems that the culprit is likely the use of `wormhole` in `convertAnnotationWrapper`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore
by GHC 08 Mar '18

08 Mar '18

#12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code compiles without any warnings! {{{#!hs {-# OPTIONS_GHC -Wmissing-methods #-} module Bug where class Foo a where _Bar :: a -> Int instance Foo Int }}} This code, however, //does// emit a warning: {{{#!hs {-# OPTIONS_GHC -Wmissing-methods #-} module Warns where class Foo a where bBar :: a -> Int instance Foo Int }}} {{{ Bug.hs:7:10: warning: [-Wmissing-methods] • No explicit implementation for ‘bBar’ • In the instance declaration for ‘Foo Int’ }}} The only difference is in the name of the class method of `Foo`. Namely, when a class method is prefixed with an underscore, GHC seems to look the other way when checking if any instances are missing an implementation of it. I'd argue that this behavior is incorrect, since I can't envision any scenario in which you'd want the compiler //not// to warn you about missing method implementations (as opposed to, say, not warning about an unused record selector). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14699: Library status for 8.4.1
by GHC 08 Mar '18

08 Mar '18

#14699: Library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- * `Cabal`: needs release * `Win32`: on-release * `array`: Needs revision * `binary`: on-release * `bytestring`: on-release * `containers`: needs release: https://github.com/haskell/containers/issues/501 * `deepseq`: needs revision * `directory`: on-release * `filepath`: needs release: https://github.com/haskell/filepath/issues/65 * `haskeline`: needs release: https://github.com/judah/haskeline/issues/75 * `hpc`: needs release * `mtl`: needs release: https://github.com/haskell/mtl/issues/52 * `parallel`: needs revision * `parsec`: needs release: https://github.com/haskell/parsec/issues/86 * `pretty`: needs release: https://github.com/haskell/pretty/issues/47 * `primitive`: needs release: https://github.com/haskell/primitive/issues/72 * `process`: needs release: https://github.com/haskell/primitive/issues/72 * `stm`: needs release: #14698 * `terminfo`: needs release: https://github.com/judah/terminfo/issues/27 * `text`: needs release: https://github.com/haskell/text/issues/215 * `time`: on-release * `transformers`: needs update: #14678 * `unix`: needs release: https://github.com/haskell/unix/issues/106 * `haddock`: needs release: https://github.com/haskell/haddock/issues/737 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #14903: RISC-V port
by GHC 08 Mar '18

08 Mar '18

#14903: RISC-V port -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At least three people recently mentioned interest in a RISC-V port of GHC. As it turns out, I started down this road one weekend last year. This ticket will track this effort. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5129: "evaluate" optimized away
by GHC 08 Mar '18

08 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | 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 Rev(s): Phab:D615 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0