March 2014 - ghc-tickets

[GHC] #8859: import conditionalization in System.Posix.Files.Common is wrong
by GHC 21 Jan '16

21 Jan '16

#8859: import conditionalization in System.Posix.Files.Common is wrong ------------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.1-rc2 Keywords: | Operating System: Other Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- `System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid "unused import" compiler warnings: {{{ #if defined(HAVE_STRUCT_STAT_ST_CTIM) || \ defined(HAVE_STRUCT_STAT_ST_MTIM) || \ defined(HAVE_STRUCT_STAT_ST_ATIM) || \ defined(HAVE_STRUCT_STAT_ST_ATIMESPEC) || \ defined(HAVE_STRUCT_STAT_ST_MTIMESPEC) || \ defined(HAVE_STRUCT_STAT_ST_CTIMESPEC) import Data.Int import Data.Ratio #endif }}} but those modules are actually used in functions like {{{ accessTimeHiRes (FileStatus stat) = unsafePerformIO $ withForeignPtr stat $ \stat_ptr -> do sec <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime #ifdef HAVE_STRUCT_STAT_ST_ATIM nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIMESPEC nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIMENSEC nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_ATIME_N nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int) let frac = toInteger nsec % 10^(9::Int) #elif HAVE_STRUCT_STAT_ST_UATIME usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int) let frac = toInteger usec % 10^(6::Int) #else let frac = 0 #endif return $ fromRational $ toRational sec + frac }}} so there should be additional tests for `defined(HAVE_STRUCT_STAT_ST_ATIMENSEC)`, `defined(HAVE_STRUCT_STAT_ST_ATIME_N)`, ... (15 total). Or, maybe there's a better alternative, since this is very long-winded and fragile... This breaks the build on Android, which has `st_atimensec`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8859> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8904: haddock displays GHC.Types.Coercible as a datatype
by GHC 21 Jan '16

21 Jan '16

#8904: haddock displays GHC.Types.Coercible as a datatype ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- ...and not as a class. Appeared after #8894 was fixed. It is correct in Data.Coerce and GHC.Exts, so this is a minor issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX
by GHC 21 Jan '16

21 Jan '16

#8916: "error: thread-local storage not supported for this target" when building cross-compiling GHC on OSX ----------------------------------+---------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Target is `x86_64-pc-linux`. I'm using the toolchain from http://crossgcc .rts-software.org/doku.php, and configured `--with-target=x86_64-pc- linux`. {{{ ===--- building phase 0 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 /Applications/Xcode.app/Contents/Developer/usr/bin/make -r --no-print- directory -f ghc.mk phase=1 phase_1_builds utils/unlit/ghc.mk:18: utils/unlit/dist/build/.depend.c_asm: No such file or directory utils/hp2ps/ghc.mk:24: utils/hp2ps/dist/build/.depend.c_asm: No such file or directory includes/ghc.mk:146: includes/dist-derivedconstants/build/.depend.c_asm: No such file or directory includes/ghc.mk:184: includes/dist-ghcconstants/build/.depend.c_asm: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.haskell: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.c_asm: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.haskell: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist- boot/build/.depend-v.haskell: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.haskell: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist- boot/build/.depend-v.c_asm: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist- boot/build/.depend-v.haskell: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/build/.depend-v.c_asm: No such file or directory compiler/ghc.mk:450: compiler/stage1/build/.depend-v.haskell: No such file or directory HC [stage 0] includes/dist-ghcconstants/build/mkDerivedConstants.o In file included from rts/Capability.h:25, from includes/mkDerivedConstants.c:27:0: rts/Task.h:238:0: error: thread-local storage not supported for this target make[1]: *** [includes/dist-ghcconstants/build/mkDerivedConstants.o] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse..
by GHC 21 Jan '16

21 Jan '16

#8924: Text.ParserCombinators.ReadP needs some kind of "commit" or "cut" to force a single parse.. ------------------------------------+------------------------------------- Reporter: PaulJohnson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- The ReadP monad maintains all possible parses of its input, rather than being left-biased as most parsers are. However this is not always quite the Right Thing. I maintain the Data.Decimal library. The Read instance for Data.Decimal up to 0.3.1 had the following behaviour: reads "34.567e8 foo" :: [(Decimal, String)] = [(34.0,".567e8 foo"),(34.567,"e8 foo"),(3.4567e9," foo")] Clearly only the last parse in the list is the Right Thing, and any parser which returns "34.0" when given "34.567" is doing it wrong. The problem came from the implementation of "optional". In numbers only the integer part is mandatory, with the fractional and exponent parts being optional. So I wrote my parser with the fractional part parsed like this: fractPart <- optional "" $ do _ <- char '.' munch1 isDigit The problem is that "optional" uses the symmetric choice operator (+++). I wrote this to work around the problem: myOpt d p = p <++ return d This uses the left-biased choice, so as soon as the parser sees the "." it commits to the fractional part. However this still isn't the Right Thing. reads "34." :: [(Double, String)] = [(34.0, ".")] but the parser above will fail to read it. Furthermore there are a number of combinators built on "+++" in ReadP, and it seems wrong to have left- biased variants of all of them. So what seems to be needed is some kind of "cut" operator, analogous to the Prolog "!" cut, which says that if you have got this far then you should commit to this parse and forget all the others. But it would have to be delimited because I only want that cut to apply to my Decimal type: if someone calls my Decimal parser then I don't want their parser to commit to an entire parse just because I have. So I think the feature I'm looking for is a delimited back-track akin to "prompt" in delimited continuations. But my monad-fu isn't good enough to design it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8114: GHC panic when building `thyme`
by GHC 16 Jan '16

16 Jan '16

#8114: GHC panic when building `thyme` -----------------------------------+--------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- While attempting to build `thyme` from Hackage with core, stg, and cmm linting and -O2 enabled, GHC crashed with an internal panic. See attached terminal log. {{{ rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which ghc /usr/local/bin/ghc rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which cabal /Users/Alexander/Library/Haskell/bin/cabal }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8613: simplifier ticks exhausted
by GHC 13 Jan '16

13 Jan '16

#8613: simplifier ticks exhausted ----------------------------------+---------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------- (Sent by chrisreade(a)mac.com ) Compiler giving up with simplifier ticks exhausted. Large amount of simplification may be going on to cause this. The problem goes away when using -fsimpl-tick-factor=1000 and the code runs. This is the session output without the flag (asking to have bug reported): chris$ ghc -O2 -rtsopts RedBlackStencilOpt.hs -v Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache Using binary package database: /Users/chris/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache hiding package binary-0.5.1.1 to avoid conflict with later version binary-0.6.4.0 hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-1.18.1.1 wired-in package ghc-prim mapped to ghc- prim-0.3.0.0-d5221a8c8a269b66ab9a07bdc23317dd wired-in package integer-gmp mapped to integer- gmp-0.5.0.0-2f15426f5b53fe4c6490832f9b20d8d7 wired-in package base mapped to base-4.6.0.1-6c351d70a24d3e96f315cba68f3acf57 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.8.0.0-c2c1b21dbbb37ace4b7dc26c966ec664 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *RedBlackStencilOpt.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2013-12-13 13:12:37 UTC ms_mod = main:RedBlackStencilOpt, ms_textual_imps = [import (implicit) Prelude, import Data.Array.Repa.Stencil.Dim2 as A, import Data.Array.Repa.Stencil as A, import Data.Array.Repa as A] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file RedBlackStencilOpt.hs Created temporary directory: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 *** Checking old interface for main:RedBlackStencilOpt: [1 of 1] Compiling RedBlackStencilOpt ( RedBlackStencilOpt.hs, RedBlackStencilOpt.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: '/usr/bin/gcc' '-m64' '-fno-stack-protector' '-m64' '-L/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-4.6.0.1' '--print-file-name' 'libiconv.dylib' Loading package base ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package QuickCheck-2.6 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package primitive-0.5.0.1 ... linking ... done. Loading package vector-0.10.0.1 ... linking ... done. Loading package repa-3.2.3.3 ... linking ... done. *** Simplify: *** CorePrep: *** ByteCodeGen: *** Desugar: Result size of Desugar (after optimization) = {terms: 900, types: 1,810, coercions: 340} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 834, types: 1,757, coercions: 567} Result size of Simplifier iteration=2 = {terms: 830, types: 1,721, coercions: 567} Result size of Simplifier = {terms: 830, types: 1,721, coercions: 567} *** Specialise: Result size of Specialise = {terms: 830, types: 1,721, coercions: 567} *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 993, types: 2,131, coercions: 567} *** Float inwards: Result size of Float inwards = {terms: 993, types: 2,131, coercions: 567} *** Simplifier: *** Deleting temp files: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s Warning: deleting non-existent /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0/ghc93155_0.s *** Deleting temp dirs: Deleting: /var/folders/dz/m1mks1yn1bsft72zgh105sw40000gn/T/ghc93155_0 ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op szipWith 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: 60402 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8736: GHCi doesn't load .dyn_o files appropriately
by GHC 09 Jan '16

09 Jan '16

#8736: GHCi doesn't load .dyn_o files appropriately ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Now that GHCi generally defaults to dynamic linking, it handles dynamic object files. But it doesn't implicitly handle the `-dynamic-too` case appropriately: {{{ $ cat Test.hs main = return () $ ./inplace/bin/ghc-stage2 -dynamic Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./inplace/bin/ghc-stage2 --interactive Test GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main> ^D $ ./inplace/bin/ghc-stage2 -dynamic-too Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./inplace/bin/ghc-stage2 --interactive Test GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Test.hs, interpreted ) Ok, modules loaded: Main. *Main> }}} Also: {{{ $ ./inplace/bin/ghc-stage2 --interactive Test.dyn_o GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Warning: ignoring unrecognised input `Test.dyn_o' Prelude> }}} but it does handle the `.o` case. This should all be fixed and merged to 7.8 since it'll likely be very annoying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8793: Improve GHC.Event.IntTable performance
by GHC 09 Jan '16

09 Jan '16

#8793: Improve GHC.Event.IntTable performance ------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | 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: | ------------------------------------+------------------------------------- The performance of `GHC.Event.IntTable` can be improved. I've managed to get some nice increases across the board. Benchmarking using `criterion` shows: function, % faster than current impl. `insert`: 4% `lookup`: 26% `update`: 11% `delete`: 5% There is one strange thing I noted. In `updateWith`, there is an inner loop that looks like this: {{{ data Bucket a = Empty | Bucket Int a (Bucket a) go _ Empty = (False, Nothing, Empty) go cont (Bucket key val next) | key == k = case f val of Nothing -> (True, Just val, cont next) Just v -> (False, Just val, cont (Bucket key v next)) | otherwise = go (\x -> cont (Bucket key val x)) next }}} which returns a tuple that is immediately consumed like so: {{{ (delete_occurred, old_val, new_bkt) <- go id ... when (isJust old_val) $ do <updateIntTable> when delete_occurred <decIntTableSize> return old_val }}} I expected that inlining the `<updateIntTable>` and `<decIntTableSize>` code blocks directly into `go` would result in better code than creating a tuple and then pattern matching on it afterwards. ie. {{{ go _ Empty = return Nothing go cont (Bucket key val next) | key == k = do case f val of Nothing -> <updateIntTable> (cont next) >> <decIntTableSize> Just v -> <updateIntTable> (cont (Bucket key v next) return (Just val) | otherwise = go (\x -> cont (Bucket key val x)) next }}} which has the exact same semantics. To my suprise, this code is almost 2x slower! The core generated in both cases is exactly what I'd expect; if anything, the second version seems tighter. I'm not sure why the first version is faster, but perhaps the original author, Bryan O'Sullivan, can shed some light as he used the tupled method in the first version. I'll attach my patch, `criterion`'s html output for the benchmarks as well as the benchmarking code, and the core for the oddity I discussed above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules
by GHC 08 Jan '16

08 Jan '16

#8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules -----------------------------------+--------------------------------------- Reporter: tvynr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I have constructed two Cabal projects named "first" and "second". The "first" project defines three files: Logging.hs (which provides some basic logging functionality) and FirstExample.hs and FirstDependent.hs (the latter of which imports the former). In the cabal file, only Logging and FirstDependent are exposed modules. FirstDependent uses a Template Haskell function "loggingFunctions" which defines logging functions for that module. Using cabal or cabal-dev to build this package works quite nicely. The second project depends on the first project and contains a single file, Second.hs. This file imports Logging but neither of the other two files. It also uses the loggingFunctions routine to generate local logging functions. The presence of the "$(loggingFunctions)" splice in Second.hs makes the problem visible, but the real problem is in the first project. Upon compilation of the "second" project with cabal or cabal- dev, the following error is generated: {{{ cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal configure Resolving dependencies... Configuring second-0.1... cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal build Building second-0.1... Preprocessing library second-0.1... [1 of 1] Compiling Second ( lib-src/Second.hs, dist/build/Second.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package unix-2.6.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package network-2.4.1.2 ... linking ... done. Loading package process-1.1.0.2 ... linking ... done. Loading package hslogger-1.2.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package first-0.2 ... linking ... ghc: /home/some- directories/example/first/../cabal-dev- sandbox//lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o: unknown symbol `firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure' ghc: unable to load package `first-0.2' make[1]: *** [build] Error 1 }}} Upon further investigation, it would seem that the .o file constructed to represent the "first" project has not been completely constructed: {{{ $ objdump -t cabal-dev- sandbox/lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o | grep '\*UND\*' | grep first 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczg_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczl_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfEqErrorSpeczuzdczeze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczlze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdccompare_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczgze_info }}} (While the above dump is for ghc 7.6.1, this has also been tested on ghc 7.6.3 as well as on both i386- and amd64-based OS installs.) If the "$(loggingFunctions)" splice is removed from Second.hs, then the project builds (presumably because the logic used by non-Template Haskell projects for linking differs from that of Template Haskell projects). Fortunately, it seems that exposing every module of the "first" project resolves this issue. But please note that the FirstExample.hs and FirstDependent.hs files are completely unrelated to the Second.hs file; the latter does not depend on the former in any way. It seems strange that I can't use Template Haskell across projects without exposing all of my project modules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults
by GHC 07 Jan '16

07 Jan '16

#8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------+------------------------------------- I built ghc-7.8.1 RC2 on ppc Fedora 21 Development with ghc-7.6.3. When I try to run dynamically linked "helloworld", it segfaults. I don't have direct access yet to a ppc box to investigate further. I guess something about the use of shared libraries on ppc is not working properly. {{{ $ cat > hello.hs main = putStrLn "hi" $ ghc -dynamic hello.hs $ ./hello Segmentation fault (core dumped) ./hello }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6