February 2018 - ghc-tickets

[GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance
by GHC 20 Feb '18

20 Feb '18

#14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We experienced code breakage while moving to 8.2.1 - in some circumstances it picks wrong instances if an instance in the lines of `instance {-# OVERLAPPABLE #-} C a ` is defined. @s9gf4ult was really nice to create a repo demonstrating an issue, you can look at the repo here: [https://github.com/s9gf4ult/isogen-minimal-example] Running `chech.sh` will trigger three builds: {{{ GHC 8.0.2, -O, succeeds GHC 8.2.1, -O0, succeeds GHC 8.2.1, -O, fails }}} If you'll check out to either of fix- branches: {{{ fix-move-to_string fix-no-catchall-instance fix-replace-to_string fix-add-irrelevant-instance }}} then the last test should succeed also. Those branches contain changes over master which fixes the bug in different ways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14752: Unboxed sums documentation looks wrong
by GHC 20 Feb '18

20 Feb '18

#14752: Unboxed sums documentation looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: Documentation | Version: 8.2.2 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to the documentation, > In the case of enumeration types (like `Bool`), the unboxed sum layout only has an `Int32` field (i.e. the whole thing is represented by an integer). This does not actually seem to be true. {{{#!hs right :: Bool -> (# (# #) | Bool #) right x = (# | x #) test :: (# (# #) | Bool #) -> Bool test (# (# #) | #) = False test (# | _ #) -> True }}} If the documentation were correct, I would expect `test (right undefined)` to be `undefined`, but it is `True`. Either we should fix the documentation to match reality or the reality to match the documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13422: INLINE CONLIKE sometimes fails to inline
by GHC 20 Feb '18

20 Feb '18

#13422: INLINE CONLIKE sometimes fails to inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #7206 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got surprisingly poor results from the `cheapBuild` experiment (see #7206), so I decided to try a simple example. {{{#!hs foo :: Int -> Int foo n = s + p where nums = [1..n] s = sum nums p = product nums }}} The idea is that we want `nums` to inline into `s` and `p`; the lost sharing is unimportant. Unfortunately, this didn't fuse. I got {{{ -- RHS size: {terms: 44, types: 31, coercions: 0, joins: 2/3} $wfoo :: Int# -> Int# $wfoo = \ (ww_s2HT :: Int#) -> let { nums_s2Gq :: [Int] nums_s2Gq = eftInt 1# ww_s2HT } in joinrec { $wgo_s2HP :: [Int] -> Int# -> Int# $wgo_s2HP (w_s2HJ :: [Int]) (ww1_s2HN :: Int#) = case w_s2HJ of { [] -> joinrec { $wgo1_s2HI :: [Int] -> Int# -> Int# $wgo1_s2HI (w1_s2HC :: [Int]) (ww2_s2HG :: Int#) = case w1_s2HC of { [] -> +# ww1_s2HN ww2_s2HG; : y_a2F9 ys_a2Fa -> case y_a2F9 of { I# y1_a2Gf -> jump $wgo1_s2HI ys_a2Fa (*# ww2_s2HG y1_a2Gf) } }; } in jump $wgo1_s2HI nums_s2Gq 1#; : y_a2F9 ys_a2Fa -> case y_a2F9 of { I# y1_a2EX -> jump $wgo_s2HP ys_a2Fa (+# ww1_s2HN y1_a2EX) } }; } in jump $wgo_s2HP nums_s2Gq 0# -- RHS size: {terms: 10, types: 4, coercions: 0, joins: 0/0} foo :: Int -> Int foo = \ (w_s2HQ :: Int) -> case w_s2HQ of { I# ww1_s2HT -> case $wfoo ww1_s2HT of ww2_s2HX { __DEFAULT -> I# ww2_s2HX } } }}} I verified that `cheapBuild` actually appeared (in `-dverbose-core2core`), but it didn't fuse, and ultimately inlined. Interestingly, forcing the argument manually fixed the problem: {{{#!hs foo :: Int -> Int foo !n = s + p where nums = [1..n] s = sum nums p = product nums }}} produces {{{#!hs $wfoo :: Int# -> Int# $wfoo = \ (ww_s2Ia :: Int#) -> case tagToEnum# (># 1# ww_s2Ia) of { False -> joinrec { $wgo_s2I6 :: Int# -> Int# -> Int# $wgo_s2I6 (w_s2I0 :: Int#) (ww1_s2I4 :: Int#) = case tagToEnum# (==# w_s2I0 ww_s2Ia) of { False -> jump $wgo_s2I6 (+# w_s2I0 1#) (+# ww1_s2I4 w_s2I0); True -> let { x_X2Fz :: Int# x_X2Fz = +# ww1_s2I4 w_s2I0 } in joinrec { $wgo1_s2HY :: Int# -> Int# -> Int# $wgo1_s2HY (w1_s2HS :: Int#) (ww2_s2HW :: Int#) = case tagToEnum# (==# w1_s2HS ww_s2Ia) of { False -> jump $wgo1_s2HY (+# w1_s2HS 1#) (*# ww2_s2HW w1_s2HS); True -> +# x_X2Fz (*# ww2_s2HW w1_s2HS) }; } in jump $wgo1_s2HY 1# 1# }; } in jump $wgo_s2I6 1# 0#; True -> 1# } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14825: Access violation on Windows is not propagated to the OS
by GHC 20 Feb '18

20 Feb '18

#14825: Access violation on Windows is not propagated to the OS -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.2.2 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We're using Haskell in production environment. Some times we get exceptions, like this: "Access violation in generated code when reading 0000000000000000" and nothing more. This is extremely hard and time consuming to debug where this exception came from. There is no information about at which address was the exception thrown. The correct way on Windows is such exceptions to be propagated to the operating system. This way we will attach a debugger to the process and it'll get and visualize where the exception happened. Currently GHC runtime is catching the exception, skip its source information and present that uninformative message to the user. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11427: TypeSynonyms not deduced
by GHC 20 Feb '18

20 Feb '18

#11427: TypeSynonyms not deduced -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- {{{ class (AllF f xs, SListI xs) => All (f :: k -> Constraint) (xs :: [k]) instance #if __GLASGOW_HASKELL__ >= 710 {-# OVERLAPPING #-} #endif All SListI xss => SingI (xss :: [[k]]) where sing = sList }}} fails with {{{ • Could not deduce (SListI xss) arising from the superclasses of an instance declaration from the context: All SListI xss bound by the instance declaration at src/Generics/SOP/Constraint.hs:141:3-40 • In the instance declaration for ‘SingI xss’ }}} See https://travis-ci.org/well-typed/generics-sop/jobs/102388817 and https://github.com/phadej/generics-sop/tree/ghc-8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #7206: Implement cheap build
by GHC 20 Feb '18

20 Feb '18

#7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > The result is the same; only allocation difference is in `cacheprof` Ignore `cacheprof` until https://ghc.haskell.org/trac/ghc/ticket/8611 is fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7206: Implement cheap build
by GHC 20 Feb '18

20 Feb '18

#7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I rebased the `cheap-build` branch, applied the idea in #13422 to `Word` and `Char` enumerations (`Int` was already implemented), verified that it works as expected, and run nofib again. The result is the same; only allocation difference is in `cacheprof`. Runtimes differ, but when I compared STG outputs I see that they're identical even though runtime differs a few percent. So they're really just noise. I suspect runtime results in comment:13 are also of this nature. I was thinking that this optimization can be done with little user intervention by adding an `INLINE` pragma, but surprisingly it doesn't work. In the example from #13422: {{{ foo :: Int -> Int foo n = s + p where nums = [1..n] s = sum nums p = product nums }}} adding `INLINE` to nums (in original GHC, without `cheap-build` patch) does not make it fuse. However if I manually inline it (substitute `[1..n]` for `nums`) it fuses as expected. Not sure if this is a bug or not, but it's certainly surprising to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14312: Head does not build on Windows with the default make config.
by GHC 19 Feb '18

19 Feb '18

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Cloning head and just running: {{{ ./boot ./configure --enable-tarballs-autodownload make }}} Fails since at least two weeks and still does as of a4ee28978acbcf68da9dfb6f198cb6e1ff38ccca The main issue is the directory library fails to build. Creating a build.mk file and setting the Flavour to quick GHC does build as expected. What triggers the failure seems to be the windows.h file created by the directory library which in some way includes itself in a loop until the preprocessor/c-compiler gives up. Renaming the file locally seems to be a viable workaround. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 19 Feb '18

19 Feb '18

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bfrk): I have gradually changed my opinion on this some over the years. I no longer think that writing explicit interface files is too much of a burden. Indeed it can have great advantages to do so, but I would prefer a proper integration into Haskell the language. The current situation is not ideal: (1) hs-boot is an obscure name for an interface definition (2) it is an implementation defined feature, outside of the language (3) it is unclear to me how it interacts with the use of export lists; ideally I would want to be able to use interface definition files as an alternative to export lists (4) it should not be necessary to repeat in the .hs file anything that is already fully defined in the interface definition file (incomplete definitions are exempted) (5) it should be possible to place the interface definition in a distinguished "header" part of the .hs, so that it need not be in a separate file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:74> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 19 Feb '18

19 Feb '18

#7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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 kcsongor): Replying to [comment:24 simonpj]: > > This is currently imperilled by #14420. > > How, exactly? #14420 means that one can define a distinguishable member of any kind, bringing back `Any` {{{ data family Any :: k }}} Isn't this what caused the original soundness issue? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7259#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0