- ghc-tickets - Haskell.org

[GHC] #10666: Distinguish between semantic module / identity module in TcGblEnv, ModIface and ModGuts
by GHC 22 Nov '15

22 Nov '15

#10666: Distinguish between semantic module / identity module in TcGblEnv, ModIface and ModGuts -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Package | Version: 7.10.1 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When we write a signature like {{{ package p where signature H where data T }}} and compile it to an interface file, there are two ways we might say what the `Module` of this interface is: 1. The **identity module** uniquely identifies an interface file, and is used for dependency analysis and tracking. In the example above, the identity module is `p(H -> HOLE:H):H`. 2. The **semantic module** tells us what the `Name`s of the entities defined in the module are supposed to be; e.g., it's used for generating new names when type-checking hs files or interfaces. In the example above, the semantic module is `hole:H`, since this signature exports one entity named `hole:H.T`. The semantic module can always be derived from the identity module. For normal Haskell modules, the semantic and identity module coincide. However, for signatures they differ: we may have many signatures for the same module; they all share their semantic module but have differing identity modules. By in large, when GHC manipulates `Module` directly it is interested in the identity module. However, when a `Module` is used with reference to a `Name` (primarily `nameIsLocalOrFrom`), we want to use the SEMANTIC module. (Another example: when we filter out the type environment before making a `ModIface`, need to filter against the semantic module.) I tried a few ways of factoring GHC's code so we'd be less likely to confuse these two `Module`s when typechecking signatures: the big problem is if you're adding a `getModule` call to `TcRn`, you're probably not going to think too hard whether or not you actually wanted the semantic module or the identity module. But if you pick the wrong thing that will break all sorts of things for signatures. Here are some things we could do: 1. My initial attempt was to change `tcg_mod`, `mg_module` and `mi_module` to record a new data type `TopModule` which recorded both the semantic and identity module, with `getModule` in `TcRn` continuing to return a semantic module, but `mi_module` returning an identity module. However, the resulting patch was pretty ugly and it's not altogether clear that `getModule` returning the semantic module is always correct. 2. My other idea is to say that these entries always are IDENTITY modules (this will result on fail fast behavior for signatures if you get it wrong), and then rewrite `nameIsLocalOrFrom`, `externaliseAndTidyId`, `initIfaceTcRn`, `newGlobalBinder` so that they always do the right thing (i.e. use the semantic module); thus, the only time you can get it wrong is if you're creating some new functionality that's not these functions that needs to use semantic modules. Pretty delicate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports
by GHC 22 Nov '15

22 Nov '15

#10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Here are two issues with our GHCi support for foreign prim imports: Here is a program that works: {{{ {-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-} module Serum where import GHC.Exts foreign import prim "cheneycopy" cheneycopy :: Word# -> State# RealWorld -> (# State# RealWorld, Word# #) }}} If I remove the world token passing, as in here: {{{ {-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-} module Serum where import GHC.Exts foreign import prim "cheneycopy" cheneycopy :: Word# -> Word# }}} I get: {{{ (GHC version 7.10.1 for x86_64-unknown-linux): ByteCodeGen.generateCCall: missing or invalid World token? }}} Another error is if I try to pass Any as an argument: {{{ {-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-} module Serum where import GHC.Exts foreign import prim "cheneycopy" cheneycopy :: Any -> State# RealWorld -> (# State# RealWorld, Word# #) }}} Then I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): primRepToFFIType }}} Note to anyone who is running into this problem: an easy workaround is to use `-fobject-code` which bypasses bytecode generation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10462> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9651: Increasing verbosity doesn't give useful information for why we couldn't load package
by GHC 22 Nov '15

22 Nov '15

#9651: Increasing verbosity doesn't give useful information for why we couldn't load package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I don't time to fix this now, so recording so I remember. {{{ [ezyang@hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc- stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf -v GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.9.20140929, stage 2 booted by GHC version 7.8.3 Using binary package database: /home/hs01/ezyang/ghc- head/inplace/lib/package.conf.d/package.cache Using binary package database: libraries/bootstrapping.conf/package.cache *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: <command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) [ezyang@hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc- stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help <command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) [ezyang@hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc- stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf -v GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.9.20140929, stage 2 booted by GHC version 7.8.3 Using binary package database: /home/hs01/ezyang/ghc- head/inplace/lib/package.conf.d/package.cache Using binary package database: libraries/bootstrapping.conf/package.cache *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: <command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9651> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8079: Redo T7919 with a cabal file
by GHC 22 Nov '15

22 Nov '15

#8079: Redo T7919 with a cabal file -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Right now T7919 fails because the new dynamic-by-default GHC means that Template Haskell must be built with dynamic; of course, GHC isn't clever enough to figure this out. If we Cabalize the test, the example should start building again (and if they don't, well, that's a bug!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8199: Get rid of HEAP_ALLOCED
by GHC 22 Nov '15

22 Nov '15

#8199: Get rid of HEAP_ALLOCED ----------------------------------------------+---------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- This bug is to track progress of removing HEAP_ALLOCED from GHC, promising faster GC, as long as we can keep the cost of indirections down. The relevant wiki article: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; we are implementing method 2. The attached patchset is *almost* able to support GHC itself; a ghc-stage2 built this way can compile most files, but is much slower in some cases, and probably has some correctness bugs. Improvements possible: * Don't pay for a double indirection when -fPIC is turned on. Probably the easiest way to do this is to *not* bake in the indirections into compiled code when it is -fPIC'd, and instead scribble over the GOT. However, I don't know how to go backwards from a symbol to a GOT entry, so we might need some heinous assembly hacks to get this working. * Closure tables should have their indirections short-circuited by the initialization code. * We are paying an indirection when a GC occurs when the closure is not in R1. According to the wiki page, technically this is not needed, but I don't know how to eliminate references to the closure itself from stg_gc_fun. * Properly handle the Windows DLL case (e.g. SRTs); this should be simpler now that everything is an indirection. * Bikeshed hs_main API changes (because closures are not valid prior to RTS initialization, so you have to pass in an indirection instead) * Improve static indirection and stable pointer registration, avoiding binary bloat from `__attribute(constructor)__` stubs. * Need to implement a new megablock tracking structure so we can free/check for lost blocks -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

Re: [GHC] #7790: Add dummy undefined symbols to indicate ways
by GHC 22 Nov '15

22 Nov '15

#7790: Add dummy undefined symbols to indicate ways -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => low -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7790#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7746: Support loading/unloading profiled objects from a profiled executable
by GHC 22 Nov '15

22 Nov '15

#7746: Support loading/unloading profiled objects from a profiled executable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: lowest | Milestone: ⊥ Component: Runtime System | Version: 7.7 (Linker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 4837, 5435, 8039 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * blockedby: 5435, 8039 => 4837, 5435, 8039 Comment: Fixed by #4837! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7746#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5082: Emit warnings when conflicting flags are supplied
by GHC 22 Nov '15

22 Nov '15

#5082: Emit warnings when conflicting flags are supplied -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => wontfix -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5082#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

22 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 22 Nov '15

22 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