- ghc-tickets - Haskell.org

Re: [GHC] #7473: getModificationTime gives only second-level resolution
by GHC 28 Dec '14

28 Dec '14

#7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by redneb): The pull request has been merged so I think this bug can be closed now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7473#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9762: #8696 + #9012
by GHC 28 Dec '14

28 Dec '14

#9762: #8696 + #9012 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- As of the patch for #9012, we create a static reference to an HPC ticks label if and only if it is in the same package, which is correct for building normally, but not for building libraries that are to be loaded piecemeal by GHCi/TH (as was the issue in #8696). See http://lpaste.net/113689 for an example error. I also wonder whether the other cases of `CLabel.labelDynamic` that check for "same package" could result in similar issues. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] Batch modify: #9032, #9652, #9762, #9905, #9924
by GHC 28 Dec '14

28 Dec '14

Batch modification to #9032, #9652, #9762, #9905, #9924 by hvr: Action: merged Comment: has been cherry-picked into ghc-7.10 branch -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=9032%2C9652%2C9762%2C9905%2C9924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9652: Bootstrapping GHC HEAD against itself doesn't work
by GHC 27 Dec '14

27 Dec '14

#9652: Bootstrapping GHC HEAD against itself doesn't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've got a partial patch: {{{ diff --git a/ghc.mk b/ghc.mk index eedb023..37ef2f2 100644 --- a/ghc.mk +++ b/ghc.mk @@ -719,7 +719,7 @@ ifneq "$(BINDIST)" "YES" ifneq "$(BOOTSTRAPPING_CONF)" "" ifeq "$(wildcard $(BOOTSTRAPPING_CONF))" "" -$(shell echo "[]" >$(BOOTSTRAPPING_CONF)) +$(shell $(GHC_PKG) init $(BOOTSTRAPPING_CONF)) endif endif }}} But I'm dying here: {{{ ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory compiler/ghc.mk:646: compiler/stage1/build/.depend-v.haskell: No such file or directory ghc/ghc.mk:114: ghc/stage1/build/.depend.haskell: No such file or directory "rm" -f ghc/stage1/build/.depend.haskell.tmp "/home/hs01/ezyang/ghc-head/inplace/bin/ghc-stage2" -M -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -optP-include -optPghc/stage1/build/autogen/cabal_macros.h -package-key array_GX4NwjS8xZkC2ZPtjgwhnz -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key direc_1OR7Bu5EIqqJUPTpfzOCIt -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key ghc_GE0xPzNsQzT2p10hpwDwSW -package-key proce_JJ2k66FcGHSLNmYZUkX8Td -package-key unix_4dEexQFispVG782agZacZC -Wall -XHaskell2010 -no-user-package-db -rtsopts -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -dep- makefile ghc/stage1/build/.depend.haskell.tmp -dep-suffix "" -include-pkg- deps ghc/./Main.hs <command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) ghc/ghc.mk:114: recipe for target 'ghc/stage1/build/.depend.haskell' failed make[1]: *** [ghc/stage1/build/.depend.haskell] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 }}} A bit hard to diagnose due to #9651. Recording this so I don't forget. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9032: Panic with self-import
by GHC 27 Dec '14

27 Dec '14

#9032: Panic with self-import -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I've run into GHC panic with this code: {{{ {-# OPTIONS_GHC -fno-warn-unused-imports #-} module Singletons.Star where import Data.Singletons.Prelude import Data.Singletons.Decide import Data.Singletons.CustomStar import Singletons.Nat import Singletons.Star -- <------- HERE data Vec :: * -> Nat -> * where VNil :: Vec a Zero VCons :: a -> Vec a n -> Vec a (Succ n) $(singletonStar [''Nat, ''Int, ''String, ''Maybe, ''Vec]) }}} This is a test in `singletons` package that leads to a panic when run: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: singletons-1.0:Singletons.Star.TFCo:R:DemoteRep*KProxy{tc r0} [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I was unable to minimize the test case. Reproducing requires following steps: 1. Installing latest th-desugar library from github: {{{ git clone https://github.com/goldfirere/th-desugar.git cd th-desugar cabal install }}} 2. Getting latest development version of singletons: {{{ git clone https://github.com/goldfirere/singletons cd singletons git checkout 56734c2bda721cb9a6a3021b901e3b29d6564f0c make tests }}} All should go well. Now you need to edit file `tests/compile-and- dump/Singletons/Star.hs` and uncomment `import Singletons.Star` line. It should be possible to reproduce the bug with: {{{ cd tests/compile-and-dump/ghc -package-name singletons-1.0 Singletons/Star.hs -i../../dist/build -c -XTemplateHaskell }}} It's important to run `make tests` first so that all interface files required by `Star.hs` are in place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9924: libffi configure script does not detect MSYS2 Windows 10 x86_64
by GHC 27 Dec '14

27 Dec '14

#9924: libffi configure script does not detect MSYS2 Windows 10 x86_64 -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When building GHC 7.10 RC 1 on Windows 10 Technical Preview, 64 bit, in MSYS2, libffi fails with the message that it cannot determine the build system, and that `config.guess` and `config.sub` may need to be updated. The latest versions do indeed work. Unfortunately the scripts are stored in the `libffi.tar` file, if we don't want to change the file we'll need some way to get the correct versions in place. I have a very hacky workaround that downloads the latest versions after unpacking the tar, which is obviously not how it should be solved, but might help some people get their RC1 to build before we have a proper fix: {{{ diff --git a/libffi/ghc.mk b/libffi/ghc.mk index ec37f0c..fbd2e5e 100644 --- a/libffi/ghc.mk +++ b/libffi/ghc.mk @@ -89,6 +89,9 @@ $(libffi_STAMP_CONFIGURE): $(TOUCH_DEP) cd libffi && \ $(LIBFFI_PATH_MANGLE) \ cd build && \ + autoreconf -f && \ + wget -O config.guess "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues…" && \ + wget -O config.sub "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;…" && \ CC=$(CC_STAGE1) \ CXX=$(CC_STAGE1) \ LD=$(LD) \ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7593: Unable to print exceptions of unicode identifiers
by GHC 26 Dec '14

26 Dec '14

#7593: Unable to print exceptions of unicode identifiers -------------------------------------+------------------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown warning at compile-time | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jeremy-list): The workaround I've been using is to add "//TRANSLIT" to the encoding of stdin, stdout, and stderr. I believe this should be the default rather than something I have to specify in my program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7593#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #17: Separate warnings for unused local and top-level bindings
by GHC 25 Dec '14

25 Dec '14

#17: Separate warnings for unused local and top-level bindings -------------------------------------+------------------------------------- Reporter: magunter | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: lowest | Version: None Component: Compiler | Keywords: -fwarn-unused- Resolution: None | binds newcomer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3283 Test Case: | Blocking: | Differential Revisions: Phab:D591 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D591 * milestone: ⊥ => 7.12.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/17#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9905: ghc-7.8.x command line error
by GHC 24 Dec '14

24 Dec '14

#9905: ghc-7.8.x command line error -------------------------------------+------------------------------------- Reporter: zRecursive | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `$ghc -e "import Data.List" -e "print 9"` will not output 9 but `ghc -e "print 9"` works normally. However, both commands work on ghc-7.6.x. Regards! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol'
by GHC 24 Dec '14

24 Dec '14

#8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' ----------------------------------+------------------------------ Reporter: Kata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------ Building ekmett's lens package from HEAD (revision 80c1fddf) with the following error fragment: {{{ Last 10 lines of the build log ( /home/kata/.cabal/logs/lens-4.0.log ): [77 of 85] Compiling Data.Vector.Lens ( src/Data/Vector/Lens.hs, dist/build/Data/Vector/Lens.o ) [78 of 85] Compiling Data.Vector.Generic.Lens ( src/Data/Vector/Generic/Lens.hs, dist/build/Data/Vector/Generic/Lens.o ) [79 of 85] Compiling Generics.Deriving.Lens ( src/Generics/Deriving/Lens.hs, dist/build/Generics/Deriving/Lens.o ) [80 of 85] Compiling GHC.Generics.Lens ( src/GHC/Generics/Lens.hs, dist/build/GHC/Generics/Lens.o ) [81 of 85] Compiling System.Exit.Lens ( src/System/Exit/Lens.hs, dist/build/System/Exit/Lens.o ) [82 of 85] Compiling System.FilePath.Lens ( src/System/FilePath/Lens.hs, dist/build/System/FilePath/Lens.o ) [83 of 85] Compiling System.IO.Error.Lens ( src/System/IO/Error/Lens.hs, dist/build/System/IO/Error/Lens.o ) /usr/bin/ld: dist/build/Control/Lens/TH.dyn_o: relocation R_X86_64_PC32 against undefined symbol `lenszm4zi0_ControlziLensziInternalziTH_appsE1zulgo_info' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status cabal: Error: some packages failed to install: lens-4.0 failed during the building phase. The exception was: ExitFailure 1 }}} Full log is attached. I'm not trying to build with shared libraries, or profiling, or anything like that. I can reproduce this failure starting from a fresh Debian testing install as follows: 1. Bootstrap GHC HEAD. {{{ sudo aptitude install ghc=7.6.3-6 happy=1.19.0-1 alex=3.1.0-1 sudo apt-get build-dep ghc cd /var/tmp git clone git://git.haskell.org/ghc.git cd ghc git checkout e01367ff ./sync-all get ./boot ./configure # Adjust the -j option to taste. make -j4 sudo make install }}} 2. Bootstrap cabal-install. {{{ cd /var/tmp wget http://www.haskell.org/cabal/release/cabal-install-1.18.0.2/cabal- install-1.18.0.2.tar.gz -O - | tar xzf - cd cabal-install-1.18.0.2 patch -p3 < cabal-install-ghc-HEAD.patch # see attached sudo aptitude install zlib1g-dev ./bootstrap.sh export PATH=$HOME/.cabal/bin:$PATH cabal update }}} 3. Build lens. {{{ cd /var/tmp git clone https://github.com/ekmett/lens cd lens git checkout 80c1fddf cabal install cpphs cabal install # this fails }}} Using gcc Debian 4.8.2-14, ld 2.24. The GHC fingerprint and output of `ghc --info` is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34