January 2017 - ghc-tickets

Re: [GHC] #605: Optimisation: strict enumerations
by GHC 06 Jan '17

06 Jan '17

#605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: I don't think this will happen for 8.2 though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/605#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10352: Properly link Haskell shared libs on ELF systems
by GHC 06 Jan '17

06 Jan '17

#10352: Properly link Haskell shared libs on ELF systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Package | Version: 7.11 system | Operating System: Linux Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since the early days of building Haskell shared libs on Linux we have been using a scheme that is really a bit of a hack. We should do it properly. In my blog post on this from 2009 (http://www.well-typed.com/blog/30/) I said: > If we use ldd again to look at the libfoo.so that we've made we will notice that it is missing a dependency on the rts library. This is problem that we've yet to sort out, so for the moment we can just add the dependency ourselves: > > $ ghc --make -dynamic -shared -fPIC Foo.hs -o libfoo.so \ > -lHSrts-ghc6.11 -optl-Wl,-rpath,/opt/ghc/lib/ghc-6.11/ > > The reason it's not linked in yet is because we need to be able to switch which version of the rts we're using without having to relink every library. For example we want to be able to switch between the debug, threaded and normal rts versions. It's quite possible to do this and it just needs a bit more rearranging in the build system to sort it out. Once it's done you'll even be able to switch rts at runtime, eg: > > $ LD_PRELOAD=/opt/ghc/lib/ghc-6.11/libHSrts_debug-ghc6.11.so > $ ./Hello So in general, if a shared lib requires symbols from another shared lib then it should depend on it. In ELF terminology that means a NEEDED entry to say this lib needs that other lib. This is important to be able to link and load these shared libraries, otherwise they can have dangling dependencies. But we don't do this. For the specific case of the RTS we do not link Haskell shared libs against the RTS. So they have lots of dangling symbols. These libraries cannot be loaded on their own, e.g. with `dlopen()`. This is bad, and has other knock-on consequences. Why don't we link to the RTS? It's because historically (with static linking) GHC had had the ability to select the flavour of the RTS when final executables are linked, not when intermediate libraries are created. This works because the RTS flavours share a common ABI. This is a useful feature as it lets us select the SMP or debug or other RTS at final link time. So when we made up the first shared lib scheme on ELF we had to support this. Our initial scheme was like this: don't link Haskell library DSOs against the RTS, only like the final exe against the RTS. Each RTS flavour has a separate SONAME, e.g. `libHSrts_thr-ghc7.8.4.so` or `libHSrts_debug- ghc7.8.4.so`. This works because the runtime linker looks at the final exe first and loads the RTS, and then when other libs are loaded the symbols all resolve. Why can't we link all the libraries against the RTS? Currently each RTS flavour has a different SONAME, which is the key that the dynamic linker uses to identify each library. So if we did link all the Haskell libs against "the" RTS we would have to pick which one at the point at which we create the library, and that'd stop us from being able to choose later. So, can we use a better scheme? We want one that doesn't leave dangling undefined references in intermediate Haskell libs, and is also compatible with the ability to select the flavour of the RTS at final exe link time (or even override it at load time). Yes we can! The first thing to note is that to be interchangeable, all the RTS flavours (that share a compatible ABI) need to have the same SONAME. So for example, all the (non-profiling) RTS DSO files have to have the internal SONAME of `libHSrts-ghc7.8.4.so`. Once they all have the same SONAME, then it's ok for all the Haskell libs to specify a NEEDED dependency on that rts SONAME. But if they have the same SONAME, what do the files get called, where do they live and how are they found? The trick is to make use of the search path. Put each RTS flavour in a different directory, but otherwise with the same filename, e.g. `lib/rts-1.0/thr/libHSrts-ghc7.8.4.so`, `lib/rts-1.0/debug/libHSrts-ghc7.8.4.so` etc. Each library DSO and exe has its list of NEEDED entries, and it has an RPATH entry used to find those libraries if they're not loaded yet. The key is the "if they're not loaded yet" bit. Remember that the linker uses the SONAME as the key to decide if the lib is loaded yet or not. So the libraries could all have an RPATH entry to say to look for the RTS in the directory containing the default RTS flavour. But then the top level exe (or foreign/export shared lib) can also link to the RTS directly (ie an NEEDED entry) and can specify an RPATH which can be for any of the rts flavours. When the linker loads the top level exe, it will loads the selected RTS using the exe's RPATH, and then when the linker sees other Haskell libs that have a NEEDED entry on the RTS it will ignore them because the RTS's SONAME is already loaded. So concretely, instead of: lib/ghc-${ver}/rts-1.0/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_debug-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_l-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr_l-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr_debug-ghc${ver}.so each with a different SONAME we'd have lib/ghc-${ver}/rts-1.0/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/debug/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/l/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr_l/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr_debug/libHSrts-ghc${ver}.so each with the same SONAME When linking libs we would always use `-lHSrts -rpath lib/ghc-${ver}/rts-1.0` When linking exes (or shared libs for external consumption) we would use both `-lHSrts` and `-rpath lib/ghc-${ver}/${rtsflavour}/rts-1.0`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10352> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9248: Document -XHaskell98 and -XHaskell2010 in flag reference
by GHC 06 Jan '17

06 Jan '17

#9248: Document -XHaskell98 and -XHaskell2010 in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12426: Allow smart constructors their own types
by GHC 06 Jan '17

06 Jan '17

#12426: Allow smart constructors their own types -------------------------------------+------------------------------------- Reporter: dfeuer | 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: -------------------------------------+------------------------------------- GHC currently offers one-way pattern synonyms allowing general deconstruction with nice syntax. And it offers bidirectional pattern synonyms, which toss in construction functions that start with capital letters. Unfortunately, it forces the construction and deconstruction sides to share a type. This is sometimes rather unfortunate. The documentation itself points out the limitation with regard to matching numeric literals (where deconstruction requires `Eq`). Another example is Edward Yang's `NF` type, whose smart constructor (but not deconstructor) requires `NFData`. I think the easiest fix is to allow a type signature in the `where` clause of a pattern synonym definition. {{{#!hs pattern X :: Eq a => a -> Foo pattern X q <- ... where X :: X a => a -> Foo X a = ... }}} Ideally, I'd like to offer the other one-way (constructor without pattern) as well, but I care less about that. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11096: Builtin encoder/decoder should be used for Latin-1
by GHC 06 Jan '17

06 Jan '17

#11096: Builtin encoder/decoder should be used for Latin-1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Filed on behalf of hvr. Currently `mkTextEncoding'` delegates decoding/encoding from/to latin-1 to `iconv`. This shouldn't be necessary as we have latin-1 an encoder in `base`. Let's use it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers
by GHC 06 Jan '17

06 Jan '17

#12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers --------------------------------------+---------------------------------- Reporter: geraint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- In ghci 8.0.1 on my mac, expressions no bigger than {{{2^(10^7) :: Integer}}} usually cause a bus error; {{{2^(10^6)}}} is apparently OK. The force of "usually" is that every now and then they and larger expressions are fine, so it is not quite reproducible. I believe it's the Integer arithmetic library, rather than the exponentiation, and I think it might be a stack overflow in libHSinteger- gmp-1.0.0.1-ghc8.0.1.dylib The problem was first encountered with compiled code doing additions and multiplications on similarly sized Integer values. Substantially larger numbers can be handled by 7.8.4 on other platforms, which is all I have to compare it with. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12954> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 06 Jan '17

06 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * priority: normal => high * status: infoneeded => new * milestone: => 8.2.1 Comment: This is still applicable and was reported again as #12954. I don't understand why we can't just update the in-tree GMP version; hvr, can you elaborate? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5344: CSE should look through coercions
by GHC 05 Jan '17

05 Jan '17

#5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: cse 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => low * status: closed => new * resolution: duplicate => * owner: simonpj => Comment: OK, I think reopening (with milestone _|_) is appropriate then. Also setting priority to low in view of this case being handled by #9291; to be re-raised if someone comes up with a compelling reason to do the CSE earlier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5344#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5344: CSE should look through coercions
by GHC 05 Jan '17

05 Jan '17

#5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: duplicate | Keywords: cse 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: | -------------------------------------+------------------------------------- Comment (by nomeata): Indeed it is easier as it can done by task. But I still believe type- changing CSE on the Core level is a research paper quality problem (and an interesting one!). We could keep this ticket open for that point in the design space, so if you want, feel free to reopen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5344#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 05 Jan '17

05 Jan '17

#7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): @Phyx- Hi, Sorry for the lack of updates. Some parts of this are working, but in general my patches are not yet ready for inclusion in GHC and I haven't had time to work on them during the last six months. I do still want to finish this, but can't guarantee it will happen in time for 8.4. Anyone willing to help out is welcome to take a look at * https://github.com/23Skidoo/haskell-iocp and * https://github.com/23Skidoo/ghc/tree/ghc-8.0-windows-iocp and ask me any questions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7353#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0