June 2016 - ghc-tickets

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 22 Jun '16

22 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"348f2dbb835b1208f601bb1e8daa1d1d54507eda/ghc" 348f2dbb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="348f2dbb835b1208f601bb1e8daa1d1d54507eda" Make the Ord Module independent of Unique order (2nd try) The `Ord Module` instance currently uses `Unique`s for comparison. We don't want to use the `Unique` order because it can introduce nondeterminism. This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic ordering making `Ord Module` deterministic transitively. I've run `nofib` and it doesn't make a measurable difference. See also Note [ModuleEnv determinism and performance]. This fixes #12191 - the regression, that the previous version of this patch had. Test Plan: ./validate run nofib: P112 Reviewers: simonmar, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2354 GHC Trac Issues: #4012, #12191 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11081: Implement Introspective Template Haskell
by GHC 22 Jun '16

22 Jun '16

#11081: Implement Introspective Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | 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: | TemplateHaskell/Introspective -------------------------------------+------------------------------------- This ticket is to track commentary and reactions to TemplateHaskell/Introspective, and to help the proposal not get lost. Contrary to the title of this ticket, it is not yet resolved that Introspective Template Haskell should ever be implemented. But with some of the support that it's gotten, it seemed appropriate to make a ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7198: New codegen more than doubles compile time of T3294
by GHC 22 Jun '16

22 Jun '16

#7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Distinguish between * Global registers, like R1, Sp, which are part of the calling convention, and live in fixed places * Local registers, written `x`, `y`, etc in Cmm, which are just like local variables in a programming language. There are an infinite number of them. You can't take their address. We do indeed generate loads into a local register at the start; but we expect those loads to sink downstream to their use sites, so they don't necessarily cause register pressure. It's not safe to replace them with memory loads. Example {{{ x = R1[4] call f( p, q ) ...use x... }}} We must save `x` on the stack across the call. R1 is involved in f's calling convention, so it may well change a lot. Indeed any modification to R1 is going to invalidate your saved "x = R1[4]" delayed load. Plus the double-load efficiency problem that Simon mentions. Better to load into a local variable and then sink it. Does that make sense? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 22 Jun '16

22 Jun '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by simonmar): I second what @simonpj said, amazing job, thanks for working on this! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8713: libdl, libpthread may be unwanted too
by GHC 21 Jun '16

21 Jun '16

#8713: libdl, libpthread may be unwanted too -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: Other Architecture: x86_64 (amd64) | Type of failure: GHC doesn't work Difficulty: Moderate (less | at all than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I have GHC on an unusual system [1] libdl.so.1, librt.so.1 and some others are "filter libraries": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linking is successful, libFOO.so.1 is not linked in :-) Unfortunately, runtime linker (ld.so.1) does not understand GNU ld linker scripts. And I get errors like this: {{{ # ghci -package unix GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package unix-2.7.0.0 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc- solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type) }}} The unix package v2.6 had the same issue with librt.so too, in version 2.7 libdl.so remains. I use the attached patch for GHC 7.6.3 to fix this issue. In general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB [1] http://osdyson.org -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 21 Jun '16

21 Jun '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Hi @simonpj, Sure that won't be a problem, I was already planning on writing an extended explanation of the implementation so make the code review easier and for if someone else needs to take a look at the implementation in the future :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 21 Jun '16

21 Jun '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by simonpj): Phyx, that sounds amazing! I have not idea what you are talking about -- I do not know enough about Windows and import libraries -- but for the first time we have someone who DOES actually understand looking hard at it. I always HATED the dll-split thing. Thank you. Maybe before you are done you can write a Duffers Guide to what people need to know about Windows linking to make sense of the implementation strategies you are using. With thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 21 Jun '16

21 Jun '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: I have recently taken a look at this and have an almost working version that should solve the problem once and for all. First, we don't actually have that many symbols to go over the limit. Or it seems we don't. If I measure amount of symbols in the input object files going into the link and the amount coming out, the difference is huge. Looking at it further this is because of two things. We never explicitly use `__declspec`, we just change the names of the functions to match the conventions that `__declspec` would use. This is fine, but it means that binutil's default of `--export-all-symbols` is still enabled. Which means, we'll re-export any symbol we link from archives as well. Given that `-dynamic` on Windows always produces an import library `.dll.a` and the search order for `ld` is {{{ libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll }}} Then we always end up picking the import lib. This is recursive, we link against `gmp`, `base` etc. By the time it gets to `GHC` the resulting import lib is huge and hence we blow passed the number of symbols. Also `kernel` and `gdi32` and `mingwex` etc are all import libraries for GCC. So we accumulate a ton of symbols from there as well. So the first thing my changes do is only export symbols defined in the input object files. This not only drastically reduces the size of the resulting DLLs and import libraries, it also pushes the number of symbols way way below the limit. In fact I got rid of `dll-split` all together and allow all symbols to go into the same dll and we end up with {{{ $ nm -g "R:\ghc\libHSghc-8.1-ghc8.1.20160617.dll" | wc -l 49610 }}} This down from ~240,000 (mingwex and mingw32 are huge for instance). The second thing my build changes do is that in order to prevent this from happening again, I implemented an automatic partitioning scheme which requires no special treatment of the split dlls. In case we hit the limit again, the build script will automatically detect this and do the following: It will split the symbols up per object file input. So that all symbols of the same object file are in the same DLL. Like @rassilon suggested before, I'm using `import libraries` to break the dependencies. So the specific grouping doesn't matter. The import libraries point to the location of the dll which contains the symbol: {{{ LIBRARY "libHSCabal-1.25.0.0-ghc8.1.20160617-pt2.dll" EXPORTS "__stginit_Cabalzm1zi25zi0zi0_DistributionziCompatziBinary" "__stginit_Cabalzm1zi25zi0zi0_DistributionziCompatziCopyFile" ... }}} And these are used to break the dependencies. We then end up with smaller dlls with the suffix `-pt<num>.dll` and their import libraries. The next step is to produce one large/merged import library with the name of the dll we were originally supposed to create. `libHSCabal-1.25.0.0-ghc8.1.20160617.dll.a` which is just a merging of the different `-pt` import files. This has the effect that when `-lHSCabal-1.25.0.0-ghc8.1.20160617` is used as the link argument (which we do), the import lib is found and the linker puts a reference to the right dlls. No extra/special handling is needed by any other tool. Using the import libraries essentially removes the limit, since each symbol is an object file in the archive. (note that while I recently added support for import libraries to GHCi, this support only extends to single dll import libraries. It needs some minor modifications to support this too but LD should work fine.) This works fine, and I can successfully compile a dynamic version of GHC and the program runs (but segfaults due to a piece of bit rotted code I'm looking at). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7665: dynamicToo001 fails on Windows
by GHC 21 Jun '16

21 Jun '16

#7665: dynamicToo001 fails on Windows ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7665#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12215: Debugging herald should be printed before forcing SDoc
by GHC 21 Jun '16

21 Jun '16

#12215: Debugging herald should be printed before forcing SDoc -------------------------------------+------------------------------------- Reporter: ezyang | 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: -------------------------------------+------------------------------------- When I am debugging panics or infinite loops related laziness issues (e.g., lazy interface checking), I've noticed that sometimes a debugging trace can change the strictness of a function, causing us to tag a thunk too early. Unfortunately, GHC makes it a bit difficult to tell that it's the debug trace's fault. Specifically, if the bad trace has the form `traceTc "foo" someBadSDoc`, we attempt to evaluate `someBadSDoc` before we start printing any output. That's too bad: we should FIRST output `foo`, and then force and print the rest of the SDoc. Internally, `traceTc`'s herald is implemented by catting the herald into the SDoc, so I am not sure what the best way of getting things to be lazier is. I don't think SDoc can be made to stream, so we might have to do something a little nasty like split the trace into two internal trace calls. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0