April 2017 - ghc-tickets

[GHC] #13506: Spurious extra error message due to functional dependencies
by GHC 13 Apr '17

13 Apr '17

#13506: Spurious extra error message due to functional dependencies -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One call site is ill-typed, but GHC reports a type error at every call site, not just the problematic one. In the original code, the problem occurred with a very common function (`Data.Lens.view`), so the avalanche of error messages made it difficult to find the problematic call site. {{{#!hs {-# LANGUAGE FlexibleInstances, FunctionalDependencies, MultiParamTypeClasses #-} module Bug where class FunDep lista a | lista -> a instance FunDep [a] a singleton :: FunDep lista a => a -> lista singleton _ = undefined -- this error is expected: -- Couldn't match type 'Char' with '()' -- arising from a functional dependency between -- constraint 'FunDep [Char] ()' arising from a use of 'singleton' -- instance 'FunDep [a] a' illTyped :: [Char] illTyped = singleton () -- but this one is not: -- Couldn't match type '()' with 'Char' -- arising from a functional dependency between constraints: -- 'FunDep [Char] Char' arising from a use of 'singleton' (in 'wellTyped') -- 'FunDep [Char] ()' arising from a use of 'singleton' (in 'illTyped') wellTyped :: [Char] wellTyped = singleton 'a' }}} The spurious error disappears if `illTyped` is commented out or moved after `wellTyped`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13559: Remove LLVM/-fPIC check in DynFlags
by GHC 12 Apr '17

12 Apr '17

#13559: Remove LLVM/-fPIC check in DynFlags -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | 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 the LLVM backend was first implemented the implementation did not support `-fPIC` or `-dynamic`. Support for this was added in 60873542e8edf0ee593fde2b6544770d8036728f, which merely added the appropriate `-relocation-model` flag to the `opt` command line when compiling with `-fPIC`. However, the error message in `DynFlags.makeDynFlagsConsistent` remains for all but a select few platforms, {{{#!hs | hscTarget dflags == HscLlvm && not ((arch == ArchX86_64) && (os == OSLinux || os == OSDarwin || os == OSFreeBSD)) && not ((isARM arch) && (os == OSLinux)) && (gopt Opt_PIC dflags || WayDyn `elem` ways dflags) = if cGhcWithNativeCodeGen == "YES" then let dflags' = dflags { hscTarget = HscAsm } warn = "Using native code generator rather than LLVM, as LLVM is incompatible with -fPIC and -dynamic on this platform" in loop dflags' warn else throwGhcException $ CmdLineError "Can't use -fPIC or -dynamic on this platform" }}} Is this still necessary? If so, why? If not, we should remove it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7722: iOS patch no 11: Fix quirk with runtime loader
by GHC 12 Apr '17

12 Apr '17

#7722: iOS patch no 11: Fix quirk with runtime loader --------------------------------------+----------------------- Reporter: StephenBlackheath | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Other | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7724 Related Tickets: | --------------------------------------+----------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"68c00a1b38707b2a5c813cbe3da3ffb7d97893b6/ghc" 68c00a1b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68c00a1b38707b2a5c813cbe3da3ffb7d97893b6" Drop special handling of iOS iOS at least since iOS8 (we are currently at iOS10.3), allows for dynamic libaries, hence any artificail restriction on dyanmic libraries should be lifted. Please ping me with any iOS related issues that should potentially resurface. The iOS toolchain has considerably changed over the years, and I'm willing to drop work arounds in good faith. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13559, #7722 Differential Revision: https://phabricator.haskell.org/D3451 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7722#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13558: Inconsistency in `CoreUtils.exprIsOk`
by GHC 12 Apr '17

12 Apr '17

#13558: Inconsistency in `CoreUtils.exprIsOk` -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Consider {{{ f1 = \x y -> let t = case x of True -> let v = Just y in (v, v) False -> (Nothing, Nothing) in \w -> t f2 = \x y -> let t = case x of True -> (Just y, Just y) False -> (Nothing, Nothing) in \w -> t }}} We give `f1` arity 1, but `f2` gets arity 2. That's bizarre, because all we've done is turn a `let` into a function application. Reason: in `CoreUtils.exprIsOk`, we recursively apply `go` in the `App` case, but we fail unconditionally in the `Let` case. That is simply inconsistent, and it bit me when trying something else. Incidentally `exprIsOk` is badly named. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13160: Simplify CoreFV.FVAnn
by GHC 12 Apr '17

12 Apr '17

#13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- Reporter: simonpj | 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 introducing type-in-type, Richard elaborated the free varaible finder so that it finds three things at once (in `CoreFV`): {{{ data FVAnn = FVAnn { fva_fvs :: DVarSet -- free in expression , fva_ty_fvs :: DVarSet -- free only in expression's type , fva_ty :: Type -- expression's type } }}} I think `fva_ty` is needed only to support `fva_ty_fvs`. And `fva_ty_fvs` seems to be used only to support the calls to `freeVarsOfType` in `FloatIn`. And those calls in turn are only to suppor `used_in_ty` in `FloatIn.sepBindsByDropPoint`. In conversation yesterday, Richard and I agreed that all this is unnecessary. Coercion bindings simply do not float inwards, so we do not need to take these precautions. (We should add a Note to explain why they don't float, and what problem might arise if they did.) To confirm this I set `used_in_ty` to `False` and compiled from scratch; everything is fine. So I propose that we * get rid of the `ty_fvs` argument to `sepBindsByDropPoint` * simplfy `FVAnn` to just gather free variables (ie one field only) Result: it's all simpler. Richard will do this when he gets a moment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13138: Clean up ghc-pkg validation warnings in build log
by GHC 12 Apr '17

12 Apr '17

#13138: Clean up ghc-pkg validation warnings in build log -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | 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 build log has hundreds of lines of `ghc-pkg` warnings which I imagine are due to how GHC's build system is different to normal. We should either work out why there are so many errors and fix them or if they are harmless suppress them to remove the noise from the log. {{{ binary-0.8.3.0: Warning: Unrecognized field abi-depends on line 40 27 binary-0.8.3.0: Warning: Unrecognized field abi on line 28 28 binary-0.8.3.0: Warning: Unrecognized field indefinite on line 22 29 binary-0.8.3.0: Warning: haddock-interfaces: /var/drydock/workingcopy-21831/repo/glasgow-haskell- compiler/libraries/binary/dist-boot/doc/html/binary/binary.haddock doesn't exist or isn't a file 30 binary-0.8.3.0: cannot find any of ["Data/Binary.hi","Data/Binary.p_hi","Data/Binary.dyn_hi"] (ignoring) 31 binary-0.8.3.0: cannot find any of ["Data/Binary/Builder.hi","Data/Binary/Builder.p_hi","Data/Binary/Builder.dyn_hi"] (ignoring) 32 binary-0.8.3.0: cannot find any of ["Data/Binary/Get.hi","Data/Binary/Get.p_hi","Data/Binary/Get.dyn_hi"] (ignoring) 33 binary-0.8.3.0: cannot find any of ["Data/Binary/Get/Internal.hi","Data/Binary/Get/Internal.p_hi","Data/Binary/Get/Internal.dyn_hi"] (ignoring) 34 binary-0.8.3.0: cannot find any of ["Data/Binary/Put.hi","Data/Binary/Put.p_hi","Data/Binary/Put.dyn_hi"] (ignoring) 35 binary-0.8.3.0: cannot find any of ["Data/Binary/Class.hi","Data/Binary/Class.p_hi","Data/Binary/Class.dyn_hi"] (ignoring) 36 binary-0.8.3.0: cannot find any of ["Data/Binary/Internal.hi","Data/Binary/Internal.p_hi","Data/Binary/Internal.dyn_hi"] (ignoring) 37 binary-0.8.3.0: cannot find any of ["Data/Binary/Generic.hi","Data/Binary/Generic.p_hi","Data/Binary/Generic.dyn_hi"] (ignoring) 38 binary-0.8.3.0: cannot find any of ["libHSbinary-0.8.3.0.a","libHSbinary-0.8.3.0.p_a","libHSbinary-0.8.3.0-ghc7.10.3.so","libHSbinary-0.8.3.0-ghc7.10.3.dylib","HSbinary-0.8.3.0-ghc7.10.3.dll"] on library path (ignoring) 39 Cabal-1.25.0.0: Warning: Unrecognized field abi-depends on line 125 40 Cabal-1.25.0.0: Warning: Unrecognized field abi on line 106 41 Cabal-1.25.0.0: Warning: Unrecognized field indefinite on line 20 42 Cabal-1.25.0.0: Warning: haddock-interfaces: /var/drydock/workingcopy-21831/repo/glasgow-haskell- compiler/libraries/Cabal/Cabal/dist-boot/doc/html/Cabal/Cabal.haddock doesn't exist or isn't a file 43 Cabal-1.25.0.0: cannot find any of ["Distribution/Backpack.hi","Distribution/Backpack.p_hi","Distribution/Backpack.dyn_hi"] (ignoring) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 12 Apr '17

12 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Changes (by winter): * cc: winter (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:71> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13565: Compiler allocations on sched in nofib regressed by 10% between 091333313 and 1883afb2
by GHC 12 Apr '17

12 Apr '17

#13565: Compiler allocations on sched in nofib regressed by 10% between 091333313 and 1883afb2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiler allocations increased from 500MB to 550MB on the `Main` module of `sched` somewhere between 09333313f32be975faf9158fcd3648489d78ad82 and 03e8d26fe0a8f7981a76550118f3c584cad76c47. Investigate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13565> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13542: Solaris build fails with collect2: execv: Arg list too long
by GHC 11 Apr '17

11 Apr '17

#13542: Solaris build fails with collect2: execv: Arg list too long -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Solaris Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It looks like HEAD build is broken on Solaris and Solaris-derived OSes. It fails with: {{{ gmake --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries /ghc-prim/dist-install/build -ilibraries/ghc-prim/dist- install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries /ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- install/build/GHC/Types.o -dyno libraries/ghc-prim/dist- install/build/GHC/Types.dyn_o gcc: error trying to exec '/usr/gcc/4.8/lib/gcc/i386-pc- solaris2.11/4.8.2/collect2': execv: Arg list too long `gcc' failed in phase `Linker'. (Exit code: 1) gmake[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 gmake: *** [all] Error 2 }}} on Solaris 11.2 and with: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries /ghc-prim/dist-install/build -ilibraries/ghc-prim/dist- install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries /ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- install/build/GHC/Types.o -dyno libraries/ghc-prim/dist- install/build/GHC/Types.dyn_o gcc: error trying to exec '/opt/local/gcc47/libexec/gcc/i486-sun- solaris2.11/4.7.4/collect2': execv: Arg list too long `gcc' failed in phase `Linker'. (Exit code: 1) libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/GHC/Types.o' failed gmake[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 Makefile:122: recipe for target 'all' failed gmake: *** [all] Error 2 }}} on SmartOS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 11 Apr '17

11 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): It looks like we have to make a space-time trade off here, if `ByteArray#` 's overhead is too large, adding a `Int#` will also cost a lot. Suppose GHC is smart enough to float all string constant out, then copying once in runtime is acceptable. Otherwise i would still want to switch space for time. Here i also propose another solution: We still keep primitive literal's type as `Addr#`, but encode the literal's byte length with UTF8 rules, that is using one byte for length less than 0x7F, two bytes for length less than 0x7FF...and so on. Then put these UTF8 encoded length header bytes in front of real bytes content. Now all we have to do left is to add a new unpack function `unpackGHCString#` to decode these header bytes first(we can reuse UTF8 code!!!), then use `memcpy` or whatever you want to do with length info. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:70> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0