February 2014 - ghc-tickets

[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

[GHC] #8673: GHC could generate GADT record selectors in more cases
by GHC 17 May '14

17 May '14

#8673: GHC could generate GADT record selectors in more cases ------------------------------------+------------------------------------- Reporter: simonpj | 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: | ------------------------------------+------------------------------------- Philip Holzenspies writes (in email to ghc-users): I was playing around with GADT-records again and ran into behaviour that I'm not sure is intentional. Given this program: {{{ {-#LANGUAGE GADTs #-} data FooBar x a where Foo :: { fooBar :: a } -> FooBar Char a Bar :: { fooBar :: a } -> FooBar Bool a }}} GHC tells me this: {{{ foo.hs:3:1: Constructors Foo and Bar have a common field `fooBar', but have different result types In the data declaration for `FooBar' Failed, modules loaded: none. }}} The user guide does say (section 7.4.7): "However, for GADTs there is the following additional constraint: every constructor that has a field f must have the same result type (modulo alpha conversion)." So this behaviour is documented in the user guide. However, it seems reasonable that in the case above, where all the relevant variables are exposed in the result type of both constructors, this should be perfectly typeable. In other words, shouldn't GHC be able to derive a type that is simply: {{{ fooBar :: FooBar x a -> a }}} ? Is this something that was simply never implemented, but could be, or is this not decidable or prohibitively computationally complex? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8673> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8742: Reuse scavenge_small_bitmap
by GHC 29 Apr '14

29 Apr '14

#8742: Reuse scavenge_small_bitmap ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | 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: | ------------------------------------+------------------------------------- Hi, I've found that the `scavenge_small_bitmap` is in-lined at two places. I added this patch to remove code duplication. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8121: Gitolite Migration
by GHC 28 Apr '14

28 Apr '14

#8121: Gitolite Migration ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: None | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This ticket is for keeping track of the implementation of the [GitolitePlan Gitolite Migration Plan] See also the posting [http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/1618 "Proposal: Gitolite for repository management"] to ghc-devs(a)haskell.org -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure)
by GHC 28 Apr '14

28 Apr '14

#8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ------------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- NB: this may be a dupe of another issue, but reporting is separately for now i'm on OS X 10.8 (mountain lion) with xcode 5, ghc comit 23fb7f3b7987d7b3fa445e54680a8a00a37e714d, I've got a gcc-4.8 installed, though gcc in my path is actually clang (as is typical for xcode 5), so I configured as {{{ ./configure --with-gcc=gcc-4.8 }}} and then I noticed as i'm building, some warnings that mean clang is being called rather than gcc! heres a relevant snippet of the build transcript {{{ cp" utils/hsc2hs/template-hsc.h inplace/lib/template-hsc.h "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H64m -O -fasm -package process -package containers -package-db libraries/bootstrapping.conf -i -iutils/deriveConstants/. -iutils/deriveConstants/dist/build -iutils/deriveConstants/dist/build/autogen -Iutils/deriveConstants/dist/build -Iutils/deriveConstants/dist/build/autogen -no-user-package-db -rtsopts -odir utils/deriveConstants/dist/build -hidir utils/deriveConstants/dist/build -stubdir utils/deriveConstants/dist/build -c utils/deriveConstants/./DeriveConstants.hs -o utils/deriveConstants/dist/build/DeriveConstants.o "inplace/bin/mkdirhier" utils/deriveConstants/dist/build/tmp//. "inplace/bin/mkdirhier" rts/dist/build//. gcc -E -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt compiler/prelude/primops.txt.pp:35:55: warning: missing terminating ' character [-Winvalid-pp-token] -- The default attribute values which apply if you don't specify ^ compiler/prelude/primops.txt.pp:1310:19: warning: missing terminating ' character [-Winvalid-pp-token] difference doesn't fit in an {\tt Int\#}.} ^ compiler/prelude/primops.txt.pp:1591:41: warning: missing terminating ' character [-Winvalid-pp-token] -- not really the right type, but we don't know about pairs here. The ^ compiler/prelude/primops.txt.pp:1620:15: warning: missing terminating ' character [-Winvalid-pp-token] -- but we don't want to tell the strictness ^ compiler/prelude/primops.txt.pp:1634:30: warning: missing terminating ' character [-Winvalid-pp-token] -- must be *precise* - we don't want the strictness analyser turning ^ compiler/prelude/primops.txt.pp:1690:14: warning: missing terminating ' character [-Winvalid-pp-token] -- NB: retry#'s strictness information specifies it to return bottom. ^ compiler/prelude/primops.txt.pp:1811:47: warning: missing terminating ' character [-Winvalid-pp-token] Otherwise, store value arg as {\tt MVar\#}'s new contents, and return with integer 1.} ^ compiler/prelude/primops.txt.pp:1906:21: warning: missing terminating ' character [-Winvalid-pp-token] {\tt RealWorld}; it's only used in the type system, to parameterise {\tt State\#}. } ^ compiler/prelude/primops.txt.pp:2084:67: warning: missing terminating ' character [-Winvalid-pp-token] -- why return the value? So that we can control sharing of seq'd ^ compiler/prelude/primops.txt.pp:2087:13: warning: missing terminating ' character [-Winvalid-pp-token] -- we don't want to inline x, so better to represent it as ^ compiler/prelude/primops.txt.pp:2108:48: warning: missing terminating ' character [-Winvalid-pp-token] -- `the processor containing the expression v'; it is not evaluated ^ compiler/prelude/primops.txt.pp:2206:20: warning: missing terminating ' character [-Winvalid-pp-token] {These aren't nearly as wired in as Etc...} ^ compiler/prelude/primops.txt.pp:2236:57: warning: missing terminating ' character [-Winvalid-pp-token] * It does not claim to be a {\it data} type, and that's important for ^ compiler/prelude/primops.txt.pp:2240:4: warning: missing terminating ' character [-Winvalid-pp-token] It's also used to instantiate un-constrained type variables after type ^ compiler/prelude/primops.txt.pp:2278:86: warning: missing terminating ' character [-Winvalid-pp-token] used when you want to write a program that you know is well-typed, but where Haskell's ^ compiler/prelude/primops.txt.pp:2301:28: warning: missing terminating ' character [-Winvalid-pp-token] have to do with GHC's internal representation details (for the congnoscenti, data values ^ compiler/prelude/primops.txt.pp:2307:76: warning: missing terminating ' character [-Winvalid-pp-token] -- NB. It is tempting to think that casting a value to a type that it doesn't have is safe ^ compiler/prelude/primops.txt.pp:2308:22: warning: missing terminating ' character [-Winvalid-pp-token] -- as long as you don't "do anything" with the value in its cast form, such as seq on it. This ^ compiler/prelude/primops.txt.pp:2309:7: warning: missing terminating ' character [-Winvalid-pp-token] -- isn't the case: the compiler can insert seqs itself, and if these happen at the wrong type, ^ compiler/prelude/primops.txt.pp:2344:17: warning: missing terminating ' character [-Winvalid-pp-token] the newtype's concrete type to the abstract type. But it also works in ^ compiler/prelude/primops.txt.pp:2367:67: warning: missing terminating ' character [-Winvalid-pp-token] {\tt instance Coercible b b' => Coercible (D a b c) (D a b' c')} ^ compiler/prelude/primops.txt.pp:2389:43: warning: missing terminating ' character [-Winvalid-pp-token] you need to set the role of {\tt Set}'s type parameter to Nominal. }}} notice the hard coded gcc call {{{ gcc -E -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked
by GHC 28 Apr '14

28 Apr '14

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- See http://www.reddit.com/r/haskell/comments/1luan1/strange_io_sequence_behavio… for a very simple program (`main'`) that accidentally evades the stack size limit, running to completion even though it has allocated hundreds of megabytes of stack chunks, and [http://www.reddit.com/r/haskell/comments/1luan1/strange_io_sequence_behavio… my comment] for an explanation of this behavior. ryani suggested that when a thread exceeds its stack limit but it is currently blocking exceptions, the RTS shouldn't simply drop the `StackOverflow` exception, but rather deliver it when the `mask` operation completes. That sounds sensible to me and it would give a nice guarantee that when any individual `mask` operation uses a small amount of stack, the stack size limit is approximately enforced. (I know that the default stack size limit may go away or essentially go away, but it can still be nice when developing to use a small stack size limit, so that one's system isn't run into the ground by infinite recursion quickly gobbling up tons of memory.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8728: Segmentation fault in Cabal
by GHC 28 Apr '14

28 Apr '14

#8728: Segmentation fault in Cabal -------------------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Keywords: Cabal | Operating System: MacOS X Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+---------------------------------- I get a segfault in the following program, compiled on OS X with the development version of GHC (last commit 50e4d40f88c3eee41384efacfd83f73305e2210d), run with the command `./Setup configure`. A `.cabal` file is not needed to produce the error. {{{ -- ghc --make Setup.hs import Distribution.Simple main = defaultMainWithHooks simpleUserHooks }}} I discovered the problem when installing `llvm-general-pure`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8728> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8676: RTS headers don't compile as C++
by GHC 28 Apr '14

28 Apr '14

#8676: RTS headers don't compile as C++ ----------------------------------+---------------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- GHC's RTS headers can't be included from C++, as they contain constructs like this {{{ dbl_link_replace(bdescr *new, bdescr *old, bdescr **list) }}} (notice the 'new'). This is the case for the headers shipped with 7.6.3 and still seems to be in the HEAD version. Since the code has the usual {{{ #ifdef __cplusplus extern "C" { #endif }}} all over the place, I assume the C++ incompatibility is simply an oversight? In any case, it would seem highly unusual to have a C interface that can't be consumed from C++. It seems all the incompatibilities could be removed with at worst a small amount of inconvenience, and automatic checking for C++ compatibility on each build could be added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8676> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8366: haskeline Posix backend needs #include <sys/termios.h> on Solaris
by GHC 28 Apr '14

28 Apr '14

#8366: haskeline Posix backend needs #include <sys/termios.h> on Solaris -------------------------------------+------------------------------------- Reporter: oddsignals | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.7 Keywords: | Operating System: Solaris Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- !System/Console/Haskeline/Backend/Posix.hsc needs an #include <sys/termios.h> to compile under Solaris. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8366> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11