May 2018 - ghc-tickets

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 14 May '18

14 May '18

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining, | Specialise Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great! By "the attached reproducible case" do you mean the one right at the top (from tibbe)? I'd like to add something as a regression test before closing, to make sure it stays fixed. Omer/Tobias, might you do that? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 14 May '18

14 May '18

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining, | Specialise Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I don't know when this was fixed, but I just tried the attached reproducible case with GHC 8.2.2, and specialization occurs as expected. This came up because I was working on another project and realized that inlining did not block specialization like this comment:19 suggested it would. I think this ticket should be marked as resolved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12463: SPECIALIZABLE pragma?
by GHC 14 May '18

14 May '18

#12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Inlining | 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 it is common practice for library authors to use the `INLINEABLE` pragma to make it more likely that a polymorphic function should get an unfolding in the module's interface file to ensure that GHC is able to specialize. While in practice this works reasonably well, it's not really saying what we often mean: we don't want to inline, we really just want GHC to behave like each use-site's module has a `SPECIALISE` pragma for each concrete type that the function is used at. For instance, consider, {{{#!hs module ALibrary where aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} module SomeUser where import ALibrary aUser :: Int -> Int aUser = {- some large expression involving aLibraryFunction -} }}} Ideally, we would want GHC to take and produce one specialized version of `aLibraryFunction` for every concrete type which it is used at. However, without an `INLINEABLE` function, GHC won't even consider producing an unfolding for `aLibraryFunction` due to its size. If we include an `INLINEABLE` pragma (as most performance-aware authors would do) then we can convince GHC to produce an unfolding, but only at the expense of lowering its inlining cost as well. This is unfortunate since we never wanted GHC to inline; merely to specialize. This is issue especially prevalent in code using MTL-style effects, where we have ubiquitous overloading of very frequently-used functions (e.g. bind). Really what we want in this case is a way of indicating to GHC that a function shouldn't be inlined (use-sites replaced with the body of the function), but rather that GHC should try hard to specialize away particular type variables. This might look like, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALIZE forall a. LibraryFunction a #-} }}} This would request that GHC would keep an inlining around and produce a specialized version of `aLibraryFunction` every time it saw a concrete instantiation of `a`. Moreover, it would try to minim -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12463> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field
by GHC 14 May '18

14 May '18

#15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field --------------------------------------+------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- I'm on Windows and I've recently updated my msys packages. One of them was libicu which I updated from version 58 to version 61. This caused one of my projects to stop building. I've managed to reproduce the problem by just cloning the text-icu package and trying to open the repl in it. This is the error I get: {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help ghc.EXE: | C:\Users\darwi\Projects\text-icu\.stack- work\dist\5c8418a7\build\cbits\text_icu.o: unknown symbol `ucnv_getMaxCharSize_61' linking extra libraries/objects failed }}} A similar error used to happen with icu 58, but I've "fixed" it (see this pull request https://github.com/bos/text-icu/pull/36) This time, however, adding `icuio` to `extra-libraries` doesn't cut it. But adding `libicuio` does the trick! I'm opening a ticket here because I assume both of those should behave the same. It's worth noting that if this is a bug, it's not just a GHCi issue. My other project that depends on text-icu just doesn't build (the same error happens during compilation). Unfortunately I can't test on 8.4 right now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15131: Speed up certain Foldable NonEmpty methods
by GHC 14 May '18

14 May '18

#15131: Speed up certain Foldable NonEmpty methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Yitzchak Gale pointed out [https://www.reddit.com/r/haskell/comments/8hxpns/why_is_nonempty_missing_so… on Reddit] that some `Foldable` methods are allowed to take default definitions for `NonEmpty` when they probably shouldn't. The biggest problem appears to be `foldr1`, which ends up with a fairly atrocious definition. Yitz seems to think we should also provide a custom definition of `null`, to avoid relying on optimizations, but at present there is no obvious need for that. He doesn't mention this, but the definition of `length` should be changed. Indeed, the default definition of `length` would be better than the custom definition we currently have. I also noticed that we don't mark `foldl1` `INLINE`. At present its unfolding is optimized, so its `foldr` is not exposed. Thus, for example, {{{#!hs foldl1 (+) $ 1 :| [2..n] }}} won't fuse. We can certainly mark `foldl1` `INLINE` to fix this (`INLINABLE` doesn't do the trick), but it would be nice to know if there's another way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15067: When Typeable and unboxed sums collide, GHC panics
by GHC 14 May '18

14 May '18

#15067: When Typeable and unboxed sums collide, GHC panics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: Typeable, | Operating System: Unknown/Multiple UnboxedSums | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program is enough to send GHC into a tizzy: {{{#!hs {-# LANGUAGE UnboxedSums #-} module Bug1 where import Type.Reflection floopadoop :: TypeRep (# Bool | Int #) floopadoop = typeRep }}} {{{ $ ghc Bug.hs [1 of 1] Compiling Bug1 ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): tyConRep (#|#) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsBinds.hs:1314:5 in ghc:DsBinds }}} If you use an unboxed sum data constructor, you can get a different panic: {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UnboxedSums #-} module Bug2 where import Language.Haskell.TH import Type.Reflection type Fweemp = $(conT (unboxedSumDataName 1 2)) doopafloop :: _ => TypeRep Fweemp doopafloop = typeRep }}} {{{ $ ghc Bug2.hs [1 of 1] Compiling Bug2 ( Bug2.hs, Bug2.o ) GHC error in desugarer lookup in Bug2: Can't find interface-file declaration for variable $tc'(#_|#) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): initDs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14068: Turn tail-recursive functions into recursive jointpoints
by GHC 14 May '18

14 May '18

#14068: Turn tail-recursive functions into recursive jointpoints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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: -------------------------------------+------------------------------------- The function {{{ let f x y = case y of A -> f x' y' B -> e2 C -> e3 in g f }}} is not turned into a recursive join point, because the call to `f` is not in tail call position. But the recursive calls are, and these matter performance-wise! Hence, it would be beneficial to turn this into {{{ let f x y = joinrec $j x y = case x y of A -> $j x' y' B -> e2 C -> e3 in $j x y in g f }}} This has the additional effect that now `f` is no longer recursive and may get inlined. This came up in #13966, and might go well with #14067. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 58

[GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path
by GHC 13 May '18

13 May '18

#15021: ghc-pkg list crashes on Windows when unicode character is in the path ----------------------------------------+--------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #10762 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Below I will attach examples of how `ghc-pkg list` crashes with {{{ <stdout>: commitBuffer: invalid argument (invalid character) }}} when the user name contains a non-ASCII character (in my case `日`). I don't think it's important what the user name is, but more likely whether or not `日` is in some path (probably the path to the package database). The issue is trivially reproducible (I tried on Windows 10, and Server 2016 as deployed by AWS) with cmd.exe and PowerShell. In the below, `chcp 20127` sets the code page to US-ASCII, and `chcp 65001`, sets it to UTF-8. This per-terminal / per-process setting is different from the system locale (as can be set [https://www.java.com/en/download/help/locale.xml this way]). The the behaviour of different combinations of system locale and code page: * English (US) system locale * `chcp 437` (English default): **crash** * `chcp 65001` (UTF-8): no crash * `chcp 20127` (ASCII): **crash** * Japanese system locale * `chcp 932` (Japanese default): no crash * `chcp 65001` (UTF-8): no crash * `chcp 20127` (ASCII): **crash** In none of these situatins should `ghc-pkg list` crash. It breaks all the build tools; from conversatins on the `haskell-jp` Slack, I have learned that Japanese users have learned to avoid unicode in their user names due to this issue. I believe the fix to `ghc-pkg` should be similar to [https://github.com/ghc/ghc/commit/1b56c40578374a15b4a2593895710c68b0e2a717 this fix for `ghc`] (#10762), where the encoding of the stdout `Handle` is set to UTF-8. ---- With English (US) system locale, as copy-pasted from PowerShell: {{{ Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. PS C:\Users\日> chcp Active code page: 437 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.EXE list C:\Users\ghc-pkg.EXE: <stdout>: commitBuffer: invalid argument (invalid character) PS C:\Users\日> chcp 65001 Active code page: 65001 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.EXE list C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\lib\package.conf.d Cabal-2.0.1.0 Win32-2.5.4.1 array-0.5.2.0 base-4.10.1.0 binary-0.8.5.1 bytestring-0.10.8.2 containers-0.5.10.2 deepseq-1.4.3.0 directory-1.3.0.2 filepath-1.4.1.2 (ghc-8.2.2) ghc-boot-8.2.2 ghc-boot-th-8.2.2 ghc-compact-0.1.0.0 ghc-prim-0.5.1.1 ghci-8.2.2 haskeline-0.7.4.0 hoopl-3.10.2.2 hpc-0.6.0.3 integer-gmp-1.0.1.0 pretty-1.1.3.3 process-1.6.1.0 rts-1.0 template-haskell-2.12.0.0 time-1.8.0.2 transformers-0.5.2.0 xhtml-3000.2.2 PS C:\Users\日> chcp 20127 Active code page: 20127 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.EXE list C:\Users\ghc-pkg.EXE: <stdout>: commitBuffer: invalid argument (invalid character) }}} With Japanese system locale, as copied from PowerShell: {{{ Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. PS C:\Users\日> chcp Active code page: 932 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.exe list C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\lib\package.conf.d Cabal-2.0.1.0 Win32-2.5.4.1 array-0.5.2.0 base-4.10.1.0 binary-0.8.5.1 bytestring-0.10.8.2 containers-0.5.10.2 deepseq-1.4.3.0 directory-1.3.0.2 filepath-1.4.1.2 (ghc-8.2.2) ghc-boot-8.2.2 ghc-boot-th-8.2.2 ghc-compact-0.1.0.0 ghc-prim-0.5.1.1 ghci-8.2.2 haskeline-0.7.4.0 hoopl-3.10.2.2 hpc-0.6.0.3 integer-gmp-1.0.1.0 pretty-1.1.3.3 process-1.6.1.0 rts-1.0 template-haskell-2.12.0.0 time-1.8.0.2 transformers-0.5.2.0 xhtml-3000.2.2 PS C:\Users\日> chcp 65001 Active code page: 65001 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.exe list C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\lib\package.conf.d Cabal-2.0.1.0 Win32-2.5.4.1 array-0.5.2.0 base-4.10.1.0 binary-0.8.5.1 bytestring-0.10.8.2 containers-0.5.10.2 deepseq-1.4.3.0 directory-1.3.0.2 filepath-1.4.1.2 (ghc-8.2.2) ghc-boot-8.2.2 ghc-boot-th-8.2.2 ghc-compact-0.1.0.0 ghc-prim-0.5.1.1 ghci-8.2.2 haskeline-0.7.4.0 hoopl-3.10.2.2 hpc-0.6.0.3 integer-gmp-1.0.1.0 pretty-1.1.3.3 process-1.6.1.0 rts-1.0 template-haskell-2.12.0.0 time-1.8.0.2 transformers-0.5.2.0 xhtml-3000.2.2 PS C:\Users\日> chcp 20127 Active code page: 20127 PS C:\Users\日> C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.2\bin\ghc-pkg.exe list C:\Users\ghc-pkg.exe: <stdout>: commitBuffer: invalid argument (invalid character) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail
by GHC 13 May '18

13 May '18

#10762: On Windows, out-of-codepage characters can cause GHC build to fail -----------------------------------------+--------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- You can see where this hit us recently on stack with issues [https://github.com/commercialhaskell/stack/issues/738 738] and [https://github.com/commercialhaskell/stack/issues/734 734]. To demonstrate, I'm attaching a UTF-8 encoded Haskell program with some Hebrew characters, and some warnings. The contents of that file are: {{{#!hs module Main ( main , שלום ) where main :: IO () main = putStrLn שלום שלום = "shalom" }}} If I first set my codepage to 65001 (UTF-8), everything works as expected: {{{ C:\Users\Michael\Desktop>chcp 65001 Active code page: 65001 C:\Users\Michael\Desktop>ghc -fforce-recomp -Wall -ddump-hi -ddump-to-file shalom.hs [1 of 1] Compiling Main ( shalom.hs, shalom.o ) shalom.hs:9:1: Warning: Top-level binding with no type signature: שלום :: [Char] Linking shalom.exe ... }}} However, if I set my codepage to 437 (US), both the warnings sent to the console, and the .hi dump file, cause GHC to exit prematurely: {{{ C:\Users\Michael\Desktop>chcp 437 Active code page: 437 C:\Users\Michael\Desktop>ghc -fforce-recomp -Wall shalom.hs [1 of 1] Compiling Main ( shalom.hs, shalom.o ) shalom.hs:9:1: Warning: Top-level binding with no type signature: <stderr>: commitBuffer: invalid argument (invalid character) }}} {{{ C:\Users\Michael\Desktop>chcp 437 Active code page: 437 C:\Users\Michael\Desktop>ghc -fforce-recomp -ddump-hi -ddump-to-file shalom.hs [1 of 1] Compiling Main ( shalom.hs, shalom.o ) shalom.dump-hi: commitBuffer: invalid argument (invalid character) }}} At the very least, I would argue that -ddump-to-file should always dump to the output files as UTF-8, as this is the most useful for tooling. Beyond that, there are a few options here: * Have all output- including to the console- go out as UTF-8. This may not play terribly nicely with consoles without setting the output codepage. * Provide a command line option or environment variable to specify "output as UTF-8." * More radical: change the default way that all Handles work so that UTF-8 is the default, instead of paying attention to code pages and environment variables. Honestly, this is my preference, but it's a bigger discussion than this one bug. The workaround we've implemented in stack for now is setting the codepage to 65001 for the console while running stack. This is not ideal, since this is essentially a global setting for the entire console. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #14875: -ddump-splices pretty-printing oddities with case statements
by GHC 13 May '18

13 May '18

#14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The latest installment in "Ryan finds minor bugs in `-ddump-splices`". Take this program: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| f :: Bool -> Bool f x = case x of (True :: Bool) -> True (False :: Bool) -> False g :: Bool -> Bool g x = (case x of True -> True False -> False) :: Bool |]) }}} Compiling this gives: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(15,6): Splicing declarations [d| f_a1sB :: Bool -> Bool f_a1sB x_a1sD = case x_a1sD of (True :: Bool) -> True (False :: Bool) -> False g_a1sC :: Bool -> Bool g_a1sC x_a1sE = (case x_a1sE of True -> True False -> False) :: Bool |] ======> f_a49Z :: Bool -> Bool f_a49Z x_a4a0 = case x_a4a0 of True :: Bool -> True False :: Bool -> False g_a49Y :: Bool -> Bool g_a49Y x_a4a1 = case x_a4a1 of True -> True False -> False :: Bool }}} Neither the `-ddump-splices` output for `f` nor `g` parse are legal Haskell: * In `f`, GHC fails to parenthesize the pattern signatures `True :: Bool` and `False :: Bool`. * In `g`, GHC fails to parenthesize the `case` expression which has an explicit `Bool` signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14875> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9