- ghc-tickets - Haskell.org

[GHC] #12138: Simplifier ticks exhausted at compiling svg-builder
by GHC 04 Jun '16

04 Jun '16

#12138: Simplifier ticks exhausted at compiling svg-builder -------------------------------------+------------------------------------- Reporter: JanUlrich | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to install svg-builder by "cabal install svg-builder"and got the following error: Resolving dependencies... Configuring svg-builder-0.1.0.1... Building svg-builder-0.1.0.1... Preprocessing library svg-builder-0.1.0.1... [1 of 5] Compiling Graphics.Svg.Path ( src/Graphics/Svg/Path.hs, dist/build/Graphics/Svg/Path.o ) [2 of 5] Compiling Graphics.Svg.Core ( src/Graphics/Svg/Core.hs, dist/build/Graphics/Svg/Core.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:Foreign.Storable.$fStorableWord21{v r2cT} [gid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 34200 I tried again with ghc -fsimpl-tick-factor=300 and it worked. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7437: peculiar behaviour with default instances and type variables
by GHC 04 Jun '16

04 Jun '16

#7437: peculiar behaviour with default instances and type variables -------------------------------------+------------------------------------- Reporter: bos | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #12151 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #12151 Comment: I wished I had added that test already, because now this issue has regressed. See #12151. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7437#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12129: Optimize the implementation of minusInteger in the integer-gmp package
by GHC 04 Jun '16

04 Jun '16

#12129: Optimize the implementation of minusInteger in the integer-gmp package -------------------------------------+------------------------------------- Reporter: admock | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As mentioned in [https://www.fpcomplete.com/blog/2016/05/weigh-package] the current implementation of `minusInteger` is {{{#!hs minusInteger x y = inline plusInteger x (inline negateInteger y) }}} which always allocates an additional integer. This could be improved by not always calling `negateInteger` and instead having an implementation more like `plusInteger`'s. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12059: Add primop to query for pinned-ness of a ByteArray
by GHC 04 Jun '16

04 Jun '16

#12059: Add primop to query for pinned-ness of a ByteArray -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- It would be useful to have, {{{#!hs isPinnedByteArray# :: MutableByteArray# -> Int# }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

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

04 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 -------------------------------------+------------------------------------- Changes (by ryantrinkle): * cc: ryan.trinkle@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex
by GHC 04 Jun '16

04 Jun '16

#11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 7.10.3 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #10726 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting. If a symbol is needed that isn't re-exported (e.g. `log1p`) then this code can't be run in GHCi because it will result in a duplicate symbols error. A workaround The `rts` seems to be a special case again. The linker seems to ignore the `extra-libraries` from the `package.conf`, which explains why you can put anything you want in there and it'll still compile. {{{ 128 emptyPLS :: DynFlags -> PersistentLinkerState 129 emptyPLS _ = PersistentLinkerState { 130 closure_env = emptyNameEnv, 131 itbl_env = emptyNameEnv, 132 pkgs_loaded = init_pkgs, 133 bcos_loaded = [], 134 objs_loaded = [], 135 temp_sos = [] } 136 137 -- Packages that don't need loading, because the compiler 138 -- shares them with the interpreted program. 139 -- 140 -- The linker's symbol table is populated with RTS symbols using an 141 -- explicit list. See rts/Linker.c for details. 142 where init_pkgs = [rtsUnitId] }}} I've tried 2 approaches which haven't worked completely: 1. I tried removing the symbols from the export list and adding `libmingwex` to the rts's `package.conf`and have it just link against it. But turns out the `rts`'s `package.conf` is ignored on all platforms. I didn't want to have to make an exception for Windows here and I don't know why the other platforms also ignore it so I abandoned this approach. 2. I tried marking the symbols we're re-exporting as weak symbols, so there wouldn't be a change to existing code and would allow you to link against `libmingwex`. But unfortunately because of when the other libraries specified by `-l` are linked in, some of the symbols have already been used and thus aren't weak anymore. So I still get duplicate link errors. What I want to try now is leaving them as weak symbols, but loading `libmingwex.a` at `rts` initialization time. Much like how `kernel32` is loaded. This is hopefully early enough that the symbols haven't been used yet. Example (LogFloat.hs file): {{{#!hs module Main (main) where import Data.Number.LogFloat (log1p) main :: IO () main = print $ log1p 1.0 }}} `runGhc LogFloat.hs` will fail: {{{ Loading package logfloat-0.13.3.3 ... linking ... LogFloat.hs: ...\x86_64-windows- ghc-7.11.20151123\logfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn\HSlogfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn.o: unknown symbol `log1p' LogFloat.hs: LogFloat.hs: unable to load package `logfloat-0.13.3.3' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

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

04 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:"2046297ec03bdcd4901f69cd6ae03e84dc974683/ghc" 2046297e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2046297ec03bdcd4901f69cd6ae03e84dc974683" Document putSymbolTable determinism Like explained in the comment it's OK here. Test Plan: ./validate Reviewers: bgamari, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2298 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

04 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:"9cc6fac5c096eb4120173495faf2c948f7a28487/ghc" 9cc6fac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9cc6fac5c096eb4120173495faf2c948f7a28487" Make FieldLabelEnv a deterministic set This lets us kill fsEnvElts function which is nondeterministic. We also get better guarantees than just comments. We don't do lookups, but I believe a set is needed for deduplication. Test Plan: ./validate Reviewers: bgamari, mpickering, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2297 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12148: GHC 8 crash when building "chatter" library
by GHC 03 Jun '16

03 Jun '16

#12148: GHC 8 crash when building "chatter" library --------------------------------------+--------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- While I try to build "chatter" library from GitHub with Stack with GHC 8.0 resolver I got that crash: [ 9 of 23] Compiling NLP.Corpora.Brown ( src\NLP\Corpora\Brown.hs, .stack- work\dist\b7fec021\build\NLP\Corpora\Brown.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying RuleFired Class op unsafeShiftR To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 11403800 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #4479: Implement TDNR
by GHC 03 Jun '16

03 Jun '16

#4479: Implement TDNR -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.5 checker) | 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 AntC): Replying to [comment:27 gidyn]: > There's a proposal for TDNR without syntax changes at SyntaxFreeTypeDirectedNameResolution. Hmm. That really is not up to being called a 'proposal'. Contrast its hand-waving with the careful detail in the original TDNR. I've added a couple of links to a ghc-users thread and to what Adam has just delivered in 8.0 DuplicateRecordFields. I think what Adam has delivered is a reasonable stab at the TDNR idea without changing any syntax. (I've made that point several times in the discussion.) I've not seen any detailed explanation that would disagree with that. (There is comment about the full ORF Part 3 Magic type classes.) If it was my call, and assuming this ticket 4479 is about TDNR, I would close this as fixed by DuplicateRecordFields. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0