- ghc-tickets - Haskell.org

Re: [GHC] #7206: Implement cheap build
by GHC 20 Feb '18

20 Feb '18

#7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > The result is the same; only allocation difference is in `cacheprof` Ignore `cacheprof` until https://ghc.haskell.org/trac/ghc/ticket/8611 is fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7206: Implement cheap build
by GHC 20 Feb '18

20 Feb '18

#7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I rebased the `cheap-build` branch, applied the idea in #13422 to `Word` and `Char` enumerations (`Int` was already implemented), verified that it works as expected, and run nofib again. The result is the same; only allocation difference is in `cacheprof`. Runtimes differ, but when I compared STG outputs I see that they're identical even though runtime differs a few percent. So they're really just noise. I suspect runtime results in comment:13 are also of this nature. I was thinking that this optimization can be done with little user intervention by adding an `INLINE` pragma, but surprisingly it doesn't work. In the example from #13422: {{{ foo :: Int -> Int foo n = s + p where nums = [1..n] s = sum nums p = product nums }}} adding `INLINE` to nums (in original GHC, without `cheap-build` patch) does not make it fuse. However if I manually inline it (substitute `[1..n]` for `nums`) it fuses as expected. Not sure if this is a bug or not, but it's certainly surprising to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14312: Head does not build on Windows with the default make config.
by GHC 20 Feb '18

20 Feb '18

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Cloning head and just running: {{{ ./boot ./configure --enable-tarballs-autodownload make }}} Fails since at least two weeks and still does as of a4ee28978acbcf68da9dfb6f198cb6e1ff38ccca The main issue is the directory library fails to build. Creating a build.mk file and setting the Flavour to quick GHC does build as expected. What triggers the failure seems to be the windows.h file created by the directory library which in some way includes itself in a loop until the preprocessor/c-compiler gives up. Renaming the file locally seems to be a viable workaround. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 20 Feb '18

20 Feb '18

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bfrk): I have gradually changed my opinion on this some over the years. I no longer think that writing explicit interface files is too much of a burden. Indeed it can have great advantages to do so, but I would prefer a proper integration into Haskell the language. The current situation is not ideal: (1) hs-boot is an obscure name for an interface definition (2) it is an implementation defined feature, outside of the language (3) it is unclear to me how it interacts with the use of export lists; ideally I would want to be able to use interface definition files as an alternative to export lists (4) it should not be necessary to repeat in the .hs file anything that is already fully defined in the interface definition file (incomplete definitions are exempted) (5) it should be possible to place the interface definition in a distinguished "header" part of the .hs, so that it need not be in a separate file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:74> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 20 Feb '18

20 Feb '18

#7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 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: | -------------------------------------+------------------------------------- Comment (by kcsongor): Replying to [comment:24 simonpj]: > > This is currently imperilled by #14420. > > How, exactly? #14420 means that one can define a distinguishable member of any kind, bringing back `Any` {{{ data family Any :: k }}} Isn't this what caused the original soundness issue? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7259#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 20 Feb '18

20 Feb '18

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not sure which comment you are replying to; and I fear I don't understand what "something like this" is. The big trouble with recursive modules is that: either you need a programmer written signature file (i.e. `.hs-boot`) or you have to compile all the modules in the SCC at once. I don't see any other path. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:73> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 20 Feb '18

20 Feb '18

#7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > This is currently imperilled by #14420. How, exactly? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7259#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14788: `error` in GHC internals can disappear by rerunning ghc again
by GHC 19 Feb '18

19 Feb '18

#14788: `error` in GHC internals can disappear by rerunning ghc again -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #14533 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was messing around with GHC's source code and thus triggered a bug, manifesting in my case as the `pprPanic "applyTypeToArgs" panic_msg` in `applyTypeToArgs` in GHC 8.2.1. Expectedly, ghc died with `the 'impossible' happened` while compiling a package (in my case `vector`). With output like this (it's not important to read the output in detail, only to see the `.o` file involved): {{{ [17 of 21] Compiling Data.Vector.Storable.Mutable ( Data/Vector/Storable/Mutable.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.2/build/Data/Vector/Storable/Mutable.o ) Data/Vector/Storable/Mutable.hs:77:1: warning: [-Wunused-imports] The import of ‘Foreign.Ptr’ is redundant except perhaps to import instances from ‘Foreign.Ptr’ To import instances alone, use: import Foreign.Ptr() | 77 | import Foreign.Ptr | ^^^^^^^^^^^^^^^^^^ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): applyTypeToArgs Expression: n#_aKi p_a3X ds5_XM4 ds7_aKj x#_aKa eta_X1H Type: Int# Args: [p_a3X, ds5_XM4, ds7_aKj, x#_aKa, eta_X1H] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreUtils.hs:226:14 in ghc:CoreUtils }}} What I did not expect was that by rerunning my `ghc --make` invocation again, the error would disappear! This is because after the error, the `.o` file is corrupt, just cut off in the middle. The reason is probably that GHC writes the `.o` file contents from an expression that can contain `error` thunks deep in, so the error only surfaces in the middle of the writing. As a result, the `.o` file is touched and `ghc --make` build pipeline, when resumnig the build next time, thinks that the `.o` file was completed all fine. I think `ghc --make` should not write the `.o` file when there's an obvious error. I suggest that ghc either `deepseq` the string to be written to the `.o` file before calling `writeFile` or equivalent, or write the file to an `.o.tmp` file and rename the temp file upon completion. The latter approach would also help against corrupted files due to power loss, see #14533. Fixing this would make developing GHC easier, as right now you can accidentally continue from a completely broken state (corrupt `.o` file) and only notice the error much later and then have to backtrack. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #602: Warning Suppression
by GHC 19 Feb '18

19 Feb '18

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Design/LocalWarningPragmas | -------------------------------------+------------------------------------- Comment (by simonpj): Same request made in #14805. It looks like a very reasonable request to me; but (especially since GHC has to move code around when doing strongly-connected component analysis of type and value bindings) not entirely straightforward to implement. Needs someone to propose a concrete design and implementation path. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11791: Remove the `isInlinePragma prag` test
by GHC 19 Feb '18

19 Feb '18

#11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11781, #5928 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of tickjet:11781#comment:9, where simonpjs writes: > What is more mysterious to me is why the unfolding for `$fApplicativeIO_$c*>` doesn't have `bindIO`, and then `bindIO` inlined into it, which would allow a cascade of further improvements, which would, I think, produce essentially the same code as `thenIO`. > > The offending corner is this > {{{ > active_unfolding_gentle id > = isInlinePragma prag -- WHY?? > && isEarlyActive (inlinePragmaActivation prag) > }}} > So I tried removing the `isInlinePragma prag` test, and indeed the code becomes identical. > > Conclusion: > * I'd love to make the above change to `active_unfolding_gentle` and see if any other performance numbers budge. I doubt that anything will change a lot -- it really only affects whether optimisation happens before or after inlining -- but it should improve compiler performance a bit for that very reason. This could be a separate ticket > > Incidentally, see #5928 which is somewhat related. This ticket tracks that idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3