- ghc-tickets - Haskell.org

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 04 Oct '16

04 Oct '16

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It's because clang's CPP inserts a space before the `#` and then GHC no longer recognizes it as a shebang line. See #10044 for a related clang whitespace oddity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10163: Export typeRepKinds in Data.Typeable
by GHC 04 Oct '16

04 Oct '16

#10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc3 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{TypeRep}}} has a {{{[KindRep]}}} field internally, {{{Data.Typeable}}} should export {{{typeRepKinds}}} (alongside {{{typeRepTyCon}}} and {{{typeRepArgs}}}, which are currently exported) to allow users to access it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11054: GHC on Windows could not use more than 64 logical processors
by GHC 04 Oct '16

04 Oct '16

#11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found that GHC runtime does not take advantage of processor groups under Windows. So it cannot use more than 64 logical processors (2x 18 core physical + HT). This is Reddit thread about: https://www.reddit.com/r/haskell/comments/3q1r0o/ghc_on_numa_72_core_2_proc… MSDN link https://msdn.microsoft.com/en- us/library/windows/desktop/dd405503(v=vs.85).aspx -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

Re: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h"
by GHC 03 Oct '16

03 Oct '16

#8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"e9104d46eab0a2fbf7af9a299da3763bcf39f148/ghc" e9104d46/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e9104d46eab0a2fbf7af9a299da3763bcf39f148" DynFlags: Fix absolute import path to generated header Test Plan: Validate Reviewers: austin, snowleopard Reviewed By: snowleopard Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2559 GHC Trac Issues: #8040. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8040#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 03 Oct '16

03 Oct '16

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"3630ad355a5b7be0240d3071bb662fe710909cca/ghc" 3630ad3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3630ad355a5b7be0240d3071bb662fe710909cca" Mark #6132 as broken on OS X It currently fails with, =====> T6132(normal) 1 of 1 [0, 0, 0] cd "./runghc/T6132.run" && "/Users/bgamari/ghc/inplace/test spaces/ghc-stage2" -c T6132.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output Compile failed (exit code 1) errors were: T6132.hs:1:2: error: parse error on input ‘#!/’ *** unexpected failure for T6132(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int
by GHC 03 Oct '16

03 Oct '16

#12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Keywords: llvm cpp | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the user guide (http://ghc.readthedocs.io/en/8.0.1/phases.html#index-8) {{{ __GLASGOW_HASKELL_LLVM__ Only defined when -fllvm is specified. When GHC is using version x.y.z of LLVM, the value of __GLASGOW_HASKELL_LLVM__ is the integer ⟨xy⟩. }}} This is not the case, though, due to 29310b622801733e1b29a9a61988406872db13ca which changes {{{figureLlvmVersion :: DynFlags -> IO (Maybe Int)}}} into {{{figureLlvmVersion :: DynFlags -> IO (Maybe (Int, Int))}}}, and the driver just {{{show}}}ing the result (https://github.com/ghc/ghc/blob/29310b622801733e1b29a9a61988406872db13ca/co…) As a result, the macro value which used to be a numeric value is now something like {{{(3, 7)}}}. I'm now using a work-around (https://github.com/NicolasT/reedsolomon/commit/9d25ad6a26a29c90b82daacbf406…) but ''or'' the 'tuple value' should become 'official API', ''or'' this is a regression to be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12628> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12593: ghci spins forever
by GHC 03 Oct '16

03 Oct '16

#12593: ghci spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- When run with {{{ ghci -ignore-dot-ghci -XRankNTypes -XTypeInType -XGADTs -XConstraintKinds t5AE.hs }}} the compiler spins -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 02 Oct '16

02 Oct '16

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => * milestone: => 8.0.2 Comment: Indeed this still seems to be broken on OS X. I can confirm the behavior seen by mpickering in comment:9. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12614: Integer division can overwrite other arguments to foreign call
by GHC 02 Oct '16

02 Oct '16

#12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: integer | Operating System: Unknown/Multiple division | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you call a foreign function, GHC can generate incorrect code while passing the arguments to the function, overwriting the 3rd argument if a later argument contains an integer division. Main.hs: {{{ {-# LANGUAGE ForeignFunctionInterface #-} module Main where {-# NOINLINE foo #-} foo :: Int -> IO () foo x = c_foo 0 0 x $ x + x `quot` 10 foreign import ccall "foo" c_foo :: Int -> Int -> Int -> Int -> IO () main :: IO () main = do foo 202 foo 203 foo 204 }}} foo.c: {{{ #include <stdio.h> void foo(int a, int b, int c, int d) { printf("%d, %d, %d, %d\n", a, b, c, d); } }}} Expected output: {{{ 0, 0, 202, 222 0, 0, 203, 223 0, 0, 204, 224 }}} Actual output: {{{ 0, 0, 2, 222 0, 0, 3, 223 0, 0, 4, 224 }}} The bug has to be somewhere in the code generator. The cmm reads: {{{ call "ccall" arg hints: [‘signed’, ‘signed’, ‘signed’, ‘signed’] result hints: [] foo(0, 0, _s3nE::I64, _s3nE::I64 + %MO_S_Quot_W64(_s3nE::I64, 10)); }}} This generates the following assembler code: {{{ xorl %edi,%edi xorl %esi,%esi movq %rbx,%rdx movl $10,%ecx movq %rax,%rdx <-- move 3rd argument into rdx movq %rbx,%rax movq %rdx,%r8 cqto idivq %rcx <-- rax := rax / rcx; rdx := rax % rcx movq %rbx,%rcx addq %rax,%rcx subq $8,%rsp xorl %eax,%eax movq %r8,%rbx call foo }}} Thus rdx is overwritten again before the call, leading to incorrect results. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas
by GHC 02 Oct '16

02 Oct '16

#12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Currently the `SPECIALISE` pragma requires that the user repeat the entire type of a binding to instantiate its types. This is often needlessly verbose and quite tiresome. Instead, why not allow the user to write the desired type as an application with `TypeApplications`? For instance, currently we might write, {{{#!hs foldWithOptionsAndParser :: forall m params. ( MonadIO m, MonadMask m, ToRow params ) => FoldOptions -> RowParser row -> Connection -> Query -> params -> a -> (a -> row -> m a) -> m a foldWithOptionsAndParser opts parser conn template qs a f = ... {-# SPECIALISE foldWithOptionsAndParser :: FoldOptions -> RowParser row -> Connection -> Query -> params -> a -> (a -> row -> IO a) -> IO a #-} }}} Instead we might want to write, {{{#!hs {-# SPECIALISE foldWithOptionsAndParser @IO #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4