June 2014 - ghc-tickets

[GHC] #9154: Links to Cabal documentation from the user guide are broken
by GHC 19 Aug '14

19 Aug '14

#9154: Links to Cabal documentation from the user guide are broken ------------------------------------+------------------------------------- Reporter: etrepum | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- At http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/packages.html there are two broken links to Cabal documentation, there's also a broken absolute link to the same place from the haddock documentation. {{{ $ find ./share/doc/ghc -name "*.html" -exec grep -H "Cabal/index.html" {} \; ./share/doc/ghc/html/haddock/invoking.html: tool <a class="ulink" href="http://www.haskell.org/ghc/docs/latest/html/Cabal/index.html" target="_top">Cabal</a> ./share/doc/ghc/html/users_guide/packages.html: <a class="ulink" href="../Cabal/index.html" target="_top">Cabal documentation</a> ./share/doc/ghc/html/users_guide/packages.html: <a class="ulink" href="../Cabal/index.html" target="_top">Cabal</a> infrastructure }}} I suppose the right place for all of these links is probably http://www.haskell.org/cabal/users-guide/ ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8943: Add System.Process.createPipe
by GHC 19 Aug '14

19 Aug '14

#8943: Add System.Process.createPipe -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/process | 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: | -------------------------------------+------------------------------------- As agreed in: http://comments.gmane.org/gmane.comp.lang.haskell.libraries/21373 I've validated the patch on OS X, but I need someone to validate on Windows. I originally wrote this code for cabal and tested it on all platforms back then. I no longer have a Windows machine and the imports in `System.Process` are messy enough that someone needs to check that it still builds on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9150: libraries/time: parseTime barfs on leading space in format string
by GHC 18 Aug '14

18 Aug '14

#9150: libraries/time: parseTime barfs on leading space in format string --------------------------+------------------------------------------------ Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ This used to work around 1.4.0, one of my test suites caught it: {{{ module Main where import Data.Time.Clock import Data.Time.Format import System.Locale main :: IO () main = do putStrLn "Trailing space is handled:" print $ (parseTime defaultTimeLocale "%M " "15 " :: Maybe UTCTime) putStrLn "\nBut leading space isn't:" print $ (parseTime defaultTimeLocale " %M" " 15" :: Maybe UTCTime) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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 11 Aug '14

11 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 07 Aug '14

07 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] #8880: Configured gcc not used for some build steps
by GHC 03 Aug '14

03 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

[GHC] #8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory
by GHC 28 Jul '14

28 Jul '14

#8873: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory -------------------------------------------+------------------------------- Reporter: configurator | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- The paths used in the {{{ghcii.sh}}} scripts to start {{{ghc --interactive}}} are incorrectly built using {{{"$0"/..}}}, which causes the message: {{{ /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: exec: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: cannot execute: No such file or directory }}} I believe using {{{"$(dirname "$0")"}}} would be a portable solution that works under both cygwin and Linux versions of bash. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8407: Module re-exports at the package level
by GHC 26 Jul '14

26 Jul '14

#8407: Module re-exports at the package level ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package 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: | ------------------------------------+------------------------------------- For various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice. I wrote up a design spec at ModuleReexports; this bug is to track the progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8407> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17