November 2013 - ghc-tickets

[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] #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] #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

[GHC] #8458: T5435_dyn_asm fails on x86_64 Linux
by GHC 22 Apr '14

22 Apr '14

#8458: T5435_dyn_asm fails on x86_64 Linux --------------------------+------------------------------------------------ Reporter: | Owner: simonmar jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: | Operating System: Linux Runtime System | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: x86_64 | Blocking: (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I keep getting failure from `T5435_dyn_asm` test: {{{ make WAY=normal TEST=T5435_dyn_asm =====> T5435_dyn_asm(normal) 2622 of 3829 [0, 0, 0] cd ./rts && $MAKE -s --no-print-directory T5435_dyn_asm </dev/null >T5435_dyn_asm.run.stdout 2>T5435_dyn_asm.run.stderr Actual stdout output differs from expected: --- ./rts/T5435_dyn_asm.stdout 2013-10-16 09:49:22.236712001 +0200 +++ ./rts/T5435_dyn_asm.run.stdout 2013-10-18 19:26:11.076223002 +0200 @@ -1,5 +1,5 @@ -initArray1 -initArray2 ctors1 ctors2 +initArray1 +initArray2 success *** unexpected failure for T5435_dyn_asm(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8458> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8141: Liberalising IncoherentInstances
by GHC 22 Apr '14

22 Apr '14

#8141: Liberalising IncoherentInstances ------------------------------------+------------------------------------- Reporter: nomeata | 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: | ------------------------------------+------------------------------------- As [http://www.haskell.org/pipermail/glasgow-haskell- users/2013-July/022651.html|SPJ argued], -XIncoherentInstances could be even more liberal. This ticket is to give the proposal a number; I am currently preparing a patch for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8491: Make BlockAlloc.c comments slightly more accurate
by GHC 13 Apr '14

13 Apr '14

#8491: Make BlockAlloc.c comments slightly more accurate ------------------------------------+------------------------------------- Reporter: ezyang | 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: | ------------------------------------+------------------------------------- I think this patch makes the comments for BlockAlloc slightly more accurate, but I'd like someone to double check for me. {{{ diff --git a/rts/sm/BlockAlloc.c b/rts/sm/BlockAlloc.c index 18c167f..41a2279 100644 --- a/rts/sm/BlockAlloc.c +++ b/rts/sm/BlockAlloc.c @@ -45,7 +45,7 @@ static void initMBlock(void *mblock); bd->free is either: - zero for a non-group-head; bd->link points to the head - (-1) for the head of a free block group - - or it points within the block + - or it points within the block (group) bd->blocks is either: - zero for a non-group-head; bd->link points to the head }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8491> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8153: Implement AES intrinsics
by GHC 11 Apr '14

11 Apr '14

#8153: Implement AES intrinsics ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- LLVM has the following intrinsics for working with AES encryption; @llvm.x86.aesni_{aesimc,aesenc,aesenclast,aesdec,aesdeclast,aeskeygenassist} It would be nice if at some stage these are supported through primops/intrinsics, as it would mean the crypto libraries can be rewritten to not use C and we'd get some nicer inlining on these. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8157: Add a broader set of (C/CMM-based) atomic memory operations
by GHC 10 Apr '14

10 Apr '14

#8157: Add a broader set of (C/CMM-based) atomic memory operations ------------------------------------+------------------------------------- Reporter: rrnewton | 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: | ------------------------------------+------------------------------------- This task is a precursor to ticket #7883. The goal is to standardize a broader set of atomic ops -- mainly CAS and fetch-and-add -- and then in #7883 we will optimize those primops to have native support in the LLVM backend and thus avoid the extra C calls. Currently, the goal is only to support word-sized (4 or 8 byte) compare-and-swap and fetch-and-add operations. In the future, this goal could be expanded to support 16-byte CAS, implemented by CMPXCHG16B on x86. Even supporting word sized CAS requires three different primops for operating on `MutVar`, `MutableArray`, and `MutableByteArray`, respectively. Here are signatures for those primOps: {{{ #!C gcptr stg_casMutVarzh ( gcptr mv, gcptr old, gcptr new ) /* MutVar# s a -> a -> a -> State# s -> (# State#, Int#, Any a #) */ gcptr stg_casArrayzh ( gcptr arr, W_ ind, gcptr old, gcptr new ); /* MutableArray# s a -> Int# -> a -> a -> State# s -> (# State# s, Int#, Any a #) */ W_ stg_casIntArrayzh( gcptr arr, W_ ind, W_ old, W_ new ); /* MutableByteArray# s -> Int# -> Int# -> Int# -> State# s -> (# State# s, Int# #) */ }}} Fetch-and-add, on the other hand, only makes sense on a `MutableByteArray`: {{{ #!C W_ stg_fetchAddIntArrayzh( gcptr arr, W_ ind, W_ incr ); /* MutableByteArray# s -> Int# -> Int# -> State# s -> (# State# s, Int# #) */ }}} Some systems, such as gcc and LLVM, provide other variants, such as "fetch-and-multiply". However, these do not have direct support on x86 and are usually just simulated with CAS. For example, see the [http://llvm.org/docs/Atomics.html#atomics-and-codegen LLVM documentation here]. User-exposed Haskell libraries for atomic operations may employ the same approach using the CAS primOps above to simulate other fetch-and-X operations. Finally, a design question which bears thinking about is how to implement opaque "ticket" approach to CAS. The basic idea is that a user does NOT present a regular pointer-based data value (e.g. `Int`) to CAS as the "old" value. Rather, observations of prior values are kept in an opaque form (`Any` type) to prevent the compiler changing the pointer identity by, for example, unboxing and reboxing the value. The way this affects the **primOp** design is as follows. The current implementation of casMutVar# and casArray# returns the NEW value rather than the old one if the CAS is successful. The Haskell code that imports the primOps treats this new value as the opaque ticket. The user can in fact safely retrieve the real value from the `Any`-based "ticket" with a `peekTicket :: Ticket a -> a` operation. But [http://hackage.haskell.org/packages/archive/atomic-primops/0.4/doc/html /Data-Atomics.html#g:1 peekTicket] MUST [https://github.com/rrnewton /haskell-lockfree- queue/blob/880fb11de354d84f6c9a8ee06d5d4a887bd449a4/AtomicPrimops/Data/Atomics.hs#L114 be marked NOINLINE] to hide the `unsafeCoerce` operation inside it from compiler optimizations. Otherwise, the code path that carries the ticket from one CAS operation to the next is subject to optimization [1]. In particular, `unsafeCoerce` simply becomes a type-level operation, not a function call with the usual constraints on control and dataflow. Returning to the issue of primOp design, if we wished to avoid the somewhat non-standard design of returning the new value from CAS, we //could// allow users to create `Ticket` values themselves, rather retrieving them as the result of previous read and CAS IO operations. Yet this would entail an additional `NOINLINE` (unsafeCoerce) function call, and I believe it would be prone to error. Further, if you look at [https://github.com/ghc/ghc/blob/25ad01533aaaf1ccf69e1b7216e66de025b8131b/rt… the primOp implementation for stg_casMutVarzh], you will see that there is //already// a branch, which is necessary for updating GC-related meta-data. Thus there is no additional overhead to return the new rather than the old value from CAS operations in the successful case. Haskell-level CAS is already a compound operation, not merely a single machine code instruction. By contrast, the C intrinsic `__sync_val_compare_and_swap` can become only a single machine operation, and it returns the "old" value irrespective of whether the CAS succeeded or failed. In fact, an equality comparison on that old value is necessary to determine if the operation succeeded. In contrast, the Haskell CAS primOps above return an unboxed tuple with an explicit success bit. Thus returning the old value in the success case is completely redundant, and returning the new value instead allows us to acheive two goals (the CAS and the opacifying coercion) with one operation at no additional cost. [1] P.S. As a concrete example of what happens when `unsafeCoerce` is not hidden, consider the following code as a starting point: {{{ x = unsafeCoerce y z = f y }}} `x` would seem to have nothing to do with `f`, and yet later in the compiler, one can end up with Core like this: {{{ z = f x }}} This exposes the type information and activates optimizations, which was the source of [https://github.com/rrnewton/haskell-lockfree- queue/issues/5 one bug] with the `lockfree-queue` package that was fixed by adding NOINLINE to `peekTicket`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3