- ghc-tickets - Haskell.org

[GHC] #11373: GHC should support static archive creation on all systems
by GHC 08 Jan '16

08 Jan '16

#11373: GHC should support static archive creation on all systems -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Currently, we have in `DriverPipeline.hs`: {{{ linkStaticLibCheck :: DynFlags -> [String] -> [UnitId] -> IO () linkStaticLibCheck dflags o_files dep_packages = do when (platformOS (targetPlatform dflags) `notElem` [OSiOS, OSDarwin]) $ throwGhcExceptionIO (ProgramError "Static archive creation only supported on Darwin/OS X/iOS") linkBinary' True dflags o_files dep_packages }}} Seems a bit odd/awful for this to only work on OS X. Either we should support none of it (not GHC's job) or all of it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1853: hpc mix files for Main modules overwrite each other
by GHC 08 Jan '16

08 Jan '16

#1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by ezyang): So, in some sense, you are actually completely screwed, because at runtime the executable producing Tix files has no idea if it was compiled from `Main1.hs` or `Main2.hs`: the symbol names for the two executables live in the same namespace, etc. There is actually a very cunning way this problem could be fixed: 1. `-main-is` could be extended to work with modules which are not in the `main` package. 2. Executables could then be compiled while setting `-package-name` to something that is not `main`. Then the symbol names would be different and you could merge them reliably. The alternative is that HPC can be told explicitly that a mix file is for a specific file name (extending it's model to not be profiling a pile of `Module`s, but a pile of `Module`s or files). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1853#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #10186, #10139, #9554, #10140, #10132, #10112, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10186, #10139, #9554, #10140, #10132, #10112, #10026, #10040, #9973, #9972, #9939 by thomie: milestone to 8.0.1 Action: leave -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10186%2C10139%2C9554%2C10140%2C101…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9969: panic in T7562
by GHC 07 Jan '16

07 Jan '16

#9969: panic in T7562 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: T7562 | Blocked By: Blocking: | Related Tickets: #7562 Differential Revisions: | -------------------------------------+------------------------------------- Various people observe this test failure: {{{ =====> T7562(normal) 869 of 4389 [0, 0, 0] cd ./typecheck/should_compile && '/home/jojo/build/haskell/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci- history -c T7562.hs -fno-warn-incomplete-patterns >T7562.comp.stderr 2>&1 Compile failed (status 256) errors were: T7562.hs:3:14: Warning: UNPACK pragma lacks '!' on the first argument of ‘Pair2’ In the definition of data constructor ‘Pair2’ In the data declaration for ‘Pair2’ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150108 for x86_64-unknown-linux): toIfaceBang Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} According to my logs, this was caused by changeset:9564bb8c84cbc0397a414e946cc8c28801f0fbe7/ghc -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] Batch modify: #10407, #10384, #9851, #10306, #10121, #10325, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10407, #10384, #9851, #10306, #10121, #10325, #10281, #10180, #10265, #9958, #10191 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10407%2C10384%2C9851%2C10306%2C101…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #8555, #8799, #9131
by GHC 07 Jan '16

07 Jan '16

Batch modification to #8555, #8799, #9131 by thomie: Action: leave Comment: For future reference: commit 0cc47eb90805f3e166ac4d3991e66d3346ca05e7 {{{ Author: Richard Eisenberg <eir(a)cis.upenn.edu> Date: Fri Dec 12 17:19:21 2014 -0500 Rewrite `Coercible` solver Summary: This is a rewrite of the algorithm to solve for Coercible "instances". A preliminary form of these ideas is at https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver The basic idea here is that the `EqPred` constructor of `PredTree` now is parameterised by a new type `EqRel` (where `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can now talk about nominal equality (the usual case) or representational equality (the `Coercible` case). This is a change from the previous behavior where `Coercible` was just considered a regular class with a special case in `matchClassInst`. Because of this change, representational equalities are now canonicalized just like nominal ones, allowing more equalities to be solved -- in particular, the case at the top of #9117. A knock-on effect is that the flattener must be aware of the choice of equality relation, because the inert set now stores both representational inert equalities alongside the nominal inert equalities. Of course, we can use representational equalities to rewrite only within another representational equality -- thus the parameterization of the flattener. A nice side effect of this change is that I've introduced a new type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness in the flattener. This commit includes some refactoring as discussed on D546. It also removes the ability of Deriveds to rewrite Deriveds. This fixes bugs #9117 and #8984. Reviewers: simonpj, austin, nomeata Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D546 GHC Trac Issues: #9117, #8984 }}} -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=8555%2C8799%2C9131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #10670, #10632, #10463, #10570, #10561, #10351, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10670, #10632, #10463, #10570, #10561, #10351, #9665, #10573, #10414, #10519, #10569, #10420, #10503, #10533, #10211, #10485, #10474, #10461, #10466, #10423, #8292 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10670%2C10632%2C10463%2C10570%2C10…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9960: Performance problem with TrieMap
by GHC 07 Jan '16

07 Jan '16

#9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Looking at #9805 reminded me. When investigating the performance of #9872 I found a major performance hole in `TrieMap`. Suppose we have a handful H of entries in a `TrieMap`, each with a very large key, size K. If you fold over such a `TrieMap` you'd expect time O(H). That would certainly be true of an association list! But with `TrieMap` we actually have to navigate down a long singleton structure to get to the elements, so it takes time O(K*H). This is pretty bad. In test `T9872` I found that 90% of compile time was spent in `TrieMap` as we repeatedly built, folded, and then rebuilt `TrieMap`s. I fixed that by keeping smaller `TrieMap`s, but the underlying problem remains. The point of a `TrieMap` is that you need to navigate to the point where only one key remains, and then things should be fast. So I think that `TypeMap`, say, should look like {{{ data TypeMap a = EmptyTM | SingletonTM Type a | TM { tm_var :: VarMap a , tm_app :: TypeMap (TypeMap a) , tm_fun :: TypeMap (TypeMap a) , tm_tc_app :: NameEnv (ListMap TypeMap a) , tm_forall :: TypeMap (BndrMap a) , tm_tylit :: TyLitMap a } }}} The `SingletonTM` means that, once you are down to a single (key,value) pair, you stop and just use `SingletonTM`. Tiresomely, because of the deBruijn thing, it'd need to be {{{ ... | SingletonTM (CMEnv, Type) a ... }}} and we'd need an auxiliary function for equality: {{{ eqTypeModuloDeBruijn :: (CMEnv, Type) -> (CEnv, Type) -> Bool }}} But that's not hard. Very similar to the way `RnEnv2` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] Batch modify: #10558, #10567, #10742, #10540, #10753, #10609, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10558, #10567, #10742, #10540, #10753, #10609, #10721, #10615, #10704, #10706, #10694, #10586, #10134, #8253, #10522 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10558%2C10567%2C10742%2C10540%2C10…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10744: Allow oneShot to work with unboxed types
by GHC 07 Jan '16

07 Jan '16

#10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature | Status: new request | 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 Revisions: | -------------------------------------+------------------------------------- Currently `oneShot` requires that both the argument type and the return type of the given function have the kind `*`. It would be nice if I could use unlifted types there. The following program demonstrates this: {{{#!hs {-# LANGUAGE MagicHash #-} module Foo where import GHC.Exts import GHC.Magic f0 :: Int -> Int f0 = oneShot $ \n -> n -- OK f1 :: Int# -> Int f1 = oneShot $ \n# -> I# n# -- Error, the argument type is unlifted f2 :: Int -> Int# f2 = oneShot $ \(I# n#) -> n# -- Error, the result type is unlifted }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16