- ghc-tickets - Haskell.org

Re: [GHC] #284: RPM doesn't support --prefix
by GHC 10 Jul '14

10 Jul '14

#284: RPM doesn't support --prefix -------------------------------------+------------------------------------ Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Build System | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by ydewit): There seems to be two areas that need to be fixed to support relocatable installs: the shell wrappers and the .conf files. Both of these set of files have absolute paths. Regarding the shell wrappers (e.g. $GHC_HOME/bin/{ghc,ghc- pkg,ghci,runghc,runhaskell}), we could simply use a slightly different scheme. For instance, an alternative for the ghc wrapper: {{{ #!/bin/sh GHC_HOME=$( cd $(dirname $0)/.. ; pwd ) exedir="${GHC_HOME}/lib/ghc-7.8.2/bin" exeprog="ghc-stage2" executablename="$exedir/$exeprog" datadir="${GHC_HOME}/lib" bindir="${GHC_HOME}/bin" topdir="${GHC_HOME}" executablename="$exedir/ghc" exec "$executablename" -B"$topdir" ${1+"$@"} }}} The critical piece is {{{ GHC_HOME=$( cd $(dirname $0)/.. ; pwd ) }}} since it needs to work for all supported platforms. Other than that, it is pretty straight-forward. I see that there is support for a {{{RelocatableBuild}}} variable in config.mk, but it is turned on only on Windows: {{{ # On Windows we normally want to make a relocatable bindist, to we # ignore flags like libdir ifeq "$(Windows_Host)" "YES" RelocatableBuild = YES else RelocatableBuild = NO endif }}} So it seems that we have two different layouts: one for Windows and one for everything else: {{{ exec_prefix = ${prefix} bindir = ${exec_prefix}/bin datadir = ${datarootdir} libdir = ${exec_prefix}/lib includedir = ${prefix}/include mandir = ${datarootdir}/man docdir = ${datarootdir}/doc/${PACKAGE_TARNAME} $(eval $(call set_default,docdir,$${datarootdir}/doc/ghc)) htmldir = ${docdir} dvidir = ${docdir} pdfdir = ${docdir} psdir = ${docdir} $(eval $(call set_default,htmldir,$${docdir})) $(eval $(call set_default,dvidir,$${docdir})) $(eval $(call set_default,pdfdir,$${docdir})) $(eval $(call set_default,psdir,$${docdir})) ifeq "$(RelocatableBuild)" "YES" # Hack: our directory layouts tend to be different on Windows, so # hack around configure's bogus assumptions here. datarootdir = $(prefix) datadir = $(prefix)/lib libdir = $(prefix)/lib docdir = $(prefix)/doc htmldir = $(docdir) dvidir = $(docdir) pdfdir = $(docdir) psdir = $(docdir) ghclibdir = $(libdir) ghcdocdir = $(datarootdir)/doc else # Unix: override libdir and datadir to put ghc-specific stuff in # a subdirectory with the version number included. # # datadir is set to libdir here as GHC needs package.conf and unlit # to be in the same place (and things like ghc-pkg need to agree on # where package.conf is, so we just set it globally). # ghclibdir = $(libdir)/$(CrossCompilePrefix)ghc-$(ProjectVersion) ghcdocdir = $(datarootdir)/doc/ghc endif ghclibexecdir = $(ghclibdir) topdir = $(ghclibdir) ghcheaderdir = $(ghclibdir)/include }}} Why two layouts? I also see that the non-windows layout is accounting for cross compilation, which is doesn't seem supported in the Windows layout. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/284#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9290: The job a whole tight will be
by GHC 10 Jul '14

10 Jul '14

#9290: The job a whole tight will be ------------------------------------+------------------------------------- Reporter: herbertlawrence | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: Horsepower XXL | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- You really have a great and rebuilding you know by you think I think there I'd get there I think character is an American as apple pie we live in a society today you got it and he in reality shows Madonna is making out with Britney Spears randy is a candle and hit you worried about steroids kids like you got to you made playing video games the current tampering [http://slioswim.com/ Horsepower XXL] that more influence in my opinion this can lead to ever be in Barry Bonds hit a homerun if there's a big difference between him taking them you don't need Paralympics a couple years as opposed to have grown man looking to perform better and better level in sports and we're thrilled maker known as I mean he’s the poster boy hysterical think the modem we heard it look at me like I did came I conquered a kickass that more biography says he was born in with 15 16 hey he won at the University nineteen-years-old 19 get to see what it looks like when hews 19 you think it was God given to next time you think that maybe people to performance-enhancing white people idolize these guys went into rock band body blow the movies on whether at all when you get to meet them and mandate a webcam a good day never at her what they appear to be thing I do you think in public like this got the middle finger on the table like this never look at the end what you get what you think and what they want you to see everybody idolized Schwarzenegger going up everybody put my hand want to lightweights in the end up. http://slioswim.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9290> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv)
by GHC 10 Jul '14

10 Jul '14

#9003: GHC eventlog: thread stop status codes modified (breaking ghc-events, threadscope, edentv) -------------------------------------------+------------------------------- Reporter: jberthold | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- A patch in GHC-7.7 modified the "thread stop status" encoding, so the current ghc-events (version 0.4.2.0 from 2012) produces wrong stop reasons when reading an eventlog written by GHC-7.8.2. The GHC patch is http://git.haskell.org/ghc.git/commit/70e20631742e516c6a11c3c112fbd5b4a08c1… The MVarRead block reason was added in the middle, shifting all following block reason codes one up. The error can be observed when a thread blocks on a black hole during a program run. Attached is a small test program which produces this situation, and two event logs for the same program run with the same arguments and RTS parameters. The program's two threads evaluate the same data, the parent thread typically blocks on a blackhole created by a forked child thread. Note the sequence around user event "child": The log written by GHC-7.6.3 correctly shows blocking on a black hole, while the log written by GHC-7.8.2 claims the main thread blocks "on I/O read". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #7103: Compiler panic, when loading wxc in GHCi
by GHC 09 Jul '14

09 Jul '14

#7103: Compiler panic, when loading wxc in GHCi -------------------------------+------------------------------------ Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by Henk-Jan): * cc: hvr (added) Comment: The problem still exists with GHC 7.8.2, compiled with DYNAMIC_GHC_PROGRAMS=YES. This is tested on Windows 8.1 (64-bit) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7103#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4218: System.Random is way too lazy
by GHC 08 Jul '14

08 Jul '14

#4218: System.Random is way too lazy ---------------------------------+----------------------------------------- Reporter: EyalLotem | Owner: rrnewton Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack overflow Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: Test Case: | Blocking: | ---------------------------------+----------------------------------------- Changes (by thomie): * cc: rrnewton (added) * difficulty: => Unknown * component: Compiler => libraries/random * milestone: 7.6.2 => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4218#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl
by GHC 07 Jul '14

07 Jul '14

#9270: GHC HEAD accepts a manual instance decl but not equivalent TH decl ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- If I try to build the traverse-with-class package with GHC HEAD, I get an error: {{{ Data/Generics/Traversable/Instances.hs:21:1: Illegal type constructor or class name: ‘c’ When splicing a TH declaration: instance c_0 a_1 => Data.Generics.Traversable.Core.GTraversable c_0 (Data.Maybe.Maybe a_1) where Data.Generics.Traversable.Core.gtraverse = \f_2 x_3 -> case x_3 of Data.Maybe.Nothing -> Control.Applicative.pure Data.Maybe.Nothing Data.Maybe.Just arg_4 -> (Control.Applicative.<*>) (Control.Applicative.pure Data.Maybe.Just) (f_2 arg_4) }}} This code used to compile with all the previous versions. Additionally, if I replace the TH splice with the generated instance declaration (with minimal corrections to make all names resolve), it is accepted: {{{ instance c_0 a_1 => Data.Generics.Traversable.Core.GTraversable c_0 (Maybe a_1) where gtraverse = \f_2 x_3 -> case x_3 of Nothing -> Control.Applicative.pure Nothing Just arg_4 -> (Control.Applicative.<*>) (Control.Applicative.pure Just) (f_2 arg_4) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9283: bad autoconf variable names
by GHC 07 Jul '14

07 Jul '14

#9283: bad autoconf variable names ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | 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: | ------------------------------------+------------------------------------- {{{ if test "$ac_cv_header_sys_epoll_h" = yes -a "$ac_cv_func_epoll_ctl" = yes; then AC_DEFINE([HAVE_EPOLL], [1], [Define if you have epoll support.]) fi if test "$ac_cv_header_sys_event_h" = yes -a "$ac_cv_func_kqueue" = yes; then AC_DEFINE([HAVE_KQUEUE], [1], [Define if you have kqueue support.]) AC_CHECK_SIZEOF([kev.filter], [], [#include <sys/event.h> struct kevent kev;]) AC_CHECK_SIZEOF([kev.flags], [], [#include <sys/event.h> struct kevent kev;]) fi if test "$ac_cv_header_poll_h" = yes -a "$ac_cv_func_poll" = yes; then AC_DEFINE([HAVE_POLL], [1], [Define if you have poll support.]) fi }}} The `AC_DEFINE` lines for `HAVE_KQUEUE` and `HAVE_POLL` don't do anything, because earlier we have {{{ AC_CHECK_FUNCS([epoll_ctl eventfd kevent kevent64 kqueue poll]) }}} and that already defines `HAVE_KQUEUE` (and sets `ac_cv_func_kqueue`) when the `kqueue` function is found. Not entirely sure what the right thing to do is here, do we rely on having a prototype for `kqueue` in `sys/event.h` specifically? Technically that wouldn't be what we check for even if we used a renamed `HAVE_KQUEUE` variable. AFAIK this doesn't cause any real problems except that it really confused me when I tried to simulate not having `poll` by moving `/usr/include/poll.h` away temporarily. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5610: Improve "Unacceptable argument type in foreign declaration" error message
by GHC 07 Jul '14

07 Jul '14

#5610: Improve "Unacceptable argument type in foreign declaration" error message -------------------------------------------------+------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type checker) | Version: Resolution: | 7.6.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect warning at | Architecture: compile-time | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by mietek): With 7.8.2, using `import Foreign.C.Types (CInt)` still results in the unclear error message: {{{ Unacceptable argument type in foreign declaration: CInt }}} Using `import Foreign.C.Types (CInt (..))` helps, but should this be required? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5610#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9275: Missing import statement in GHC.Event.Poll
by GHC 06 Jul '14

06 Jul '14

#9275: Missing import statement in GHC.Event.Poll ----------------------------------+---------------------------------------- Reporter: ydewit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- See the following section from base's GHC.Event.Poll module: {{{ module GHC.Event.Poll ( new , available ) where #include "EventConfig.h" #if !defined(HAVE_POLL_H) import GHC.Base new :: IO E.Backend new = error "Poll back end not implemented for this platform" available :: Bool available = False {-# INLINE available #-} #else #include <poll.h> import Control.Concurrent.MVar (MVar, newMVar, swapMVar) import Control.Monad ((=<<), liftM, liftM2, unless) import Data.Bits (Bits, FiniteBits, (.|.), (.&.)) import Data.Maybe (Maybe(..)) import Data.Monoid (Monoid(..)) import Data.Word import Foreign.C.Types (CInt(..), CShort(..)) import Foreign.Ptr (Ptr) import Foreign.Storable (Storable(..)) import GHC.Base import GHC.Conc.Sync (withMVar) import GHC.Enum (maxBound) import GHC.Num (Num(..)) import GHC.Real (ceiling, fromIntegral) import GHC.Show (Show) import System.Posix.Types (Fd(..)) import qualified GHC.Event.Array as A import qualified GHC.Event.Internal as E }}} Note how there is a missing {{{import qualified GHC.Event.Internal as E}}} when {{{HAVE_POLL_H}}} is not defined. The same issue is present in master. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9277: audit ghc floating point support for IEEE (non)compliance
by GHC 06 Jul '14

06 Jul '14

#9277: audit ghc floating point support for IEEE (non)compliance ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: high | Milestone: 7.10.1 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: | ------------------------------------+------------------------------------- As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation. This impacts both a number of other tasks i wish to do for ghc **and** much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to: a) improve test suite support for checking for compliance b) write some patches to provide portable compliant primops for the operations which need compiler support c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point. (this may grow into a few subtickets, we'll see) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9277> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0