November 2015 - ghc-tickets

Re: [GHC] #7660: warning: conflicting types when compiling via-C
by GHC 21 Nov '15

21 Nov '15

#7660: warning: conflicting types when compiling via-C -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: hvr Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1506 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"192dd068890701a7692890677d4cbf9f2abdb64a/ghc" 192dd068/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="192dd068890701a7692890677d4cbf9f2abdb64a" Suppress conflicting types for builtins warnings GCC 4.0 and later warn about type-conflicting prototypes for built-in functions such as `strlen`. This is a problem for the via-c backend as it generates code such as typedef void *(*(*StgFunPtr)(void))(void); extern StgFunPtr strlen(); However, by using the `-fno-builtin` flag, GCC is told not to try to auto-detect such built-in functions and instead treat them as ordinary external functions. This also suppresses this warning. This address #7660 Test Plan: IIAM Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D1506 GHC Trac Issues: #7660 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7660#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 21 Nov '15

21 Nov '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"6664ab8356f00ef0b2186f30a0d29a9c0228c045/ghc" 6664ab83/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6664ab8356f00ef0b2186f30a0d29a9c0228c045" Add DVarSet - a deterministic set of Vars This implements `DVarSet`, a deterministic set of Vars, with an interface very similar to `VarSet` with a couple of functions missing. I will need this in changes that follow, one of them will be about changing the type of the set of Vars that `RuleInfo` holds to make the free variable computation deterministic. Test Plan: ./validate I can add new tests if anyone wants me to. Reviewers: simonpj, simonmar, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1487 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7253: Top-level bindings in ghci
by GHC 21 Nov '15

21 Nov '15

#7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: roshats Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1299 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"b98ff3ccb14e36145404f075349c8689762a2913/ghc" b98ff3cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b98ff3ccb14e36145404f075349c8689762a2913" Function definition in GHCi This patch allows define and re-define functions in ghci. `let` is not required anymore (but can be used). Idea: If ghci input string can be parsed as statement then run it as statement else run it as declaration. Reviewers: mpickering, bgamari, austin Reviewed By: mpickering, bgamari, austin Subscribers: hvr, mpickering, dterei, thomie Differential Revision: https://phabricator.haskell.org/D1299 GHC Trac Issues: #7253 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7253#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 21 Nov '15

21 Nov '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"2325bd4e0fad0e5872556c5a78d1a6a1873e7201/ghc" 2325bd4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2325bd4e0fad0e5872556c5a78d1a6a1873e7201" Create a deterministic version of tyVarsOfType I've run into situations where I need deterministic `tyVarsOfType` and this implementation achieves that and also brings an algorithmic improvement. Union of two `VarSet`s takes linear time the size of the sets and in the worst case we can have `n` unions of sets of sizes `(n-1, 1), (n-2, 1)...` making it quadratic. One reason why we need deterministic `tyVarsOfType` is in `abstractVars` in `SetLevels`. When we abstract type variables when floating we want them to be abstracted in deterministic order. Test Plan: harbormaster Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1468 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11078: Access to module renaming with reifyModule, in TemplateHaskell
by GHC 21 Nov '15

21 Nov '15

#11078: Access to module renaming with reifyModule, in TemplateHaskell -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | 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 writing a bit of TemplateHaskell for stringing together QuickCheck style specifications. I require every module containing properties to export a symbol called ''axiom_set''. Then, my checkAxioms function finds all the ''axiom_set'' symbols from modules imported where I call checkAxioms. checkAxioms :: DecsQ checkAxioms = do ModuleInfo ms <- reifyModule =<< thisModule forM_ ms $ \mi@(Module _ m) -> do runIO . print =<< lookupValueName (modString m ++ ".axiom_set") The above code should find all the imported "axiom_set" symbols. However, if Module.Axioms defines axiom_set but that I imported as follows import Module.Axioms as MA my code can't find MA.axiom_set. I think either modString should return MA in the case of Module.Axioms or there should be a function that takes a symbol and a module and constructs a Name referring to the symbol in the module and considering possible renamings of modules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 21 Nov '15

21 Nov '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by niteria): * differential: Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268 => Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268, Phab:D1360, Phab:D1373, Phab:D1396, Phab:D1457, Phab:D1468, Phab:D1487, Phab:D1504, Phab:D1508 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11118: Very hard to load previously compiled .o files in ghci
by GHC 20 Nov '15

20 Nov '15

#11118: Very hard to load previously compiled .o files in ghci -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- It's extremely hard to get ghci to load .o files created previously. The upshot is that cabal repl never loads previous .o files. It did used to be also to with older ghc versions. There is currently nothing sensible cabal can do about this except to build things twice (which isn't sensible). When one compiles modules using -static -dynamic-too, then ghci will not load those .o files, even if one specifies the appropriate -dynosuf -dynhisuf. One way to get ghci to load the .o files is if one does not build the static .o files at all, and only builds with -dynamic. This means the main .o files are the dynamic ones. It's possible to do this and keep the sets of files separate, by using -dynamic -osuf dyn_o -hisuf dyn_hi for --make mode, and then again for --interactive mode. However it's then impossible to use the -dynamic-too mode, which we want since it saves time. In this mode, although ghc does indeed generate dyn_o and dyn_hi files, ghci will not load these, even if one specifies -osuf dyn_o -hisuf dyn_hi. If one tries, ghci says "[flags changed]". So it looks like the problem is that the -static -dynamic-too information gets saved into the generated dyn_hi files. The info that should be saved probably should be as if they were generated with -dynamic only. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11116: GC reports memory in use way below the actual
by GHC 20 Nov '15

20 Nov '15

#11116: GC reports memory in use way below the actual -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- The following program encodes and decodes a long list of words. The memory in use reported by the GC seems to be off by multiple gigabytes when compared to the reports of the OS. Results shown below. ghc-7.10.2, binary-0.7.6.1. {{{ #!haskell import Control.Exception (evaluate) import Control.Monad (void) import Data.Binary (encode, decode) import qualified Data.ByteString.Lazy as BSL import Data.List (isPrefixOf, foldl') import Data.Word (Word32) import GHC.Stats import System.Mem (performGC) type T = (Word32,[Word32]) main :: IO () main = do let sz = 1024 * 1024 * 15 xs = [ (i,[i]) :: T | i <- [0 .. sz] ] bs = encode xs void $ evaluate $ sum' $ map (\(x, vs) -> x + sum' vs) xs putStrLn "After building the value to encode:" printMem putStrLn $ "Size of the encoded value: " ++ show (BSL.length bs `div` (1024 * 1024)) ++ " MB" putStrLn "" putStrLn "After encoding the value:" printMem let xs' = decode bs :: [T] void $ evaluate $ sum' $ map (\(x, vs) -> x + sum' vs) xs' putStrLn "After decoding the value:" printMem -- retain the original list so it is not GC'ed void $ evaluate $ last xs -- retain the decoded list so it is not GC'ed void $ evaluate $ last xs' printMem :: IO () printMem = do performGC readFile "/proc/self/status" >>= putStr . unlines . filter (\x -> any (`isPrefixOf` x) ["VmHWM", "VmRSS"]) . lines stats <- getGCStats putStrLn $ "In use according to GC stats: " ++ show (currentBytesUsed stats `div` (1024 * 1024)) ++ " MB" putStrLn $ "HWM according the GC stats: " ++ show (maxBytesUsed stats `div` (1024 * 1024)) ++ " MB" putStrLn "" sum' :: Num a => [a] -> a sum' = foldl' (+) 0 }}} Here are the results: {{{ # ghc --make -O -fno-cse -fforce-recomp -rtsopts test.hs # time ./test +RTS -T After building the value to encode: VmHWM: 2782700 kB VmRSS: 2782700 kB In use according to GC stats: 1320 MB HWM according the GC stats: 1320 MB Size of the encoded value: 240 MB After encoding the value: VmHWM: 3064976 kB VmRSS: 3064976 kB In use according to GC stats: 1560 MB HWM according the GC stats: 1560 MB After decoding the value: VmHWM: 7426784 kB VmRSS: 7426784 kB In use according to GC stats: 2880 MB HWM according the GC stats: 2880 MB real 0m24.348s user 0m22.316s sys 0m1.992s }}} At the end of the program the OS reports 7 GB while the GC reports less than 3G of memory in use. Running the program with {{{+RTS -M3G}}} keeps VmHWM bounded at the expense of doubling the execution time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11114: Can't compile ghc on fedora 23
by GHC 20 Nov '15

20 Nov '15

#11114: Can't compile ghc on fedora 23 -------------------------------------+------------------------------------- Reporter: waghanza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I' m trying to compile (through a ''Docker'' '''container''') ghc 7.10.2 My commands are: {{{ dnf -y install @development-tools @rpm-development-tools glibc-devel ncurses-devel gmp-devel autoconf automake libtool gcc make perl python ghc happy alex git python-sphinx git clone --recursive git://git.haskell.org/ghc.git /opt/ghc git checkout ghc-7.10.2-release ./boot ./configure --prefix=/usr/local make -j$((`grep -c processor /proc/cpuinfo`+1)) }}} The '''make''' process fails. Here is the stack => https://gist.github.com/anonymous/0800967ca05e5a2c65b8 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11115: Indicate missing associated type instances
by GHC 20 Nov '15

20 Nov '15

#11115: Indicate missing associated type instances -------------------------------------+------------------------------------- Reporter: rimmington | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | 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: -------------------------------------+------------------------------------- If there is no matching instance for a typeclass that defines an associated type, GHC cannot further reduce an application of that associated type. For nested type family applications, this produces rather large error messages, eg: {{{ <interactive>:98:20: Couldn't match type ‘units-2.3:Data.Metrology.Factor.Normalize (Data.Metrology.Suspicious.Poly.SurfaceUnitFactorsOf (Data.Singletons.Prelude.Tuple.Snd (Data.Metrology.Suspicious.Poly.SplitPrefix (PrefixExp Deci) Deci Core)) units-2.3:Data.Metrology.Factor.@- '['units-2.3:Data.Metrology.Factor.F Core ('Data.Metrology.Z.S 'Data.Metrology.Z.Zero)])’ with ‘'[]’ In the expression: (25 %> centi Core) `ceilToUnit` deci Core In an equation for ‘it’: it = (25 %> centi Core) `ceilToUnit` deci Core }}} The cause of the above error message is that `Deci` is not a member of the typeclass `ExpUnitPrefix` that defines the associated type `PrefixExp`. Unfortunately this is not clear at all from the error message, and adding additional class constraints to the appropriate functions doesn't improve things. It would be nice if GHC pointed out that there is no `ExpUnitPrefix Deci` instance, or at least that `PrefixExp Deci` cannot be further reduced. I imagine this would be useful for open type families as well, but I can't comment personally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2