- ghc-tickets - Haskell.org

Re: [GHC] #2159: Use a more efficient representation than [DynFlag]
by GHC 15 Feb '16

15 Feb '16

#2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well the bit array was 4x faster than IntSet in my unscientific test. And it would probably be a bit faster still when the option to test is known and can be inlined. But there could be little left to gain after the switch to IntSet. A pretty easy experiment to do, if we had an easy way to benchmark compiler performance... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2159#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2159: Use a more efficient representation than [DynFlag]
by GHC 15 Feb '16

15 Feb '16

#2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Heh, I was just looking at this too. I imagine a bit array representation as in "bitmap.dpatch" would be a lot faster though. Especially if you added RULES to inline the case of checking for a known flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2159#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2159: Use a more efficient representation than [DynFlag]
by GHC 15 Feb '16

15 Feb '16

#2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Unless I am mistaken this has already been implemented. `DynFlags` now represents dump flags, extension flags, and general flags as `IntSet`s, using the `Enum` instances of the respective types to map each flag to a bit. I'm not entirely sure when this change was made but it was quite a while ago. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2159#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11567: Haddock renders wired-in types with kind signature
by GHC 14 Feb '16

14 Feb '16

#11567: Haddock renders wired-in types with kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Lifted wired-in types seem to be rendered with an unnecessary `TYPE 'Lifted` kind signature. See, for instance, [https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0…] I'm not yet sure whether this is a ghc or haddock issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax
by GHC 14 Feb '16

14 Feb '16

#2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I assume hvr is joking, but you can never be sure... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2530#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax
by GHC 14 Feb '16

14 Feb '16

#2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, if people find this objectionable, I suppose we also need to review #10104, since that also resulted in a change in `Show` output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2530#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9920: Segfault in arm binary
by GHC 14 Feb '16

14 Feb '16

#9920: Segfault in arm binary ----------------------------+------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+------------------------------------------- Using ghc HEAD (6713f0d9a) I compile a very simple program which segfaults immediately. Stepping through it using GDB I find its crashing on the instruction {{{ 0x3f5a98 <stg_init_finish$def+12> ldr r5, [r5] }}} and that just before this instruction the value of `r5` is zero. That means its trying to load into `r5` the value at the address in `r5`. Obviously that's going to segfault. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

Re: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax
by GHC 13 Feb '16

13 Feb '16

#2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Fwiw, Changing GHCi's output after so many years is possibly disrupting to literature, as GHCi's output would look different from examples printed in books and tutorials. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2530#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7985: Allow openFile on unknown file type
by GHC 13 Feb '16

13 Feb '16

#7985: Allow openFile on unknown file type -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 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 ekmett): > Just guessing once and for all that files of unknown type are seekable (or not seekable) doesn't seem right. We ''could'' default to merely claiming a `Stream` as a reasonably safe default. This makes the fewest assumptions about supported operations, and would give back `False` for unknown seekability. This is conservative, but would allow users to at least open and stream content to/from such devices. If users later can point to specific exotic non-posix device types that support seeking then we could toggle on support for them on a case by case basis. This would likely let us simplify the `statGetType` logic a great deal to something like: {{{#!hs statGetType :: Ptr CStat -> IO IODeviceType statGetType p_stat = do c_mode <- st_mode p_stat :: IO CMode case () of _ | s_isdir c_mode -> return Directory | s_isreg c_mode -> return RegularFile | s_isblk c_mode -> return RawDevice | otherwise -> return Stream }}} Another, far less desirable, alternative would be to add a new `IODeviceType` and call `ioe_unsupportedOperation` when you attempt to call `hIsSeekable` on such a device, but it only delays the unexpected bottom, and seems like it would rely on `seek` being implemented in a rather uniform manner across devices across platforms, which doesn't fit with my understanding of the world. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7985#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7320: GHC crashes when building on 32-bit Linux in a Linode
by GHC 13 Feb '16

13 Feb '16

#7320: GHC crashes when building on 32-bit Linux in a Linode ---------------------------------------+-------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+-------------------------------- Comment (by rwbarton): This was a long time ago; is it still an issue? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7320#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0