December 2018 - ghc-tickets

[GHC] #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux
by GHC 11 Dec '18

11 Dec '18

#15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux ----------------------------------------+--------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.7 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #15847 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- ghc assumes that on linux, C compiler (e.g. gcc) will build non-PIC object code when no `-fPIC` is passed. But this is no longer true for recent gcc version on some distributions. e.g. {{{ $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ gcc --version gcc (GCC) 7.3.1 20180312 $ touch dummy.c $ gcc -Q -v dummy.c 2>&1 | grep PIC options enabled: -fPIC -fPIE -faggressive-loop-optimizations }}} We need pass `-fno-PIC` explicitly just like `-no-pie`. In particular, this results in 300+ ext-interp related tests to fail on i386 when built with a gcc that has `-fPIC` on by default, as we don't support loading non-PIC .o built from .c on i386. (See #15847, fix this bug will mitigate #15847) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15826: Allow using (Source)Plugins through the GHC API
by GHC 11 Dec '18

11 Dec '18

#15826: Allow using (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- One might expect to be able to load plugins through the GHC API by doing something like: {{{ runGHC $ do dflags <- getSessionDynFlags setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] } }}} but this doesn't actually work because the `plugins` field in `DynFlags` is used as a cache and overwritten by `initializePlugins` whenever plugins loaded through the command-line need reloading. Not to mention that there isn't a meaningful way to fill the `_conjure_up_modiface` hole AFAIK. While in principle it might be possible to use source plugins via the API right now by messing with the exposed cmdline flags the right way it feels much cleaner to just have a new type of plugin that can be added to GHC right through the API. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15854: PPC: Panic in native code generator
by GHC 11 Dec '18

11 Dec '18

#15854: PPC: Panic in native code generator ---------------------------------+---------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- Head fails on powerpc64le: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181103 for powerpc64le-unknown-linux): PPC.CodeGen.getRegister: no match Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.o' failed }}} I think I know what is going on and will work on a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14225: "No module named ... is imported" message is a bit misleading with qualified imports
by GHC 11 Dec '18

11 Dec '18

#14225: "No module named ... is imported" message is a bit misleading with qualified imports -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.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 seems that the `No module named ... is imported` message produced in response to out-of-scope identifiers doesn't account for qualified imports. For instance, {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import qualified Data.Maybe as M λ> M.fromJusr <interactive>:2:1: error: Not in scope: ‘M.fromJusr’ Perhaps you meant ‘M.fromJust’ (imported from Data.Maybe) No module named ‘M’ is imported. λ> }}} I suppose there is the question of whether we consider `M` to be a "module" here; I would argue that I imported it and therefore the message is at very least a bit misleading. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15924: Do not save performance test results if work tree is dirty
by GHC 11 Dec '18

11 Dec '18

#15924: Do not save performance test results if work tree is dirty -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Keywords: performance | Operating System: Unknown/Multiple tests git notes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12758 Differential Rev(s): | Wiki Page: | Performance/Tests -------------------------------------+------------------------------------- The test driver will automatically save performance results to git notes. Notes are attached to commits, but if the working tree is dirty, performance characteristics my be affected and the saved results will not be valid. * Only save performance test results if work tree is dirty. * Bonus: don't save to a git note if we have 0 results. * Update wiki page. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16026: No way to run a subset of the testsuite
by GHC 11 Dec '18

11 Dec '18

#16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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: -------------------------------------+------------------------------------- Currently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16026> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15949: Hadrian needs more convenient build target names
by GHC 11 Dec '18

11 Dec '18

#15949: Hadrian needs more convenient build target names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- With the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to know the name of the final target which the build will produce which may contain version numbers, platform triples, and all sorts of other ugliness. I suggest we introduce a set of convenience targets to make this easier. For instance one could run: {{{ $ hadrian stage1:lib:ghc }}} to build the stage1 `ghc` library or {{{ $ hadrian stage2:exe:hp2ps }}} to build `hp2ps`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15946: configure script makes use of argument flag that is not supported in OpenBSD
by GHC 11 Dec '18

11 Dec '18

#15946: configure script makes use of argument flag that is not supported in OpenBSD -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: configure | Operating System: OpenBSD Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After some head-scratching, I found that the configure script makes use of the **-v** verbose flag. This flag does not exist in OpenBSD. It was causing the build process to fail due to some files not existing during the compilation process. I'm getting around this by removing all **-v** occurrences as a pre- compilation step: {{{ find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' }}} To make the process a little smoother for other folks, perhaps creating an alias that is conditional based OS type at the header of the script along the lines of would be best: {{{ case "$build_os" in openbsd*) alias mksymlnk="ln -f" ;; *) alias mksymlnk="ln -f -v" ;; esac ... mksymlnk utils/fs/fs.* utils/lndir/ ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1: Implicit parameters cause strange behavi
by GHC 11 Dec '18

11 Dec '18

#1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"c98e25a4de88f12c6ded0a97fcf3ed8f4996b9ea/ghc" c98e25a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c98e25a4de88f12c6ded0a97fcf3ed8f4996b9ea" Explicitly pass -fno-PIC to C compiler on linux Recent gcc on some linux ditributions may have -fPIC on by default ``` $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ gcc --version gcc (GCC) 7.3.1 20180312 $ touch dummy.c $ gcc -Q -v dummy.c 2>&1 | grep PIC options enabled: -fPIC -fPIE -faggressive-loop-optimizations ``` This results in following error for i686: ``` $ TEST=T13366 make test ... c-iserv.bin: /home/watashi/github/ghc/libraries/ghc-prim/dist-install/build/HSghc-pri m-0.5.3.o: unknown symbol `_GLOBAL_OFFSET_TABLE_' ghc-stage2: unable to load package `ghc-prim-0.5.3' ... ``` As our runtime linker doesn't support R_386_GOTPC relocations at all (#15847). Also while we don't have such problem on x86_64, it's not desired to build PIC objects either. Test Plan: `TEST=T13366 make test` passed on {rGHC82a716431cc680392e332bc2b1a1fd0d7faa4cd8} Reviewers: simonmar, bgamari, austin Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15848 Differential Revision: https://phabricator.haskell.org/D5288 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16035: keep-cafs fails on FreeBSD 11
by GHC 11 Dec '18

11 Dec '18

#16035: keep-cafs fails on FreeBSD 11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.7 System (Linker) | Keywords: | Operating System: FreeBSD Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's a bit unclear why: {{{#!patch =====> keep-cafs(normal) 9 of 10 [0, 4, 2] cd "rts/keep-cafs.run" && $MAKE -s --no-print-directory KeepCafs Actual stdout output differs from expected: diff -uw "rts/keep-cafs.run/keep-cafs.stdout.normalised" "rts/keep- cafs.run/keep-cafs.run.stdout.normalised" --- rts/keep-cafs.run/keep-cafs.stdout.normalised 2018-12-11 22:41:53.650952000 +0000 +++ rts/keep-cafs.run/keep-cafs.run.stdout.normalised 2018-12-11 22:41:53.651227000 +0000 @@ -1,2 +1,4 @@ -1000 -1001 +KeepCafsMain: KeepCafs1.o: unknown symbol `base_GHCziBase_zdfMonadIO_closure' +KeepCafsMain: KeepCafs2.o: unknown symbol `base_GHCziNum_zdfNumInt_closure' +34410180672 +34410180672 }}} Perhaps a GHCi linker issue? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4