- ghc-tickets - Haskell.org

[GHC] #15420: executable with library and template haskell doesn't compile statically
by GHC 20 Jul '18

20 Jul '18

#15420: executable with library and template haskell doesn't compile statically -------------------------------------+------------------------------------- Reporter: tiny | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See the attached program. Make sure to compile it under a cabal sandbox so that it picks up the static compilation options in cabal.config. It doesn't compile, complaining about a missing dynamic (.so/.dll) library although everything should be static. It does work if either - the static compilation options are left out of cabal.config and everything compiles dynamically, or - the `tmp` variable from Main.hs is removed, or - the staticth library import is removed from the executable (remove dependency in staticth.cabal and import statement from Main.hs). If all 3 are present it doesn't compile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5793: make nofib awesome
by GHC 20 Jul '18

20 Jul '18

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #15357 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 19 Jul '18

19 Jul '18

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.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: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12606: Linux (ELF) Support for "ghc -static -shared"
by GHC 19 Jul '18

19 Jul '18

#12606: Linux (ELF) Support for "ghc -static -shared" ----------------------------------------+--------------------------------- Reporter: tmobile | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- On some platforms it is possible to create a stand-alone shared library out of some object `Foo.o` including foreign exports with something like: `ghc -static -shared Foo.o ...` The resulting library will have `Foo`'s dependencies including `base` as well as the RTS statically linked in. On BSDs this is possible because generating position independent code is the default there, and on Windows this is possible because the dynamic loader uses some magic that doesn't require position independent code. Unfortunately on Linux this is not possible because `libHSbase`, `libHSrts`, etc. are not built with `-fPIC` unless one specifically asks for it when building GHC. As far as I know this is the only way to get `-static -shared` to work on this platform. There are use cases for compiling Haskell code into a single shared object that does not have additional runtime dependencies. Suppose one wishes to write a plugin for a program in Haskell. It would be nice to provide the plugin as a single shared object, rather than requiring GHC's libraries to be present at runtime as well. An easy solution might be adding a switch to the configure script or `build.mk` to make it easier to build GHC+libs with `-fPIC` on Linux. Ideally it would be possible to build and install both PIC and non-PIC libraries and have GHC choose the correct one at link time based on the flags and target platform, since PIC code carries a small space/performance overhead and isn't necessary on Linux in most cases. I don't know my way around GHC(outside of the GHC API) or the build system that well yet, but if adding extra build system flags and GHC link-time flag handling code to make this work is an acceptable solution I'm happy to spend the time to get this working. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4
by GHC 19 Jul '18

19 Jul '18

#15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: m68k | Type of failure: Incorrect result | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We have observed in Debian that GHC can produce a erratically behaving version of ghc-pkg which causes issues when piping it's output to another program. Example: {{{ make_setup_recipe Running ghc --make Setup.hs -o debian/hlibrary.setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking debian/hlibrary.setup ... . /usr/share/haskell-devscripts/Dh_Haskell.sh && \ configure_recipe Running debian/hlibrary.setup configure --ghc -v2 --package- db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell- packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option =-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/base-prelude-/ --datasubdir=base-prelude --htmldir=/usr/share/doc/libghc-base-prelude- doc/html/ --enable-library-profiling Configuring base-prelude-1.2.1... Warning: cannot determine version of /usr/bin/ghc-pkg : "" hlibrary.setup: The program 'ghc-pkg' is required but the version of /usr/bin/ghc-pkg could not be determined. }}} (Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-base- prelude&arch=m68k&ver=1.2.1-1&stamp=1530588494&raw=0) Examining the behavior of the affected ghc-pkg binary on m68k shows what's going on: {{{ root@pacman:~# uname -a Linux pacman 4.16.0-2-m68k #1 Debian 4.16.16-1 (2018-06-19) m68k GNU/Linux root@pacman:~# ghc-pkg --version GHC package manager version 8.2.2 root@pacman:~# ghc-pkg --version | cat root@pacman:~# }}} Comparing that to an x86_64 machine shows that piping to cat should actually output something: {{{ glaubitz@epyc:~$ uname -a Linux epyc 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 GNU/Linux glaubitz@epyc:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.2 glaubitz@epyc:~$ ghc --version | cat The Glorious Glasgow Haskell Compilation System, version 8.2.2 glaubitz@epyc:~$ }}} Further investigation shows that the problem is partially resolved when building GHC with reduced optimization: {{{ echo "SRC_HC_OPTS += -O0 -H64m" >> mk/build.mk echo "GhcStage1HcOpts = -O" >> mk/build.mk echo "GhcStage2HcOpts = -O0" >> mk/build.mk echo "GhcLibHcOpts = -O" >> mk/build.mk }}} The above issue goes away, but ghc-pkg itself still shows some strange behavior: {{{ make_setup_recipe Running ghc --make Setup.hs -o debian/hlibrary.setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking debian/hlibrary.setup ... . /usr/share/haskell-devscripts/Dh_Haskell.sh && \ configure_recipe Running debian/hlibrary.setup configure --ghc -v2 --package- db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell- packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option =-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/microlens- ghc-0.4.8.0/ --datasubdir=microlens-ghc --htmldir=/usr/share/doc/libghc- microlens-ghc-doc/html/ --enable-library-profiling Configuring microlens-ghc-0.4.8.0... hlibrary.setup: ghc-pkg dump failed: dieVerbatim: user error (hlibrary.setup: '/usr/bin/ghc-pkg' exited with an error: ghc-pkg: <stdout>: commitBuffer: invalid argument (invalid character) ) }}} (Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell- microlens-ghc&arch=m68k&ver=0.4.8.0-2&stamp=1529960552&raw=0) To reproduce the issue, GHC can be tested using QEMU which has pretty good support for the m68k target these days. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13194: Concurrent modification of package.cache is not safe
by GHC 19 Jul '18

19 Jul '18

#13194: Concurrent modification of package.cache is not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | 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: -------------------------------------+------------------------------------- There are a couple of different issues here. 1. On Linux, issuing `ghc-pkg register` for multiple packages in parallel might result in lost updates to package database because of how `registerPackage` function works - it reads existing package databases, picks the one to modify, then checks that package info for the package to register is fine and replaces package database with what was read in the beginning + new package info. Therefore, if updates interleave, it might happen that process1 reads the database, then process2 updates it while process1 still has the old version and uses it for its update later, so update made by process2 is lost. 2. On Windows, update to package database might fail - the issue is that GHC attempts to update it using rename trick, which fails whenever any other process has file to be replaced open for reading. Combine that with the fact that GHC reads package database when compiling packages and you get problems in both Stack (https://github.com/commercialhaskell/stack/issues/2617) and Cabal (https://github.com/haskell/cabal/issues/4005) BTW, rename trick (used for atomic database updates) not only doesn't work on Windows, it's also not atomic e.g. on NFS (https://stackoverflow.com/questions/41362016/rename-atomicity-and-nfs) The solution to both problems is to use OS specific features to lock database file (in shared mode when reading and in exclusive mode when writing). This can be done on Windows using LockFileEx. Unfortunately for POSIX things are a bit more complicated. There are two ways to lock a file on Linux: 1. Using fcntl(F_SET_LK) (POSIX API) 2. Using flock (BSD API) However, fcntl locks have a serious limitation: The record locks described above are associated with the process (unlike the open file description locks described below). This has some unfortunate consequences: * If a process closes any file descriptor referring to a file, then all of the process's locks on that file are released, regardless of the file descriptor(s) on which the locks were obtained. This is bad: it means that a process can lose its locks on a file such as /etc/passwd or /etc/mtab when for some reason a library function decides to open, read, and close the same file. * The threads in a process share locks. In other words, a multithreaded program can't use record locking to ensure that threads don't simultaneously access the same region of a file. Whereas flock is not guaranteed to work with NFS, according to https://en.wikipedia.org/wiki/File_locking#Problems: Whether and how flock locks work on network filesystems, such as NFS, is implementation dependent. On BSD systems, flock calls on a file descriptor open to a file on an NFS-mounted partition are successful no-ops. On Linux prior to 2.6.12, flock calls on NFS files would act only locally. Kernel 2.6.12 and above implement flock calls on NFS files using POSIX byte-range locks. These locks will be visible to other NFS clients that implement fcntl-style POSIX locks, but invisible to those that do not.[4] Assuming that the solution would be to go with locking the database, we would need to: 1. In `registerPackage`, lock all read databases in shared mode except for the database that will later be modified, which has to be locked in exclusive mode. The handle also would need to be kept open and passed to `changeDB` later and used for rewriting the database with updated version in `GHC.PackageDb.writePackageDb` instead of `writeFileAtomic` (which is not actually unconditionally atomic, as demonstrated above). 2. `GHC.PackageDb.decodeFromFile` would lock a file in appropriate mode and return the handle to open file if appropriate. 3. Add support for locking a file. This should be fairly easy to do in GHC.IO.Handle.FD by extending function `openFile'` with appropriate parameters and then adding wrapper function `openLockedFile` or something. We can add both blocking and non-blocking locking to make ghc-pkg show information about waiting for locked package database if appropriate. Alternatively we could add a function similar to the following: `hLock :: Handle -> LockMode -> Bool{-block-} -> IO Bool`, but that requires extracting file descriptor from Handle, which as far as I see is problematic. Is going with locking an acceptable solution here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #15313: Framework failures on windows with plugins
by GHC 19 Jul '18

19 Jul '18

#15313: Framework failures on windows with plugins -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- On Windows, when the load is heavy (i.e. when doing a full `sh validate` I get a bunch of framework failures in the `plugins/` testsuite directory {{{ Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2) }}} I sent a full log to Tamar who said: Thanks for the log, that does give a clue. The command fails with {{{ setup.exe: 'C:/code/HEAD/inplace/bin/ghc-pkg.exe' exited with an error: ... rule-defining-plugin-0.1: cannot find any of ["libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.a","libHSrule- defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.p_a","libHSrule-defining- plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.so","libHSrule-defining- plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dylib","HSrule-defining- plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dll"] on library path (use --force to override) make[2]: *** [Makefile:18: package.T10420] Error 1 }}} so it's the `setup install` from https://github.com/ghc/ghc/blob/c2783ccf545faabd21a234a4dfc569cd856082b9/te… /rule-defining-plugin/Makefile failing. Unfortunately, all those tests run with -v0 which is annoying because now the verbosity of the testsuite doesn't control that of these tests. I'm not sure why these commands fail under heavy load though. I'll need to dive into the source of ghc-pkg to figure out what's happening. Notice that all the framework failures are these plugin tests which modify a package database. A wild guess is that `ghc-pkg` tries to take a lock on all package-databases or something when it's mutating one. But I'm not intimately familiar with the package store and this doesn't explain why it doesn't happen on Linux. For now one solution I can propose is to create a ticket to track these and mark these tests as cpu multirace on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15313> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15410: Fix typos in docs
by GHC 18 Jul '18

18 Jul '18

#15410: Fix typos in docs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 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: -------------------------------------+------------------------------------- Fix some typos in documenatation -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15410> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15408: Spellcheck TcUnify file
by GHC 18 Jul '18

18 Jul '18

#15408: Spellcheck TcUnify file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Correct spelling errors -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15408> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15407: Spellcheck TcType file
by GHC 18 Jul '18

18 Jul '18

#15407: Spellcheck TcType file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Minor comment fixes -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15407> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4