July 2014 - ghc-tickets

[GHC] #9013: addWord2# is buggy
by GHC 11 Aug '14

11 Aug '14

#9013: addWord2# is buggy ------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Looks like its behavior differs between optimization levels: {{{#!haskell {-# LANGUAGE MagicHash, UnboxedTuples #-} import GHC.Prim import GHC.Word big :: Word big = maxBound good = let x = case big of W# w -> w in case plusWord2# x x of (# a, b #) -> (W# a, W# b) main = do putStrLn $ case good of (0, z) -> "Such optimal, much sad" (1, z) -> "No optimization here" }}} I thought I was going crazy! Try the above code with and without -O2 and you'll get different output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9013> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9189: Linking fails on OSX when -staticlib and -threaded are enabled
by GHC 10 Aug '14

10 Aug '14

#9189: Linking fails on OSX when -staticlib and -threaded are enabled -------------------------------------+------------------------------------- Reporter: frode | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: pthread staticlib | Operating System: MacOS X threaded | Type of failure: Compile-time Architecture: x86 | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I'm trying to build a library with ffi exported functions to be called from ObjectiveC in an Xcode project on OSX. With just -staticlib it works, but when I add -threaded as well I get a linker error saying that it cannot find pthread. This happens even with a trivial program: {{{ Test.hs: module Test where main :: IO () main = putStrLn "Hello" }}} {{{ $ ghc Test.hs -staticlib -threaded [1 of 1] Compiling Test ( Test.hs, Test.o ) Linking liba.a ... error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library) }}} The linker command that fails: {{{ *** Linker: libtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2 /ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread }}} If I make a script that removes the -lpthread argument, it links ok and the project works with multiple threads calling my ffi-functions simultaneously. It was suggested by Bob on Haskell Cafe that it should not link against libpthread on OSX since it is included in libSystem (like IOS): https://groups.google.com/d/msg/haskell-cafe/GGEkifs_-uY/uzHeV-Z2E2YJ https://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs#L186… OSX version 10.9.3 Verbose output: {{{ $ ghc Test.hs -staticlib -threaded -v Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3 Using binary package database: /usr/local/lib/ghc-7.8.2/package.conf.d/package.cache Using binary package database: /Users/frode/.ghc/x86_64-darwin-7.8.2/package.conf.d/package.cache hiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0 hiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7 hiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7 wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: hiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0 hiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7 hiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7 wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Test.hs Stable obj: [Test] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2014-06-10 10:02:41 UTC ms_mod = main:Test, ms_textual_imps = [import (implicit) Prelude] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Test.hs Created temporary directory: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0 *** Checking old interface for main:Test: [1 of 1] Skipping Test ( Test.hs, Test.o ) Upsweep completely successful. *** Deleting temp files: Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s Warning: deleting non-existent /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s link: linkables are ... LinkableM (2014-06-10 10:02:55 UTC) main:Test [DotO Test.o] Linking liba.a ... *** C Compiler: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c -o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -I/usr/local/lib/ghc-7.8.2/include *** Linker: libtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2 /ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library) *** Deleting temp files: Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c *** Deleting temp dirs: Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8569: ASSERT in testcase type-rep, only in some ways:
by GHC 06 Aug '14

06 Aug '14

#8569: ASSERT in testcase type-rep, only in some ways: ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: | ------------------------------------+------------------------------------- On HEAD, I currently (d55cc30658ae7c5afc0d62f3bd118fb2a5fcee40) get {{{ =====> type-rep(normal) 2696 of 3834 [0, 0, 0] =====> type-rep(hpc) 2696 of 3834 [0, 0, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(hpc) =====> type-rep(optasm) 2696 of 3834 [0, 1, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(optasm) =====> type-rep(ghci) 2696 of 3834 [0, 2, 0] =====> type-rep(threaded1) 2696 of 3834 [0, 2, 0] =====> type-rep(threaded2) 2696 of 3834 [0, 2, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(threaded2) =====> type-rep(dyn) 2696 of 3834 [0, 3, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(dyn) =====> type-rep(optllvm) 2696 of 3834 [0, 4, 0] Compile failed (status 256) errors were: [1 of 1] Compiling Main ( type-rep.hs, type-rep.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131124 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Demand.lhs, line 439 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for type-rep(optllvm) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9265: Extend PackageId to include version dependency information
by GHC 05 Aug '14

05 Aug '14

#9265: Extend PackageId to include version dependency information ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.9 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- [MultiInstances Multiple installed instances of a package] has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoCMultipleInstances GSoC project] that ultimately never got merged into HEAD. This ticket is our latest attack on the problem, summarized as: add a version dependency hash to the `PackageId` (NOT the `InstalledPackageId`) associated with packages in the database. This approach is distinguished from the prior attempts as follows: - We make no attempt to support multiple installations of different ways or ABI-compatible versions of a library (e.g. with/without optimizations.) This corresponds to supporting multiple InstalledPackageIds in a database; in our case, we're supporting multiple `PackageId`. - We do not have to deal with conflicting "instances" in GHC's package resolver: multiple instances can be simultaneously loaded and used in a single compiled program. This is because PackageIds are baked into the exported linker symbols, so different versions will have different names and can peacefully coexist. - We do not have to deal with the delicate ordering problem of calculating an ABI hash when configuring a package, which is prior to when we actually know it (ABI hash is only known after compilation), because our hash is based ONLY on dependency resolution choice. - In absence of preference for previously installed packages, our Cabal dependency resolution stays exactly the same: Cabal picks versions, and from these choices we calculate the dependency hashes. With preference, we will have to do a little more work. - We do not attempt to garbage collect old packages. Because we are not dependent on ABI, there is not an explosion of installed pacakges from package development; new installed packages only occur when version numbers are bumped up, or packages are installed in a combinatorially different fashion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9375: Support for module thinning/renaming on command line
by GHC 05 Aug '14

05 Aug '14

#9375: Support for module thinning/renaming on command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In #8407, we added the capability for packages to reexport modules from other packages. This ticket is for the dual operation: during the compilation of a module, rather than being forced dump all of the exposed modules of package foo when I say `-package foo`, I should be able to selectively pick which modules I make visible (thinning) and rename them, if I like. For now, the proposed syntax is for all package flags, I can now write `-package "foo (A as B, C)"`. This feature has special implications for how the package database hiding/showing works. Currently, if I write `-package foo-0.1`, this will automatically go ahead and un-expose any other packages named `foo` that I may have loaded. But if I write `-package foo-0.1 (Foo as Foo1) -package foo-0.2 (Foo as Foo2)`, I probably didn't actually want to hide the old instance of `foo-0.1` when I exposed `foo-0.2`. More generally, rather than thinking of package configuration as flipping exposed/not-exposed bits on and off of an in-memory package database, we would rather think of it as setting up a mapping of module names to their implementations, and only reporting a conflict when there is an inconsistent module mapping. Since this is a change of behavior, I propose two sets of semantics, controlled by a flag `-backpack` (but really, I mostly care about the second set). Flag naming can be negotiated. In the **absence** of `-backpack`, thinning/renaming works by modifying the exposed/reexported module fields of the matched packages in the database. However, the old hiding behavior still applies, so this functionality would primarily be useful if two separate packages exported a module with the same name, and you still wanted to use both of them. So, the original example would not do what you want, but `-package mtl (Control.Monad.Trans as MtlTrans) -package transformers (Control.Monad.Trans as TransformersTrans)` would DTRT. **With** the `-backpack` flag, no auto-hiding of packages occurs (this affects flags with thinning and renaming). Furthermore, the package database is cleared, as would be done with `-hide-all-packages`. We replace the old resolution algorithm with the new one, which processes each flag one-by-one while building a module mapping, picking a package which is consistent with the currently selected set of packages. This consistency is done by looking at the current module mapping and ensuring all of the modules the package would bring into scope are consistent with the modules we have already. Both example shown before would work; furthermore, `-package foo -package foo` would also continue to work, since `foo`'s exports are consistent with itself. However, `-package foo-0.1 -package foo-0.2` would be rejected (whereas now it is accepted.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9379: Blocked STM transaction is not interruptible
by GHC 04 Aug '14

04 Aug '14

#9379: Blocked STM transaction is not interruptible -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{#!hs import Control.Exception import Control.Concurrent import Control.Concurrent.STM import Foreign.StablePtr main :: IO () main = do tv <- atomically $ newTVar True _ <- newStablePtr tv t <- mask_ $ forkIO (blockSTM tv) killThread t blockSTM :: TVar Bool -> IO () blockSTM tv = do atomically $ do v <- readTVar tv check $ not v }}} This code blocks forever. As I understand it, since the transaction blocks, it should be interruptible even despite the mask, and so killThread must succeed here, and the program should finish promptly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9379> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);`
by GHC 04 Aug '14

04 Aug '14

#9329: GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- The following Cmm code snippet compiles fine {{{#!c foo () { STK_CHK_GEN_N (((1)*8)); /* works */ return (0); } }}} The following one, however, only compiles with `-O0`, but panics with `-O1` or more: {{{#!c foo () { STK_CHK_GEN_N (8); /* panics */ return (0); } }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): bundle c1 foo [(c1, label: block{v c1}_info rep:StackRep [])] [(c0, {}), (c3, {})] foo() // [] { info_tbl: [(c1, label: block{v c1}_info rep:StackRep [])] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c0: R1 = 0; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } } Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9329> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp
by GHC 04 Aug '14

04 Aug '14

#9303: O2: (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp ----------------------------------+--------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- {{{ ghc --make -O2 M.hs [1 of 1] Compiling M ( M.hs, M.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_s1Mp Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As in #9155 bug was caught on '''wx''' package in the same module. I didn't try to trim it down to minimal sample. No external modules required. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8880: Configured gcc not used for some build steps
by GHC 02 Aug '14

02 Aug '14

#8880: Configured gcc not used for some build steps ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: | ------------------------------------+------------------------------------- The gcc passed to `./configure --with-gcc` isn't used for all gcc invocations, leadings to warnings (and potentially problems) on OS X where the default gcc is llvm. Here's an example, the call to `gcc -E` doesn't use my configure gcc, `/usr/local/bin/gcc-4.9`: {{{ sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.debug_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_debug_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.l_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.thr_l_dyn_o|" -e "1s|^|rts/|" -e "1s|rts/|rts/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/Users/tibbe/src/ghc/||g" rts/dist/build/.depend-v-dyn-l-debug-thr- thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit >> rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp && true gcc -E -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build -m64 -fno-stack-protector -Wall -Wextra -Wstrict-prototypes -Wmissing- prototypes -Wmissing-declarations -Winline -Waggregate-return -Wpointer- arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict- aliasing -fno-common -DDTRACE -O2 -fomit-frame-pointer -DRtsWay=\"rts_v\" -Wno-strict-prototypes -MM -x c rts/WSDeque.c -MF rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn- thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit no checking for sigaction... In file included from rts/WSDeque.c:44: In file included from rts/RtsUtils.h:12: rts/BeginPrivate.h:9:13: warning: unknown pragma ignored [-Wunknown- pragmas] #pragma GCC visibility push(hidden) ^ In file included from rts/WSDeque.c:44: In file included from rts/RtsUtils.h:48: rts/EndPrivate.h:2:13: warning: unknown pragma ignored [-Wunknown-pragmas] #pragma GCC visibility pop ^ 2 warnings generated. }}} I can't quite tell from which part of the build this is. Looks RTS related. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8880> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons
by GHC 01 Aug '14

01 Aug '14

#8331: GHC fails to apply {-# SPECIALIZE #-} for dubious reasons -------------------------+------------------------------------------------- Reporter: | Owner: blitzcode | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I encountered a 'RULE left-hand side too complicated to desugar' warning when trying to reduce some typeclass overhead through a SPECIALIZE pragma. The change I had to make to my program to make the warning go away seems rather strange, so I thought it might be worth reporting as a bug. This is the small test case I wrote to understand the problem better: {{{ {-# LANGUAGE FlexibleInstances, RankNTypes #-} module Main (main) where import Control.Monad import Control.Monad.Reader import Control.Monad.ST import Control.Applicative class (Applicative m, {- Functor m ,-} Monad m) => MonadAbstractIOST m where addstuff :: Int -> m Int type ReaderST s = ReaderT (Int) (ST s) instance MonadAbstractIOST (ReaderST s) where addstuff a = return . (a +) =<< ask runAbstractST :: (forall s. ReaderST s a) -> a runAbstractST f = runST $ runReaderT f 99 {-# SPECIALIZE INLINE useAbstractMonad :: ReaderST s Int #-} useAbstractMonad :: MonadAbstractIOST m => m Int useAbstractMonad = foldM (\a b -> a `seq` return . (a +) =<< (addstuff b)) 0 [1..50000000] -- useConcreteMonad :: ReaderST s Int -- useConcreteMonad = foldM (\a b -> a `seq` return . (a +) =<< (addstuff b)) 0 [1..50000000] main :: IO () main = do let st = runAbstractST useAbstractMonad putStrLn . show $ st }}} The use case here is simply having a library of functions which are abstracted from the underlying implementation of state (Reader / IO, Reader / ST, etc.) and operate on it with a small set of typeclass functions. This has very severe runtime overhead (~5x) compared to using the actual transformer stack directly, so a SPECIALIZE pragma seemed a good idea. The simple program above works as expected, but the warning appears as soon as the 'Functor' superclass is commented back in. It seems to me this should make no difference as Functor is already a superclass of Applicative. It was still there simply by oversight. I think SPECIALIZE should not fail in this case, and if it does, it would be really helpful to have a better error message. 'Too complicated' does not help in tracking down what needs to be changed for the specialization to happen, and given how harsh the overhead is otherwise, this is quite painful. In any case, once the specialization is applied in my actual program, the following error appears: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone a_saCf{v} [lid] 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: 66169 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It seems like I need a -fsimpl-tick-factor of 450-500 for the compilation to succeed, resulting in a ~3x increase in binary size and a ~4x increase in compile time. The resulting code at least seems to benefit from the specialization as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8331> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8