November 2013 - ghc-tickets

[GHC] #8378: Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkGmpConstants workaround fails to build objects for integer-gmp
by GHC 24 Mar '14

24 Mar '14

#8378: Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkGmpConstants workaround fails to build objects for integer-gmp -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: solaris,integer- | Operating System: Unknown/Multiple gmp | Type of failure: Building GHC Architecture: Unknown/Multiple | failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8373,8366,8361 | -------------------------------------+------------------------------------- Here is the script I used to get build dependencies: {{{ sudo apt-get update sudo apt-get install --assume-yes ghc libncurses5-dev \ mesa-common-dev freeglut3-dev libedit-dev cabal install happy alex haddock }}} Here is the build bootstrap script I am using on a clean Ubuntu 13.04 install: {{{ #!/bin/bash export TARGET=x86_64-sun-solaris2.11 export PREFIX=$HOME/Documents/gcc/cross/$TARGET export SYSROOT=$PREFIX/sysroot export PATH=$PATH:$PREFIX/bin export GCC=$PREFIX/bin/$TARGET-gcc export LD=$PREFIX/bin/$TARGET-ld export NM=$PREFIX/bin/$TARGET-nm export OBJDUMP=$PREFIX/bin/$TARGET-objdump git clone git://github.com/ghc/ghc pushd ghc echo "Stage1Only = YES" >> mk/build.mk cp mk/build.mk{.sample,} ./sync-all --no-dph get perl boot patch -d libraries/haskeline/ -p1 < \ ../ghc-patches/0001-Include-termios.h-for- solaris2-host.-Fixes-8366.patch cp $SYSROOT/opt/local/include/gmp.h libraries/integer-gmp/gmp/ ./configure \ --host=x86_64-unknown-linux-gnu \ --build=x86_64-unknown-linux-gnu \ --target=x86_64-sun-solaris2 \ --with-gcc=$GCC \ --with-ld=$LD \ --with-nm=$NM \ --with-objdump=$OBJDUMP make # will fail with failure to run mkGmpDerivedConstants scp inplace/lib/bin/mkGmpDerivedConstants root@ns2:. ssh root@ns2 "./mkGmpDerivedConstants" > \ libraries/integer-gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h make cat << __EOF__ >> libraries/base/include/HsBaseConfig.h #define HTYPE_DOUBLE Double #define HTYPE_FLOAT Float __EOF__ make #make -j $(nproc) popd }}} The log of the run is attached. It is too large for the ticket body and apparently too large for Gist as well. Somewhere along the way the build forgets integer-gmp and no objects are built for it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8351: Arrays are always allocated out-of-line
by GHC 23 Mar '14

23 Mar '14

#8351: Arrays are always allocated out-of-line ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- unordered-containers uses lots of small arrays (length <= 16). These arrays are always allocated out-of-line by a call to `allocate`. I suspect this is bad for performance. We should look into supporting inline- allocation, perhaps by using a new `newSmallArray#` primop and/or by spotting calls to `newArray#` with a small, statically-known size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools)
by GHC 18 Mar '14

18 Mar '14

#8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools) ----------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I got the following panics when I ran the GHC test suite per ticket #8148 (using xcode 5 CLI dev preview tools released as of august 21st on OS X 10.8) =====> ghcilink003(normal) 889 of 3736 [8, 195, 0] cd ./ghci/linking && $MAKE -s --no-print-directory ghcilink003 </dev/null >ghcilink003.run.stdout 2>ghcilink003.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> EnumFromToP(normal) 564 of 3736 [0, 82, 0] cd ./dph/enumfromto && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c EnumFromToP.hs -O -fno-enable-rewrite-rules -package dph-lifted-vseg >EnumFromToP.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-22 16:09:56.000000000 -0400 +++ ./dph/enumfromto/EnumFromToP.comp.stderr 2013-08-22 16:11:18.000000000 -0400 @@ -0,0 +1,6 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20130822 for x86_64-apple-darwin): + DsMonad: uninitialised ds_parr_bi + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> jmp_tbl(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c jmp_tbl.hs -O -fasm -fPIC -O >jmp_tbl.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(hpc) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fhpc -hpcdir .hpc.T7574 -no- hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fasm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(normal) 102 of 3736 [0, 2, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8124: Possible leaks when using foreign export.
by GHC 17 Mar '14

17 Mar '14

#8124: Possible leaks when using foreign export. ------------------------------+-------------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.6.3 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- When a Haskell function exported with foreign export is called from outside Haskell a new Task may be allocated for it. There will be one Task allocated for each OS thread calling into Haskell (this happens in rts_lock()). This Task is, by design, never deallocated. This works fine with a small number of threads, but if the external caller generates a lot of threads that die the Haskell RTS will just get more and more Task objects that are never freed. The Task also contains a condition variable and a mutex, which incurs a HANDLE leak on Windows. I don't see an elegant fix to this, but the attached code remembers the OS thread for "incall" Task, and every so often (every 100 Tasks created) if will scan the Tasks looking for ones where the OS thread is dead, and remove these. The fix only works on Windows, I'm afraid. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8254: confusing comment on allocate()
by GHC 27 Feb '14

27 Feb '14

#8254: confusing comment on allocate() ------------------------------------+-------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- {{{ /* ----------------------------------------------------------------------------- allocate() This allocates memory in the current thread - it is intended for use primarily from STG-land where we have a Capability. It is better than allocate() because it doesn't require taking the sm_mutex lock in the common case. Memory is allocated directly from the nursery if possible (but not from the current nursery block, so as not to interfere with Hp/HpLim). -------------------------------------------------------------------------- */ }}} Not sure what, if anything, `allocate()` is better than, but it's not `allocate()`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8254> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8512: Add flag like '-xc' that only reports uncaught exceptions
by GHC 21 Feb '14

21 Feb '14

#8512: Add flag like '-xc' that only reports uncaught exceptions ------------------------------------+------------------------------------- Reporter: blitzcode | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The -xc RTS flag reports the stack trace of all exceptions. This can be very noisy when, for instance, certain http or parsing libraries are used that throw many exceptions, often handled fully internal, during their normal operation. Having multiple threads makes it even noisier. I'd think having a flag like -xc that only reports uncaught exceptions would be useful. It seems the GHCi debugger has a flag to only stop on uncaught exceptions, maybe this could be made available as an RTS option? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8512> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8301: error BaseReg must be in a register for THREADED_RTS
by GHC 18 Feb '14

18 Feb '14

#8301: error BaseReg must be in a register for THREADED_RTS -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------------- Compiling git HEAD on powerpc64-linux. This was working as recently as two weeks ago. Now getting: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name ghc-7.7.20130914 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage2 -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.3.1 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package time-1.4.1 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -DNO_REGS -optc-DTHREADED_RTS -DSTAGE=2 -O2 -fwarn-tabs -fno-warn-amp -O -dcore-lint -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -c compiler/utils/Platform.hs -o compiler/stage2/build/Platform.o In file included from /home/erikd/PPC64/ghc-ppc64/includes/Stg.h:232:0: 0, from /tmp/ghc10950_0/ghc10950_2.hc:3: /home/erikd/PPC64/ghc-ppc64/includes/stg/Regs.h:359:2: error: #error BaseReg must be in a register for THREADED_RTS }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8365: stage2 build fails on Solaris (SmartOS)
by GHC 17 Feb '14

17 Feb '14

#8365: stage2 build fails on Solaris (SmartOS) ----------------------------------+---------------------------------------- Reporter: oddsignals | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I'm getting some missing symbols building on 32-bit SmartOS. 'quick' flavour build, DYNAMIC_BY_DEFAULT = NO, DYNAMIC_GHC_PROGRAMS = NO. {{{ $ uname -a SunOS pkgx86 5.11 joyent_20130919T215407Z i86pc i386 i86pc Solaris }}} {{{ "inplace/bin/ghc-stage1" -o ghc/stage2/build/tmp/ghc-stage2 -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -hide-all-packages -i -ighc/. -ighc/stage2/build -ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/autogen/cabal_macros.h -package array-0.4.0.2 -package base-4.7.0.0 -package bytestring-0.10.3.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package ghc-7.7.20130926 -package haskeline-0.7.0.4 -package process-1.2.0.0 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XPatternGuards -XNondecreasingIndentation -XForeignFunctionInterface -XUnboxedTuples -XFlexibleInstances -XMagicHash -O0 -fasm -threaded -no-user-package-db -rtsopts -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build ghc/stage2/build/Main.o ghc/stage2/build/InteractiveUI.o ghc/stage2/build/GhciMonad.o ghc/stage2/build/GhciTags.o ghc/stage2/build/hschooks.o <no location info>: Warning: Couldn't figure out linker information! Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc. Undefined first referenced symbol in file base_GHCziConcziIO_ensureIOManagerIsRunning_closure /opt/src/ghc/rts/dist/build/libHSrts_thr.a(RtsStartup.thr_o) base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure /opt/src/ghc/rts/dist/build/libHSrts_thr.a(RtsStartup.thr_o) base_GHCziPack_unpackCString_closure /opt/src/ghc/rts/dist/build/libHSrts_thr.a(RtsAPI.thr_o) ld: fatal: symbol referencing errors. No output written to ghc/stage2/build/tmp/ghc-stage2 collect2: error: ld returned 1 exit status make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8305: ghci macros override built-ins for command expansion
by GHC 13 Feb '14

13 Feb '14

#8305: ghci macros override built-ins for command expansion ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | 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: #8113 | ------------------------------------+------------------------------------- I have a ghci macro `:tsu` from the ghc-vis package, which I installed a long time ago. In HEAD ghci (since the patch for #8113) this causes `:t` to expand to `:tsu`, rather than `:type`. That happened to result in a weird error the first time I tried to use `:t` (something like `Prelude.read: no parse`), and it took me a while to diagnose that my `.ghci` file was the issue! I don't like this new behavior because it forces me to either change my ghci habits (start using `:type` instead of `:t`) or avoid macros starting with any letter that I currently use as a single-letter ghci command. I set this ticket priority to highest because in any event this new behavior shouldn't sneak in to a GHC release unnoticed. Below is my proposal for how `:commands` should be interpreted now that built-in commands can be overridden (#8113), copied from a comment I made recently on that ticket. ---- I suppose what I specifically want to happen when I enter a `:command` is an algorithm like this. If the name I entered is an exact match for a macro or built-in, use that name. Otherwise, try to complete the name to the name of a ''built-in'' in the traditional way. If this succeeds, use the resulting name. Otherwise, try to complete the name to the name of a macro, and use the resulting name if that succeeds, otherwise give up. In all cases where we got a name, use the ''macro'' of that name if there is one, and otherwise use the built-in. (Obviously, for `::command`, ignore macros entirely.) In other words, built-ins should take precedence over macros for the purpose of name ''completion'', but macros should take precedence over built-ins for the purpose of name ''lookup''. This is backwards- compatible from the perspective of the user who is not aware of the change—`:t` will always mean `:type`, as long as the user has no macro named `:t`, just like in previous versions of ghci—while still allowing the aware user to redefine exactly what `:type` means. And it's flexible enough in that if the user really wants `:t` to complete to some other macro `:test` that they've written, they can always define another macro `:t` to expand to `:test`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8305> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing
by GHC 12 Feb '14

12 Feb '14

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | 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: 1377 | ------------------------------------+------------------------------------- The `GHC.Exts` module exports functions [[http://hackage.haskell.org/package/base-4.6.0.1/docs/GHC- Exts.html#g:6|breakpoint and breakpointCond]]. Right now they are no-ops, but apparently at some point in the past could be used to set breakpoints programmatically. From my reading of the source code, this feature was removed (either accidentally or on purpose) when the implementation of breakpoints [[changeset:cdce647711c0f46f5799b24de087622cb77e647f/ghc|was reworked]]. Relevant commits: * 31751ccacc24ebe5d15a0af84b10dc612d455440 * 3a99fa889bdff0c86df20cb18c71d30e30a79b43 * cdce647711c0f46f5799b24de087622cb77e647f Initially reported [http://stackoverflow.com/questions/19283911/how-do-i -use-ghc-exts-breakpoint here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6