March 2014 - ghc-tickets

[GHC] #8667: sync-all doesn't work properly if you run from a fork on github
by GHC 20 Jun '14

20 Jun '14

#8667: sync-all doesn't work properly if you run from a fork on github ------------------------------------+------------------------------------- Reporter: schyler | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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 intuitive behaviour when working with projects on github is to make your own fork so that you can use the online interface (or GitHub for {windows,osx} apps). One would assume that this behaviour was endorsed because of the ~130 forks to the ghc repo, however forking the repo actually causes ./sync-all to stop working (it asks for a username and password to whomever@ github.com) It seems the only way for a person to work with the project from github is to clone directly from the original repo. This sounds like a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8753: Import constructor but not the data type
by GHC 09 Jun '14

09 Jun '14

#8753: Import constructor but not the data type ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- How do I import a constructor but not its data type? The constructor might have the name of a data type which I do not want to bring into scope. Use case: Library (A) defines a parametrized data type (D a) which I want to use in my code (B) in instantiated form (D Int) but with the same name (D). I want to pattern match against inhabitants of type D, so I need the constructor(s) in scope. Here is how it could look like if import lists let me specify whether I want to import a type or a constructor with name "D". module A where data D a = D a module B where import A (constructor D) import qualified A D = A.D Int f :: D -> Int f (D x) = x Haskell has different name spaces for type and constructors, but does not let the user talk about these name spaces where it matters, namely in import/export lists. At least I found no documentation instructing me how to do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8939: Should check the return value of clock_gettime
by GHC 08 Jun '14

08 Jun '14

#8939: Should check the return value of clock_gettime -------------------------------------------+------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: -------------------------------------------+------------------------------- In `ghc-7.6.3/rts/posix/GetTime.c`, function `StgWord64 getMonotonicNSec(void)`: The return value of `clock_gettime` should be checked, and if the value is not 0 (success), it should fall back to `gettimeofday`. The following patch demonstrates a possible fix: {{{ --- pre/rts/posix/GetTime.c 2013-04-18 17:22:47.000000000 -0400 +++ ghc-7.6.3/rts/posix/GetTime.c 2014-03-28 09:52:08.537125998 -0400 @@ -84,19 +82,22 @@ #ifdef HAVE_CLOCK_GETTIME struct timespec ts; + int res= clock_gettime(CLOCK_ID, &ts); + if(res==0) return (StgWord64)ts.tv_sec * 1000000000 + (StgWord64)ts.tv_nsec; #elif defined(darwin_HOST_OS) uint64_t time = mach_absolute_time(); return (time * timer_scaling_factor_numer) / timer_scaling_factor_denom; -#else +#endif + { //fallback struct timeval tv; gettimeofday(&tv, (struct timezone *) NULL); return (StgWord64)tv.tv_sec * 1000000000 + (StgWord64)tv.tv_usec * 1000; -#endif + } } Time getProcessElapsedTime(void) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure
by GHC 08 Jun '14

08 Jun '14

#8938: Should fallback instead of EXIT_FAILURE on clock_gettime failure -------------------------------------------+------------------------------- Reporter: uznx | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: -------------------------------------------+------------------------------- In GHC 7.6, `rts/posix/GetTime.c, Time getProcessCPUTime(void)`: if the result of `clock_gettime` is not zero (success), then the function should fall back to getrusage below instead of aborting with {{{ sysErrorBelch("clock_gettime"); stg_exit(EXIT_FAILURE); }}} The following patch demonstrates a possible fix: {{{ --- pre/rts/posix/GetTime.c 2013-04-18 17:22:47.000000000 -0400 +++ ghc-7.6.3/rts/posix/GetTime.c 2014-03-28 09:52:08.537125998 -0400 @@ -64,10 +64,8 @@ res = clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &ts); if (res == 0) { return SecondsToTime(ts.tv_sec) + NSToTime(ts.tv_nsec); - } else { - sysErrorBelch("clock_gettime"); - stg_exit(EXIT_FAILURE); } + // else fallback } #endif }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8942: Duplicate symbol error when loading an archive twice
by GHC 08 Jun '14

08 Jun '14

#8942: Duplicate symbol error when loading an archive twice ------------------------------------+------------------------------- Reporter: gelisam | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- ghci can load packages from object files (*.o) and from archive files (*.a). When an object file is loaded twice, the second attempt is silently ignored. When an archive file is loaded twice, ghci aborts with the message "fatal error: I found a duplicate definition for symbol ''s''", for the first symbol ''s'' in the archive. === Patch The attached patch changes {{{rts/Linker.c}}} so that loading an archive file twice silently ignores the second attempt, just like it does with object files. === Repro steps Install a package using Cabal 1.18.*, as that version only produces archives and not objects. Then, force ghci to load that package twice. One way to do this is to use hint inside ghci to load a value from the package. {{{ $ ghci > import Hello > import Language.Haskell.Interpreter > r <- runInterpreter $ setImports ["Hello"] >> interpret "Hello" (as :: Hello) Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package unix-2.6.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package old-time-1.1.0.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package process-1.1.0.2 ... linking ... done. Loading package Cabal-1.16.0 ... linking ... done. Loading package binary-0.5.1.1 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.9.0.0 ... linking ... done. Loading package hpc-0.6.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package ghc-7.6.3 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package hello-0.1.0.0 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package exceptions-0.3.3.1 ... linking ... done. Loading package extensible-exceptions-0.1.1.4 ... linking ... done. Loading package ghc-mtl-1.1.0.0 ... linking ... done. Loading package ghc-paths-0.1.0.9 ... linking ... done. Loading package random-1.0.1.1 ... linking ... done. Loading package hint-0.4.0.0 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol ___stginit_hellozm0zi1zi0zi0_Hello whilst processing object file /Users/gelisam/.cabal/lib/x86_64-osx- ghc-7.6.3/hello-0.1.0.0/libHShello-0.1.0.0.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} A minimal definition for the hello package is attached, but doesn't contain anything relevant to the issue. It's just a dummy datatype: {{{#!haskell {-# LANGUAGE DeriveDataTypeable #-} module Hello where import Data.Typeable data Hello = Hello deriving Typeable }}} === Workaround Use Cabal 1.16, which (also) installs object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8942> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling)
by GHC 03 Jun '14

03 Jun '14

#8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ----------------------------------+--------------------------------------- Reporter: MagnusTherning | 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: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I'm configuring and building {{{haskell-src-exts}}} like this: {{{ runhaskell Setup configure -O -p --enable-shared \ -fbase4 runhaskell Setup build }}} It builds the ordinary bits just fine, but when it gets to compiling for profiling: {{{ [ 1 of 22] Compiling Language.Haskell.Exts.Annotated.Syntax ( src/Language/Haskell/Exts/Annotated/Syntax.hs, dist/build/Language/Haskell/Exts/Annotated/Syntax.p_o ) /tmp/ghc340_0/ghc340_8.s:1:0: internal compiler error: Segmentation fault .section .rodata ^ Please submit a full bug report, with preprocessed source if appropriate. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8475: Library docs: broken links to Foreign.ForeignPtr
by GHC 03 Jun '14

03 Jun '14

#8475: Library docs: broken links to Foreign.ForeignPtr ------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Documentation | 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: | ------------------------------------+------------------------------------- In the library docs at `http://www.haskell.org/ghc/docs/latest/html/libraries/index.html`, the `Foreign.ForeignPtr` module in the contents is the one from `haskell2010`, not `base`. This causes various problems, it seems. For instance: * the link from `ForeignPtr` to `Foreign.ForeignPtr` is broken * the link from `Foreign.Concurrent` to `Foreign.ForeignPtr` is broken there are probably other broken links too. We need to figure out what to do about overlapping modules properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8781: check if GNU nm is realy needed and if so let configure detect gnm
by GHC 03 Jun '14

03 Jun '14

#8781: check if GNU nm is realy needed and if so let configure detect gnm ----------------------------------+---------------------------------------- Reporter: maeder | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1-rc1 Component: Build System | Operating System: Solaris Keywords: | Type of failure: Building GHC failed Architecture: x86 | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- building ghc-7.8.20140130 under Solaris fails with a non-GNU nm as follows: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/opt/csw/bin/gcc" --gcc-flag -U__i686 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc- flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/ccs/bin/nm" Can't find "STD_HDR_SIZE" gmake[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 43

[GHC] #8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris
by GHC 03 Jun '14

03 Jun '14

#8783: make ghc-pwd-bindist script /bin/sh compatible for Solaris ------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://www.haskell.org/ghc/dist/7.8.1-rc1/ghc-7.8.20140130-i386-unknown- solaris2.tar.bz2 has a ghc-pwd-bindist script containing {{{ #!/bin/sh export LD_LIBRARY_PATH="libraries/directory/dist- install/build:libraries/unix/dist-install/build:libraries/time/dist- install/build:libraries/old-locale/dist-install/build:libraries/filepath /dist-install/build:libraries/bytestring/dist- install/build:libraries/deepseq/dist-install/build:libraries/array/dist- install/build:libraries/base/dist-install/build:libraries/integer-gmp /dist-install/build:libraries/ghc-prim/dist- install/build:rts/dist/build:$LD_LIBRARY_PATH" exec "utils/ghc-pwd/dist-install/build/tmp/ghc-pwd" ${1+"$@"} }}} that fails during configure under Solaris with: {{{ checking for path to top of build tree... utils/ghc-pwd/dist- install/build/tmp/ghc-pwd-bindist: LD_LIBRARY_PATH=libraries/directory /dist-install/build:libraries/unix/dist-install/build:libraries/time/dist- install/build:libraries/old-locale/dist-install/build:libraries/filepath /dist-install/build:libraries/bytestring/dist- install/build:libraries/deepseq/dist-install/build:libraries/array/dist- install/build:libraries/base/dist-install/build:libraries/integer-gmp /dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:: is not an identifier configure: error: cannot determine current directory }}} see more under http://www.haskell.org/pipermail/glasgow-haskell- users/2014-February/024669.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks
by GHC 24 May '14

24 May '14

#8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks ----------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Are we going to make available directions so that people can use 7.6 correctly with xcode 5 and/or mavericks? eg: will we provide directions to either 1. use Luke Ianni's clang wrapper hack, and bundle that with a 7.6 release thats 7.6.3 + that extra binary to make a 10.8 friendly "stability" release 2. tell people to stick to xcode 4.6 and/or install a newer GCC (say, GCC 4.8) and adjust their ghc settings file to point to that other GCC? We need to provide this information in a clear way, because this WILL be a problem where we'll have a support load from it (whether we want to or not, until GHC 7.8 gets a haskell platform release, this WILL happen. We need to have a mitigation strategy so that we aren't dealing with it constantly) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9