March 2013 - ghc-tickets

[GHC] #7754: Can't find curses.h when building cross-compiler
by GHC 21 Mar '13

21 Mar '13

#7754: Can't find curses.h when building cross-compiler --------------------------------+------------------------------------------- Reporter: fumieval | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: arm, terminfo, raspberry pi Os: Linux | Architecture: arm Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- {{{ $ PATH=$PATH:/home/fumiaki/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin $ ./configure --target=arm-linux-gnueabihf --enable-unregisterised $ make (...) "inplace/bin/ghc-cabal" check libraries/terminfo "inplace/bin/ghc-cabal" configure --with- ghc="/home/fumiaki/ghc/inplace/bin/ghc-stage1" --with-ghc- pkg="/home/fumiaki/ghc/inplace/bin/ghc-pkg" --enable-library-vanilla --disable-library-profiling --disable-shared --disable-library-for-ghci --enable-library-for-ghci --with- hscolour="/home/fumiaki/.cabal/bin/HsColour" --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --configure-option=--host=arm-unknown-linux-gnueabihf --with- gcc="/home/fumiaki/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf- raspbian/bin/arm-linux-gnueabihf-gcc" --with-ld="/home/fumiaki/tools/arm- bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf- ld" --configure-option=--with-cc="/home/fumiaki/tools/arm-bcm2708/gcc- linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc" --with- ar="/usr/bin/ar" --with-ranlib="true" --with- alex="/home/fumiaki/.cabal/bin/alex" --with- happy="/home/fumiaki/.cabal/bin/happy" -- dist-install libraries/terminfo Configuring terminfo-0.3.2.5... configure: WARNING: unrecognized options: --with-compiler, --with-gcc configure: WARNING: if you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used checking for arm-unknown-linux-gnueabihf-gcc... /home/fumiaki/tools/arm- bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf- gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /home/fumiaki/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc accepts -g... yes checking for /home/fumiaki/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc option to accept ISO C89... none needed checking how to run the C preprocessor... /home/fumiaki/tools/arm-bcm2708 /gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking curses.h usability... no checking curses.h presence... no checking for curses.h... no configure: error: in `/home/fumiaki/ghc/libraries/terminfo': configure: error: curses headers could not be found, so this package cannot be built See `config.log' for more details make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 }}} Of course there are curses.h and corresponding library which is installed by 'apt-get install libncurses5-dev'. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4941: SpecConstr generates functions that do not use their arguments
by GHC 21 Mar '13

21 Mar '13

#4941: SpecConstr generates functions that do not use their arguments ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): Replying to [comment:20 nfrisby]: > I'm investigating nucleic2 at the moment; it's changing something currently not specifically tracked by ticky, so I'm resurrecting more counters. There's nothing obvious to me in the STG, at least. It's actually pretty clear in the STG. A let at the entry to $w$wvar_most_distant_atom with 12 free Float# vars gets inlined into numerous thunks, at least 24 (25?) of which are allocated all at once. In the CMM `Hp = Hp + 1376` becomes `Hp = Hp + 3576`. Some arithmetic with these numbers just about covers the reported ticky difference for $w$wvar_most_distant_atom. Needs more inspection (distinct from this ticket... sorry), though this seems a bit of a corner case: arity=40 and the involved state type uses record types with numerous non-strict fields of type Float. I'll record it with the ticket I'm soon making for the late demand analysis pass. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4941#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7781: Dumb error message when trying to runghc a module with no 'main' function
by GHC 21 Mar '13

21 Mar '13

#7781: Dumb error message when trying to runghc a module with no 'main' function -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- $ runghc Log.hs Log.hs:1:33: Not in scope: `main' Perhaps you meant `min' (imported from Prelude) It really should say something like: No `main` function found. Can't run a module with no `main'. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4837: Template Haskell does not work in a profiled compiler.
by GHC 21 Mar '13

21 Mar '13

#4837: Template Haskell does not work in a profiled compiler. ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Profiling | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Old description: > Template Haskell does not work if the compiler itself is built profiles. > Because of this we cannot debug GHC compile time performance problems > when compiling Data.Vector and DPH as they use Template Haskell. #4172 is > related. > > Trying to use Template Haskell in a profiled compiler currently triggers > the assertion at {{{main/HscMain.hs:1245}}} New description: Template Haskell does not work if the compiler itself is built profiles. Because of this we cannot debug GHC compile time performance problems when compiling Data.Vector and DPH as they use Template Haskell. #4172 is related. Trying to use Template Haskell in a profiled compiler currently triggers the assertion at {{{main/HscMain.hs:1245}}} Supporting this would also mean that we can run GHCi with profiled code! -- Comment(by ezyang): OK, I added a note to the description mentioning GHCi would also benefit from this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4837#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4837: Template Haskell does not work in a profiled compiler.
by GHC 20 Mar '13

20 Mar '13

#4837: Template Haskell does not work in a profiled compiler. ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Profiling | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: closed #3360 as a dup. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4837#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3360: Add profiling support to GHCi
by GHC 20 Mar '13

20 Mar '13

#3360: Add profiling support to GHCi -------------------------------+-------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.2 Resolution: duplicate | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Closing as dup of #4837 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3360#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7743: GHCI segfaults with Data.Binary instances
by GHC 20 Mar '13

20 Mar '13

#7743: GHCI segfaults with Data.Binary instances -----------------------------+---------------------------------------------- Reporter: BigEndian | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following code seems to crash GHCi I apologize for the long test case, but I'll need to rebuild ghc with symbols first before I can reduce the test case. GHCi's output is {{{ eric@sagacity ~/prog/haskell/tasks master > ghci GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l Segfault.hs [1 of 1] Compiling Main ( Segfault.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package binary-0.5.1.1 ... linking ... done. "zsh: segmentation fault ghci }}} Related code is {{{ module Main where import qualified Data.ByteString as BW import Data.Word(Word8(..)) import Data.Binary import Control.Monad import Data.Char convertWord8ToChar :: Word8 -> Char convertWord8ToChar = chr . fromIntegral convertCharToWord8 :: Char -> Word8 convertCharToWord8 = fromIntegral . ord stringToWByteString :: String -> BW.ByteString stringToWByteString = BW.pack . map convertCharToWord8 wByteStringToString :: BW.ByteString -> String wByteStringToString = map convertWord8ToChar . BW.unpack newtype TaskString = TaskString BW.ByteString deriving (Read, Show) stringToTaskString :: String -> TaskString stringToTaskString = TaskString . stringToWByteString word8sToTaskString :: [Word8] -> TaskString word8sToTaskString = TaskString . BW.pack instance Binary TaskString where get = do (return . word8sToTaskString . init) =<< readWord8sUntil 0 where readWord8sUntil :: Word8 -> Get [Word8] readWord8sUntil val = do w8 <- getWord8 if w8 == val then return $ [w8] else (return . (w8:)) =<< (readWord8sUntil val) put (TaskString bws) = mapM_ putWord8 $ (BW.unpack bws) ++ [0] data Task = Task { taskTitle :: TaskString, taskNotes :: TaskString, taskPriority :: Int } deriving (Read, Show) instance Binary Task where get = do tt <- get :: Get TaskString tn <- get :: Get TaskString tp <- get :: Get Int return Task { taskTitle = tt, taskNotes = tn, taskPriority = tp } put t = do put $ taskTitle t put $ taskNotes t put $ taskPriority t exTaskTitle = stringToTaskString "Do the dishes" exTaskNotes = stringToTaskString "Must be done by 12:00 today" exTaskPriority = 0 encTaskTitle = encode exTaskTitle decTaskTitle = decode encTaskTitle :: TaskString exTask = Task { taskTitle = exTaskTitle, taskNotes = exTaskNotes, taskPriority = exTaskPriority } encTask = encode exTask decTask = decode encTask :: Task main = do putStrLn $ show encTask -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4837: Template Haskell does not work in a profiled compiler.
by GHC 20 Mar '13

20 Mar '13

#4837: Template Haskell does not work in a profiled compiler. ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Profiling | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by ezyang): #3360 seems related? I'm not sure what the difference here is. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4837#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5302: Unused arguments in join points
by GHC 20 Mar '13

20 Mar '13

#5302: Unused arguments in join points ---------------------------------+------------------------------------------ Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): As of 321941a, this test case (at less the _full.hs one) still generates the unused arguments. In fact, the join point under discussion also contains a join point with the same flaw. This happens with and without a SpecConstr. In both cases, a late demand analysis removes both unnecessary arguments. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5302#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4941: SpecConstr generates functions that do not use their arguments
by GHC 20 Mar '13

20 Mar '13

#4941: SpecConstr generates functions that do not use their arguments ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): Replying to [comment:9 batterseapower]: > I looked at the worst offender (crypytarithm2) and saw something pretty odd. It looks like the transformation is working correctly but the output code (post simplification) contains dead let-bindings for SpecConstr specialisations that have been worker/wrappered, and those workers have been subsequently inlined into all use sites. Replying to [comment:14 batterseapower]: > I fail to see how this does not explain the allocation increase - if my inner loop is allocating a spurious closure for this dead function, doesn't that increase the allocation figures? The dead function is not present in the version of the code without the extra strictness analysis pass. These dead SpecConstr'd and ww'd closures are still allocated in cryptarithm2. With the late demand, cryptarithm2 has +8% allocation. These dead closures are 4% of that (according to ticky). The other 4% is reboxing: 3 words, ~ 4000 times --- for calls to those dead lets' progeny, no less. I used the pipeline: SpecConstr, simpl, stranal, wwsplit, simpl. I have confirmed that the variables are dead in the STG. I have not investigated why the fix for #4962 doesn't remove these lets. I altered ticky to count the heap used when allocating each closure. {{{ Entries Allocs Alloc'd Arity Kinds Function -------------------------------------------------------------------------------- 0 0 2056 3 SSL $sgo{v s2X7} (main:Main) 0 0 8262 3 SSL $sgo{v s2Qx} (main:Main) 0 0 13460 3 ESL $sgo1{v s2Zq} (main:Main) 0 0 25288 3 ESL $sgo1{v s2R0} (main:Main) 0 0 75814 3 SSL $sgo{v s2Ui} (main:Main) 3376149 ALLOC_HEAP_tot }}} With just -O2, it's 3125158 ALLOC_HEAP_tot. Otherwise, the late demand looks pretty good. Column header = <libraries options>/<nofib test options>. ____ is 0.0%. In this notation, "late-dmd" implies also -O2. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd/O2 late-dmd/late-dmd ------------------------------------------------------------------------------- cryptarithm2 25078168 +____ +8.0% nucleic2 98331744 +____ +3.2% cichelli 80310632 +____ -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +____ -2.6% k-nucleotide 4125102928 -____ -4.8% knights 2037984 +____ -3.7% mandel2 1041840 +____ -21.4% parstof 3103208 +____ -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -____ -1.0% }}} I'm investigating nucleic2 at the moment; it's changing something currently not specifically tracked by ticky, so I'm resurrecting more counters. There's nothing obvious to me in the STG, at least. I don't yet have trustworthy runtime numbers. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4941#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0