June 2017 - ghc-tickets

[GHC] #11501: Building nofib/fibon returns permission denied
by GHC 09 Jun '17

09 Jun '17

#11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 7.10.3 benchmark suite | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building nofib/fibon returns permission denied: {{{ == make boot - --no-print-directory; in /h/ywang30/nofib/fibon/Hackage/Bzlib ------------------------------------------------------------------------ // Codec/Compression/BZip/Stream.hsc make[3]: execvp: //: Permission denied make[3]: *** [Codec/Compression/BZip/Stream.hs] Error 127 }}} Steps to reproduce: Edit nofib/mk/boilerplate.mk:35 to NoFibSubDirs = fibon make clean && make boot in nofib/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13789: Look into haddock performance regressions due to desugaring on -fno-code
by GHC 09 Jun '17

09 Jun '17

#13789: Look into haddock performance regressions due to desugaring on -fno-code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- c9eb4385aad248118650725b7b699bb97ee21c0d enabled desugaring when GHC is invoked with `-fno-code` in order to resolve #10600. Unfortunately this causes GHC to do more (unnecessary) work when parsing for haddock, causing some rather significant allocations regressions in the haddock performance tests, {{{ bytes allocated value is too high: Expected haddock.base(normal) bytes allocated: 25592972912 +/-5% Lower bound haddock.base(normal) bytes allocated: 24313324266 Upper bound haddock.base(normal) bytes allocated: 26872621558 Actual haddock.base(normal) bytes allocated: 27868466432 Deviation haddock.base(normal) bytes allocated: 8.9 % *** unexpected stat test failure for haddock.base(normal) =====> haddock.Cabal(normal) 6 of 7 [0, 0, 0] bytes allocated value is too high: Expected haddock.Cabal(normal) bytes allocated: 18269309128 +/-5% Lower bound haddock.Cabal(normal) bytes allocated: 17355843671 Upper bound haddock.Cabal(normal) bytes allocated: 19182774585 Actual haddock.Cabal(normal) bytes allocated: 22294859000 Deviation haddock.Cabal(normal) bytes allocated: 22.0 % *** unexpected stat test failure for haddock.Cabal(normal) =====> haddock.compiler(normal) 7 of 7 [0, 0, 0] bytes allocated value is too high: Expected haddock.compiler(normal) bytes allocated: 52762752968 +/-10% Lower bound haddock.compiler(normal) bytes allocated: 47486477671 Upper bound haddock.compiler(normal) bytes allocated: 58039028265 Actual haddock.compiler(normal) bytes allocated: 65378619232 Deviation haddock.compiler(normal) bytes allocated: 23.9 % *** unexpected stat test failure for haddock.compiler(normal) }}} Work out how to mitigate this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13750: GHC produces incorrect coercions in hairy code
by GHC 08 Jun '17

08 Jun '17

#13750: GHC produces incorrect coercions in hairy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Andres Löh has been working with an optimized version of generics-sop, and ran into segfaults. He was able to reduce the test case to the attached (still not tiny) one, and could reduce it no further. He discovered the following utterly bogus definition in `-ddump-simpl` (with -O): {{{ Main.gshowP_$dAll :: All MyShow GHC.Exts.Any [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] Main.gshowP_$dAll = ghc-prim-0.5.0.0:GHC.Classes.$p1(%,%) @ (All MyShow GHC.Exts.Any) @ (All (All MyShow) GHC.Exts.Any) (ghc-prim-0.5.0.0:GHC.Classes.C:(%%) `cast` (Sub (Sym (Main.D:R:AllFk_c[][0] <[*]>_N <All MyShow>_N)) ; Sym (Main.N:All[0] <[*]>_N <All MyShow>_N <'[]>_N) ; Sub (Nth:1 (Sub (Sym (Main.D:R:AllFkc:[0] <[*]>_N <All MyShow>_N <'[Char]>_N <'[]>_N)) ; (AllF <[*]>_N <All MyShow>_N ((':) <[*]>_N (UnsafeCo nominal '[Char] GHC.Exts.Any) (UnsafeCo nominal '[] GHC.Exts.Any))_N)_R ; Sub (Main.D:R:AllFkc:[0] <[*]>_N <All MyShow>_N <GHC.Exts.Any>_N <GHC.Exts.Any>_N))) ; Main.N:All[0] <[*]>_N <All MyShow>_N (UnsafeCo nominal GHC.Exts.Any (GHC.Exts.Any : GHC.Exts.Any)) ; Sub (Main.D:R:AllFkc:[0] <[*]>_N <All MyShow>_N <GHC.Exts.Any>_N <GHC.Exts.Any>_N) :: (() :: Constraint :: Constraint) ~R# ((All MyShow GHC.Exts.Any, All (All MyShow) GHC.Exts.Any) :: Constraint))) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13750> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13666: The fake gcc can't handle trailing backslashes
by GHC 08 Jun '17

08 Jun '17

#13666: The fake gcc can't handle trailing backslashes ----------------------------------------+--------------------------------- Reporter: niklasl | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Driver | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The fake gcc will choke on trailing backslashes in arguments, like -Iinclude\ or -Llibs\. `realgcc` handles them fine. It seems to insert as spurious quote or terminating a quote too early. Error message: {{{ .\test-ghc.c:1:20: fatal error: test-inc"/header.h: Invalid argument compilation terminated. }}} Found here: [https://github.com/idris-lang/Idris-dev/issues/3801] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13796: hard to embed custom manifest on windows
by GHC 08 Jun '17

08 Jun '17

#13796: hard to embed custom manifest on windows ----------------------------------------+--------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I want to use a custom manifest file on windows to enable long filename support. I tried several ghc options to find a way to do it, and it does not seem easily possible to do this. First I thought, let's use -fno-gen-manifest, and since ghc generates foo.exe.manifest when building foo.hs, I'll provide a file with that name and it'll pick it up. But it seems that -fno-gen-manifest implies -fno- embed-manifest, so it didn't run windres, and this didn't work. Then I tried using -optwindres, hoping to pass windres -i foo.rc, and make that file point to my custom manifest. But, despite being documented as options that are passed to windres, -optwindres actually adds to the end of the windres --preprocessor option, so this caused it to run windres --preprocessor "gcc.exe ... -i foo.rc" The only remaining option seems to be to use -pgmwindres with a wrapper program that runs windres with the options I want. It seemed easier to file a ghc bug at this point.. I feel that the best fix would be either to still run windres when -fno- gen-manifest is used, or to add a new option like -fuse-custom-manifest- file=filename -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13798: Invalid transformation in simplOptExpr
by GHC 08 Jun '17

08 Jun '17

#13798: Invalid transformation in simplOptExpr -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Prior to [https://git.haskell.org/ghc.git/commitdiff/1722fa106e10e63160bb2322e2ccb830… this commit], `CoreOpt.simple_opt_expr` transforms {{{ case e of (b :: t1 ~# t2) DEFAULT -> rhs ==> rhs }}} That was plain wrong when `e` diverges, or calls `error`. Hence the commit. But the commit does this {{{ case Coercible_sc e of (b :: t1 ~# t2) DEFAULT -> rhs ==> rhs }}} narrowing the scope of the transformation to when the scrutinee is application of the Coercible superclass selector {{{ Coercible_sc :: Coercible a b -> (a ~R# b) }}} Here's the code from `CoreOpt`: {{{ | isDeadBinder b , [(DEFAULT, _, rhs)] <- as , isCoercionType (varType b) , (Var fun, _args) <- collectArgs e , fun `hasKey` coercibleSCSelIdKey -- without this last check, we get #11230 = go rhs }}} But that's bizarrely ad-hoc. And, worse, it is flat-out wrong... what if `e` diverges? It's not actually hurting anyone right now, but what we should really do is use `exprOkForSpeculation`; and teach `exprOkForSpeculation` how to deal with class-op selectors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13373: Handle long file paths on Windows
by GHC 07 Jun '17

07 Jun '17

#13373: Handle long file paths on Windows ----------------------------------------+--------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In the past, Cabal and GHC have run into Windows' PATH_MAX path size limitation, which caps the length of file system paths at 260 characters. Examples: * https://github.com/haskell/cabal/issues/3972 * https://ghc.haskell.org/trac/ghc/ticket/10777 It would be really great if Haskell's base libraries handled long file system paths correctly. There are a few possibilities for achieving this: * Call GetShortPathName https://msdn.microsoft.com/en- us/library/windows/desktop/aa364989(v=vs.85).aspx before calling any Windows API function, if we notice the file path is too long. The bad: Windows has to store the alias, and this aliasing mechanism may be disabled (but maybe this never happens in practice). * Rewrite the core libraries to use the Unicode versions of functions, which support longer paths. We need to add the `\\?\` prefix in this case. However, this prefix is not supported by all functions, and it turns off automatic expansion in the path string (so `..` is not interpreted.) Care would need to be taken to not break existing code. * For Windows 10 only, opt into transparent long path support using a manifest. See the bottom of https://msdn.microsoft.com/en- us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath Downside: this only works for Windows 10 An alternative plan is to build and publish an alternative Windows IO library, which is a drop-in replacement for the IO functionality implemented in base but is long paths. We can use this to test paths and provide better functionality to old versions of GHC, before merging the changes back into base proper. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13797: Mark negation injective
by GHC 07 Jun '17

07 Jun '17

#13797: Mark negation injective -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple InjectiveFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language DataKinds, TypeOperators, TypeFamilyDependencies, UndecidableInstances #-} import GHC.TypeLits data N = O | S N type family U (a :: Nat) = (res :: N) | res -> a where U 0 = O U n = S (U (n-1)) }}} gives {{{ olates injectivity annotation. Type variable ‘n’ cannot be inferred from the right-hand side. In the type family equation: U n = 'S (U (n - 1)) -- Defined at /tmp/a.hs:37:3 • In the equations for closed type family ‘U’ In the type family declaration for ‘U’ Failed, modules loaded: none. }}} I expect this to work, this depends on making `(-)` injective which depends on [https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies#Futureplansandi… "generalized injectivity"]? {{{#!hs type family (a :: Nat) - (b :: Nat) = (res :: Nat) | a b -> res, res a -> b, res b -> a where {- built in -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3591: A working program reports <<loop>> when compiled with -O
by GHC 07 Jun '17

07 Jun '17

#3591: A working program reports <<loop>> when compiled with -O -------------------------------+------------------------------------------- Reporter: blamario | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: | Test Case: simplCore/should_run/T3591 None/Unknown | Blocked By: | Blocking: Related Tickets: | -------------------------------+------------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"2b74bd9d8b4c6b20f3e8d9ada12e7db645cc3c19/ghc" 2b74bd9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b74bd9d8b4c6b20f3e8d9ada12e7db645cc3c19" Stop the specialiser generating loopy code This patch fixes a bad bug in the specialiser, which showed up as Trac #13429. When specialising an imported DFun, the specialiser could generate a recusive loop where none existed in the original program. It's all rather tricky, and I've documented it at some length in Note [Avoiding loops] We'd encoutered exactly this before (Trac #3591) but I had failed to realise that the very same thing could happen for /imported/ DFuns. I did quite a bit of refactoring. The compiler seems to get a tiny bit faster on deriving/perf/T10858 but almost all the gain had occurred before now; this patch just pushed it over the line. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3591#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11317: Test prog003 fails with segfault on Windows (GHCi)
by GHC 07 Jun '17

07 Jun '17

#11317: Test prog003 fails with segfault on Windows (GHCi) --------------------------------------+------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: #11234 Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- On my `x86_64` Windows machine test `prog003` fails with a segfault: {{{ cd ./ghci/prog003 && ghciWayFlags=-static HC="/home/Rik/ghc/inplace/bin /ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -dno-debug-output -no- user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history " "/home/Rik/ghc/inplace/bin/ghc-stage2.exe" -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <prog003.script > prog003.run.stdout 2> prog003.run.stderr >> prog003.run.stdout 2>> prog003.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Run 1 a :: Int -> Int 168 Run 2 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 3 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 4 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 5 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 6 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 7 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 8 Segmentation fault/access violation in generated code Stderr: *** unexpected failure for prog003(ghci) }}} (I do not think it is an access violation error since when I remove [https://github.com/ghc/ghc/blob/c2fab84239299176a8e72aa26ae894019d677bd9/te… line 65] and everything below line 70, the same stdout is generated.) This looks related to ticket #11234. The GHC version used was [http://git.haskell.org/ghc.git/commit/df6cb57b32d94b7f6f7c9a86207adfeee9712… df6cb57b32d94b7f6f7c9a86207adfeee9712ed6], although I already noticed the problem with a version a few days older. If someone could point me to information about how to install GDB suitable for debugging GHC on my Windows machine I will try to post the stack trace. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15