July 2018 - ghc-tickets

[GHC] #15344: ApplicativeDo seems to prevent the fail method from being used
by GHC 05 Jul '18

05 Jul '18

#15344: ApplicativeDo seems to prevent the fail method from being used -------------------------------------+------------------------------------- Reporter: kccqzy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: -------------------------------------+------------------------------------- I am not sure if this is intended, but I came across this issue when debugging a runtime exception. It seems like an incomplete pattern match in a do-block with ApplicativeDo enabled will not use the fail method. If I have a module like this {{{#!hs {-# LANGUAGE ApplicativeDo #-} {-# OPTIONS_ghc -ddump-simpl #-} module M where f :: Maybe (Maybe Int) -> Maybe Int -> Maybe Int f mgs mid = do _ <- mid (Just moi) <- mgs pure (moi + 42) main :: IO () main = print (f (Just Nothing) (Just 2)) }}} This will result in a runtime exception: {{{ Just *** Exception: repro.hs:(6,13)-(9,17): Non-exhaustive patterns in lambda }}} But if I remove the ApplicativeDo extension, this code works as normal, producing Nothing as the output. On a theoretical level I understand why this is happening, but I still find it quite unexpected, especially since the documentation at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #things-to-watch-out-for claims that > Your code should just work as before when ApplicativeDo is enabled, provided you use conventional Applicative instances. If this is not a defect in GHC itself, I'd say it is a defect in documentation in not pointing out this gotcha. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15344> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11547: Accessing shadowed definitions in GHCi
by GHC 05 Jul '18

05 Jul '18

#11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- Apparently GHCi creates a qualified namespace for each line it interprets, as can be observed with: {{{#!hs > data A = A > data A = B > :t A A :: Ghci3.A }}} Apparently accessing shadowed definitions in this way sometimes breaks GHCi: {{{#!hs > let a = a > let a = a > :t Ghci7.a <interactive>:1:1: error: • GHC internal error: ‘Ghci7.a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the expression: Ghci7.a }}} More specifically, complete reproduction instructions: {{{#!hs GHCi, version 8.1.20160205: http://www.haskell.org/ghc/ :? for help > let foo = foo > :t Ghci1.foo Ghci1.foo :: t > let foo = foo > :t Ghci1.foo <interactive>:1:1: error: • GHC internal error: ‘Ghci1.foo’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the expression: Ghci1.foo }}} 7.10.2 (and 7.8.3 as verified over IRC by monochrom) appears to have a slightly different behavior. It seems it only creates namespaces for data/newtype/class declarations. Yet still, it fails with an error the first time but works completely fine thereafter: {{{#!hs > data A = A > data A = A > :t Ghci1.A Failed to load interface for ‘Ghci1’ no package key matching ‘interactive’ was found > :t Ghci1.A Ghci1.A :: Ghci1.A }}} 7.6.3 uses a different approach to displaying out of scope names so the behavior doesn't apply: {{{#!hs > data A = A > data A = B > :t A A :: main::Interactive.A }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8263: allow duplicate deriving / standalone deriving
by GHC 04 Jul '18

04 Jul '18

#8263: allow duplicate deriving / standalone deriving ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I would like to avoid conditional compilation. Currently I need to write: {{{ #if MIN_VERSION_Cabal(1,18,0) -- cabal 1.18 has these instances #else deriving instance Typeable Flag #endif }}} Would it be sane to have the deriving instance do nothing if the imported instance that clashes was also derived? reifyInstances together with a fixed #8100 could allow faking this feature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15202: Internal error showing typed hole in GHCi
by GHC 04 Jul '18

04 Jul '18

#15202: Internal error showing typed hole in GHCi -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypedHoles | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Run `ghc --interactive`, and at the prompt type {{{#!hs default () fish :: Eq a => a; fish = undefined foo :: String; foo = show _ }}} The following error appears: {{{ <interactive>:1:1: error: GHC internal error: ‘Ghci1.$trModule’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r2CZ :-> Identifier[foo::String, TopLevelLet]] }}} I have not yet been able to reproduce this loading a module; it seems to need to be on the command line. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers
by GHC 04 Jul '18

04 Jul '18

#15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let x = () Prelude> let x = () Prelude> :t _ <interactive>:1:1: error: GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] }}} Seems to only happen when there were two identifiers defined with the same name. As verified by mpickering on IRC this isn't reproducible in 8.2.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jul '18

04 Jul '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): New nofib results. - `nofib-gn-gnl`: GHC and boot libraries compiled with `-fno-state-hack` compiling nofib normally, vs. GHC compiled normally and boot libraries compiled with `-fno-state-hack` compiling nofib normally. This measures the effect of compiling GHC itself with `-fno-state-hack`. - `nofib-ns-nn`: GHC compiled normally compiling nofib normally vs. GHC compiled normally compiling nofib with `-fno-state-hack`. This measures the effect of the state hack on nofib when using a vanilla compiler. - `nofib-ns-nn-gnl`: GHC compiled normally with boot libraries compiled with `-fno-state-hack` compiling nofib normally vs. GHC compiled normally with boot libraries compiled with `-fno-state-hack` compiling nofib with `-fno-state-hack`. This measures the effect of the state hack on nofib when using a vanilla compiler with state-hack-free boot libraries. Key observations: - Differences are now much closer to what we expect, specifically, whether we compile GHC and / or boot libraries with or without the state hack does not significantly change nofib performance (< 1%). - Compiling GHC itself and boot libraries without the state hack makes nofib compilation slightly slower than compiling only boot libraries without the state hack (~4%). - Compiling nofib without the state hack makes compilation significantly faster (~25%) than compiling nofib with the state hack, regardless of how GHC itself and the boot libraries were compiled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jul '18

04 Jul '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-ns-nn-gnl.analyze.log" added. nofib analyse output: nofib compiled with NSH vs. normally, on a GHC build with NSH libraries -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jul '18

04 Jul '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-ns-nn.analyze.log" added. nofib analyse output: nofib compiled with NSH vs. normally, on a vanilla GHC build -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 04 Jul '18

04 Jul '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-gn-gnl.analyze.log" added. nofib analyse output: effect of NSH on libraries only vs. NSH on all of GHC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15249: Add support for cmpeq and cmpgt MMX intrinsics
by GHC 03 Jul '18

03 Jul '18

#15249: Add support for cmpeq and cmpgt MMX intrinsics -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: primops | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Add primop support for the following MMX intrinsics: {{{#!c __m64 _mm_cmpeq_pi16 (__m64 a, __m64 b) __m64 _mm_cmpeq_pi32 (__m64 a, __m64 b) __m64 _mm_cmpeq_pi8 (__m64 a, __m64 b) __m64 _mm_cmpeq_pi8 (__m64 a, __m64 b) __m64 _mm_cmpgt_pi16 (__m64 a, __m64 b) __m64 _mm_cmpgt_pi32 (__m64 a, __m64 b) __m64 _mm_cmpgt_pi8 (__m64 a, __m64 b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5