August 2017 - ghc-tickets

[GHC] #13243: make test in non-validate configuration fails with a variety of ghci errors
by GHC 04 Sep '18

04 Sep '18

#13243: make test in non-validate configuration fails with a variety of ghci errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Starting with a fresh checkout of `ghc`, testing in a non-validate configuration fails in a rather peculiar way. e.g., {{{ $ ./boot $ ./configure $ make $ make test }}} Results in a number of test failures of the `ghci` way which suggest that GHCi is having trouble identifying types. e.g., {{{ =====> break026(ghci) 50 of 101 [0, 46, 0] cd "./ghci.debugger/scripts/break026.run" && HC="/mnt/work/ghc/ghc- testing/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output " "/mnt/work/ghc/ghc-testing/inplace/test spaces/ghc- stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -ignore-dot-ghci< break026.script Actual stderr output differs from expected: diff -uw "/dev/null" "./ghci.debugger/scripts/break026.run/break026.run.stderr.normalised" --- /dev/null 2017-01-24 15:20:36.872346204 -0500 +++ ./ghci.debugger/scripts/break026.run/break026.run.stderr.normalised 2017-02-08 15:52:09.290099692 -0500 @@ -0,0 +1,14 @@ + +<interactive>:16:1: + No instance for (Show t1) arising from a use of ‘print’ + Cannot resolve unknown runtime type ‘t1’ + Use :print or :force to determine these types + Relevant bindings include it :: t1 (bound at <interactive>:16:1) + These potential instances exist: + instance Show Ordering -- Defined in ‘GHC.Show’ + instance Show Integer -- Defined in ‘GHC.Show’ + instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’ + ...plus 22 others + ...plus 11 instances involving out-of-scope types + (use -fprint-potential-instances to see them all) + In a stmt of an interactive GHCi command: print it *** unexpected failure for break026(ghci) =====> break027(ghci) 51 of 101 [0, 47, 0] cd "./ghci.debugger/scripts/break027.run" && HC="/mnt/work/ghc/ghc- testing/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output " "/mnt/work/ghc/ghc-testing/inplace/test spaces/ghc- stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -ignore-dot-ghci< break027.script Actual stdout output differs from expected: diff -uw "./ghci.debugger/scripts/break027.run/break027.stdout.normalised" "./ghci.debugger/scripts/break027.run/break027.run.stdout.normalised" --- ./ghci.debugger/scripts/break027.run/break027.stdout.normalised 2017-02-08 15:52:10.750125249 -0500 +++ ./ghci.debugger/scripts/break027.run/break027.run.stdout.normalised 2017-02-08 15:52:10.750125249 -0500 @@ -1,8 +1,8 @@ Breakpoint 0 activated at QSort.hs:4:12-13 Breakpoint 1 activated at QSort.hs:5:16-51 Stopped in QSort.qsort, QSort.hs:5:16-51 -_result :: [Integer] = _ -a :: Integer = 3 -left :: [Integer] = _ -right :: [Integer] = _ -a :: Integer -- Defined in ‘interactive:Ghci1’ +_result :: [a] = _ +a :: a = _ +left :: [a] = _ +right :: [a] = _ +a :: a -- Defined in ‘interactive:Ghci1’ *** unexpected failure for break027(ghci) =====> print001(ghci) 11 of 101 [0, 7, 0] cd "./ghci.debugger/scripts/print001.run" && HC="/mnt/work/ghc/ghc- testing/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output " "/mnt/work/ghc/ghc-testing/inplace/test spaces/ghc- stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -ignore-dot-ghci< print001.script Actual stdout output differs from expected: diff -uw "./ghci.debugger/scripts/print001.run/print001.stdout.normalised" "./ghci.debugger/scripts/print001.run/print001.run.stdout.normalised" --- ./ghci.debugger/scripts/print001.run/print001.stdout.normalised 2017-02-08 15:51:08.413033889 -0500 +++ ./ghci.debugger/scripts/print001.run/print001.run.stdout.normalised 2017-02-08 15:51:08.413033889 -0500 @@ -1,10 +1,9 @@ li = (_t1::[Maybe Integer]) Just 0 -li = Just 0 : (_t2::[Maybe Integer]) +li = (_t2::[Maybe Integer]) 6 -li = [Just 0,(_t3::Maybe Integer),(_t4::Maybe Integer), - (_t5::Maybe Integer),(_t6::Maybe Integer),(_t7::Maybe Integer)] -li = [Just 0,_,_,_,_,_] +li = (_t3::[Maybe Integer]) +li = _ [Just 0,Just 1,Just 2,Just 3,Just 4,Just 5] -li = [Just 0,Just 1,Just 2,Just 3,Just 4,Just 5] -li = [Just 0,Just 1,Just 2,Just 3,Just 4,Just 5] +li = (_t4::[Maybe Integer]) +li = _ *** unexpected failure for print001(ghci) }}} It would be nice to know what is going on here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8414: ghc-pkg prevents dynamic library only packages
by GHC 04 Sep '18

04 Sep '18

#8414: ghc-pkg prevents dynamic library only packages ------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC supports compiling Haskell libraries as dynamic libraries and building executables against dynamic libraries. GHCi seems to support loading modules from dynamic libraries, too. So it would seem that it should be possible to have packages that only include dynamic libraries, omitting the .a and .o files typically generated. cabal-install allows building dynamic libraries only, for example with the command "cabal install --disable-library-vanilla --enable-shared --disable-library-profiling". However, ghc-pkg register refuses to install the package without the .a files present. This seems to be a bug with ghc-pkg. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10374: Can't build GHC with a dynamic only GHC installation
by GHC 04 Sep '18

04 Sep '18

#10374: Can't build GHC with a dynamic only GHC installation -------------------------------------+------------------------------------- Reporter: jessicah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When an installation of GHC doesn't include the vanilla "way", GHC cannot be built from this existing installation of GHC. E.g. using the following mk/build.mk: {{{ V = 0 GhcLibWays = dyn SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 DYNAMIC_BY_DEFAULT = YES NoFibWays = STRIP_CMD = : }}} Steps to reproduce: 1. build & install GHC using above configuration 2. rebuild GHC using above configuration, --with-ghc pointing to the installation created in step 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8441: Allow family instances in an hs-boot file
by GHC 02 Sep '18

02 Sep '18

#8441: Allow family instances in an hs-boot file ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compiling an .hs-boot file with a data instance leads to this error: {{{ Illegal family instance in hs-boot file }}} Yet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor declared in the instance. Furthermore, it may sometimes be desirable to allow type family instances in a hs-boot file, as well, in case some including modules need the instance for type simplification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13930: Cabal configure
by GHC 02 Sep '18

02 Sep '18

#13930: Cabal configure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- `cabal configure` apparently has a space leak when compiled with GHC HEAD but not 8.0. It's not clear whether this is really a GHC regression yet, but here it is certainly GHC version-specific. See https://github.com/haskell/cabal/issues/4589 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #8279: bad alignment in code gen yields substantial perf issue
by GHC 29 Aug '18

29 Aug '18

#8279: bad alignment in code gen yields substantial perf issue ------------------------------+-------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- independently, a number of folks have noticed that in various ways, GHC currently has quite a few different memory alignment related performance problems that can have >= 10% perf impact! Nicolas Frisby notes {{{ On my laptop, a program showed a consistent slowdown with -fdicts-strict I didn't find any obvious causes in the Core differences, so I turned to Intel's Performance Counter Monitor for measurements. After trying a few counters, I eventuall saw that there are about an order of magnitude more misaligned memory loads with -fdicts-strict than without, so I think that may be a significant part of the slowdown. I'm not sure if these are code or data reads. Can anyone suggest how to validate this hypothesis about misaligned reads? A subsequent commit has changed the behavior I was seeing, so I'm not interested in alternatives means to determine if -fdicts-strict is somehow at fault — I'm just asking specifically about data/code memory alignment in GHC and how to diagnose/experiment with it. }}} Reid Barton has independently noted {{{ so I did a nofib run with llvm libraries, ghc quickbuild so there's this really simple benchmark tak, https://github.com/ghc/nofib/blob/master/imaginary/tak/Main.hs it doesn't use any libraries at all in the main loop because the Ints all get unboxed but it's still 8% slower with quick-llvm (vs -fasm) weird right? [14:36:30] <carter> could you post the asm it generates for that function? [14:36:49] <rwbarton> well it's identical between the two versions <rwbarton> but they get linked at different offsets because some llvm sections are different sizes <rwbarton> if I add a 128-byte symbol to the .text section to move it to the same address... then the llvm libs version is just as fast <rwbarton> well, apparently 404000 is good and 403f70 is bad <rwbarton> I guess I can test other alignments easily enough <rwbarton> I imagine it wants to start on a cache line <rwbarton> but I don't know if it's just a coincidence that it worked with the ncg libraries <rwbarton> that it got a good location <rwbarton> for this program every 32-byte aligned address is 10+% faster than any merely 16-byte aligned address <rwbarton> and by alignment I mean alignment of the start of the Haskell code section <carter> haswell, sandybridge, ivy bridge, other? <rwbarton> dunno <rwbarton> I have similar results on Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz <rwbarton> and on Quad-Core AMD Opteron(tm) Processor 2374 HE <carter> ok <rwbarton> trying a patch now that aligns all *_entry symbols to 32 bytes }}} the key point in there is that on the tak benchmark, better alignment for the code made a 10% perf differnce on TAk on Core2 and opteron cpus! benjamin scarlet and Luite are speculating that this may be further induced by Tables next to code (TNC) accidentally creating bad alignment so theres cache line pollution / conflicts between the L1 Instruction- cache and data-caches. So one experiment would be to have the TNC transform pad after the table so the function entry point starts on the next cacheline? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #11350: Allow visible type application in patterns
by GHC 28 Aug '18

28 Aug '18

#11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Constructors (and pattern synonyms) when treated as expressions may be applied to types: {{{#!hs {-# LANGUAGE TypeApplications #-} Nothing :: Maybe a Nothing @() :: Maybe () pattern Pair :: a -> a -> (a, a) pattern Pair x y = (x, y) Pair :: a -> a -> (a, a) Pair @Int :: Int -> Int -> (Int, Int) }}} But using them in patterns won't parse: {{{#!hs -- parse error in pattern: @Int maybeToList :: Maybe Int -> [Int] maybeToList (Nothing @Int) = [] maybeToList (Just @Int x) = [x] -- parse error in pattern: @Int add :: (Int, Int) -> Int add (Pair @Int x y) = x + y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL
by GHC 26 Aug '18

26 Aug '18

#14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Build System | 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: -------------------------------------+------------------------------------- In principle the GHC 8.2.1 bindist for Debian 8 should work fine on WSL. However, in practice it fails during `make install` with this error, {{{ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops
by GHC 26 Aug '18

26 Aug '18

#8733: I/O manager causes unnecessary syscalls in send/recv loops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Network applications often call send followed by recv, to send a message and then read an answer. This causes syscall traces like this one: {{{ recvfrom(13, ) -- Haskell thread A sendto(13, ) -- Haskell thread A recvfrom(13, ) = -1 EAGAIN -- Haskell thread A epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager) recvfrom(14, ) -- Haskell thread B sendto(14, ) -- Haskell thread B recvfrom(14, ) = -1 EAGAIN -- Haskell thread B epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager) }}} The recvfrom call always fails, as the response from the partner we're communicating with won't be available right after we send the request. We ought to consider descheduling the thread as soon as sending is "done". The hard part is to figure out when that is. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase")
by GHC 25 Aug '18

25 Aug '18

#14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The scenario showed as below: {{{ # This is a FreeBSD Jail for testing $ freebsd-version 11.1-RELEASE $ pkg info # (related packages only) binutils-2.28,1 GNU binary tools gcc-ecj-4.5 Eclipse Java Compiler used to build GCC Java gcc5-5.4.0_2 GNU Compiler Collection 5 gmake-4.2.1_1 GNU version of 'make' utility gmp-6.1.2 Free library for arbitrary precision arithmetic libiconv-1.14_10 Character set conversion library libunistring-0.9.7 Unicode string library mpc-1.0.3 Library of complex numbers with arbitrarily high precision mpfr-3.1.5_1 Library for multiple-precision floating- point computations perl5-5.24.1_1 Practical Extraction and Report Language $ ls -l /usr/local/lib/lib{iconv,charset,gmp}.* -rw-r--r-- 1 root wheel 6864 Jul 13 09:10 /usr/local/lib/libcharset.a lrwxr-xr-x 1 root wheel 19 Jul 13 09:10 /usr/local/lib/libcharset.so -> libcharset.so.1.0.0 lrwxr-xr-x 1 root wheel 19 Jul 13 09:10 /usr/local/lib/libcharset.so.1 -> libcharset.so.1.0.0 -rw-r--r-- 1 root wheel 10733 Jul 13 09:10 /usr/local/lib/libcharset.so.1.0.0 -rw-r--r-- 1 root wheel 1252196 Jul 13 09:23 /usr/local/lib/libgmp.a lrwxr-xr-x 1 root wheel 16 Jul 13 09:23 /usr/local/lib/libgmp.so -> libgmp.so.10.3.2 lrwxr-xr-x 1 root wheel 16 Jul 13 09:23 /usr/local/lib/libgmp.so.10 -> libgmp.so.10.3.2 -rwxr-xr-x 1 root wheel 531728 Jul 13 09:23 /usr/local/lib/libgmp.so.10.3.2 -rw-r--r-- 1 root wheel 1110392 Jul 13 09:10 /usr/local/lib/libiconv.a lrwxr-xr-x 1 root wheel 17 Jul 13 09:10 /usr/local/lib/libiconv.so -> libiconv.so.2.5.1 lrwxr-xr-x 1 root wheel 17 Jul 13 09:10 /usr/local/lib/libiconv.so.2 -> libiconv.so.2.5.1 -rw-r--r-- 1 root wheel 1076449 Jul 13 09:10 /usr/local/lib/libiconv.so.2.5.1 # installed using # env CC=/usr/local/bin/gcc5 LDFLAGS='-Wl,-rpath=/usr/local/lib/gcc5' ./configure --prefix=/home/ghc $ /home/ghc/bin/ghc --numeric-version 8.2.1 $ cat /home/ghc/lib/ghc-8.2.1/settings [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "/usr/local/bin/gcc5"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", " -fuse-ld=gold"), ("C compiler supports -no-pie", "NO"), ("Haskell CPP command","/usr/local/bin/gcc5"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "ld.gold"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/local/bin/ar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/local/bin/perl"), ("cross compiling", "NO"), ("target os", "OSFreeBSD"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("target has RTS linker", "@HaskellHaveRTSLinker@"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] $ /home/ghc/bin/ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> (!!6) $ scanl (*) 1 [1..] 720 $ cat Main.hs module Main (main) where main :: IO () main = putStrLn "hello world" $ /home/ghc/bin/ghc -O0 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... In file included from /home/ghc/lib/ghc-8.2.1/include/rts/Threads.h:19:0: error: 0, from /home/ghc/lib/ghc-8.2.1/include/Rts.h:173, from /tmp/ghc28144_0/ghc_4.c:1: /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include- fixed/sys/types.h:266:9: error: error: unknown type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^ | 266 | typedef __vm_ooffset_t vm_ooffset_t; | ^ /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include- fixed/sys/types.h:268:9: error: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^ | 268 | typedef __vm_pindex_t vm_pindex_t; | ^ `gcc5' failed in phase `C Compiler'. (Exit code: 1) }}} On my FreeBSD 10.3 box: {{{ $ freebsd-version 10.3-STABLE $ pkg info binutils-2.28,1 GNU binary tools gcc-5.4.0_2 Meta-port for the default version of the GNU Compiler Collection gcc-ecj-4.5 Eclipse Java Compiler used to build GCC Java gcc5-5.4.0_3 GNU Compiler Collection 5 gmake-4.2.1_1 GNU version of 'make' utility gmp-6.1.2 Free library for arbitrary precision arithmetic libffi-3.2.1 Foreign Function Interface libiconv-1.14_10 Character set conversion library perl5-5.24.1_1 Practical Extraction and Report Language $ cat ./ghc-8.2.1-bin/lib/ghc-8.2.1/settings [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", " -fuse-ld=gold"), ("C compiler supports -no-pie", "NO"), ("Haskell CPP command","gcc"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "ld.gold"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/bin/ar"), ("ar flags", "clqs"), ("ar supports at file", "NO"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/local/bin/perl"), ("cross compiling", "NO"), ("target os", "OSFreeBSD"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("target has RTS linker", "@HaskellHaveRTSLinker@"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] $ ./ghc-8.2.1-bin/bin/ghc -O0 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main hello, world! }}} I also noticed that using FreeBSD's strip (from elftoolchain), the {{{ Installing library in /home/ghc/lib/ghc-8.2.1/ghc-prim-0.5.1.0 "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /integer-gmp dist-install "strip" '' '/home/ghc' '/home/ghc/lib/ghc-8.2.1' '/home/ghc/share/doc/ghc- 8.2.1/html/libraries' 'v p dyn' }}} phase will be a bit longer than GNU's strip. (Tested by put my $LOCALBASE/bin ahead in $PATH). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14