December 2013 - ghc-tickets

[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 10 Apr '14

10 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

[GHC] #8378: Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkGmpConstants workaround fails to build objects for integer-gmp
by GHC 24 Mar '14

24 Mar '14

#8378: Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkGmpConstants workaround fails to build objects for integer-gmp -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: solaris,integer- | Operating System: Unknown/Multiple gmp | Type of failure: Building GHC Architecture: Unknown/Multiple | failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8373,8366,8361 | -------------------------------------+------------------------------------- Here is the script I used to get build dependencies: {{{ sudo apt-get update sudo apt-get install --assume-yes ghc libncurses5-dev \ mesa-common-dev freeglut3-dev libedit-dev cabal install happy alex haddock }}} Here is the build bootstrap script I am using on a clean Ubuntu 13.04 install: {{{ #!/bin/bash export TARGET=x86_64-sun-solaris2.11 export PREFIX=$HOME/Documents/gcc/cross/$TARGET export SYSROOT=$PREFIX/sysroot export PATH=$PATH:$PREFIX/bin export GCC=$PREFIX/bin/$TARGET-gcc export LD=$PREFIX/bin/$TARGET-ld export NM=$PREFIX/bin/$TARGET-nm export OBJDUMP=$PREFIX/bin/$TARGET-objdump git clone git://github.com/ghc/ghc pushd ghc echo "Stage1Only = YES" >> mk/build.mk cp mk/build.mk{.sample,} ./sync-all --no-dph get perl boot patch -d libraries/haskeline/ -p1 < \ ../ghc-patches/0001-Include-termios.h-for- solaris2-host.-Fixes-8366.patch cp $SYSROOT/opt/local/include/gmp.h libraries/integer-gmp/gmp/ ./configure \ --host=x86_64-unknown-linux-gnu \ --build=x86_64-unknown-linux-gnu \ --target=x86_64-sun-solaris2 \ --with-gcc=$GCC \ --with-ld=$LD \ --with-nm=$NM \ --with-objdump=$OBJDUMP make # will fail with failure to run mkGmpDerivedConstants scp inplace/lib/bin/mkGmpDerivedConstants root@ns2:. ssh root@ns2 "./mkGmpDerivedConstants" > \ libraries/integer-gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h make cat << __EOF__ >> libraries/base/include/HsBaseConfig.h #define HTYPE_DOUBLE Double #define HTYPE_FLOAT Float __EOF__ make #make -j $(nproc) popd }}} The log of the run is attached. It is too large for the ticket body and apparently too large for Gist as well. Somewhere along the way the build forgets integer-gmp and no objects are built for it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8351: Arrays are always allocated out-of-line
by GHC 23 Mar '14

23 Mar '14

#8351: Arrays are always allocated out-of-line ------------------------------------+------------------------------------- Reporter: tibbe | 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: | ------------------------------------+------------------------------------- unordered-containers uses lots of small arrays (length <= 16). These arrays are always allocated out-of-line by a call to `allocate`. I suspect this is bad for performance. We should look into supporting inline- allocation, perhaps by using a new `newSmallArray#` primop and/or by spotting calls to `newArray#` with a small, statically-known size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8600: ghc --help is outdated
by GHC 22 Mar '14

22 Mar '14

#8600: ghc --help is outdated ------------------------------------+------------------------------------- Reporter: Feuerbach | 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: | ------------------------------------+------------------------------------- {{{ To compile and link a complete Haskell program, run the compiler like so: ghc --make Main where the module Main is in a file named Main.hs (or Main.lhs) in the current directory. The other modules in the program will be located and compiled automatically, and the linked program will be placed in the file `a.out' (or `Main.exe' on Windows). }}} First, --make is no longer necessary. Second, ghc doesn't create a.out on Unix — instead, the file is named the same as the main module (Main in that example). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools)
by GHC 17 Mar '14

17 Mar '14

#8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools) ----------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I got the following panics when I ran the GHC test suite per ticket #8148 (using xcode 5 CLI dev preview tools released as of august 21st on OS X 10.8) =====> ghcilink003(normal) 889 of 3736 [8, 195, 0] cd ./ghci/linking && $MAKE -s --no-print-directory ghcilink003 </dev/null >ghcilink003.run.stdout 2>ghcilink003.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> EnumFromToP(normal) 564 of 3736 [0, 82, 0] cd ./dph/enumfromto && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c EnumFromToP.hs -O -fno-enable-rewrite-rules -package dph-lifted-vseg >EnumFromToP.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-22 16:09:56.000000000 -0400 +++ ./dph/enumfromto/EnumFromToP.comp.stderr 2013-08-22 16:11:18.000000000 -0400 @@ -0,0 +1,6 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20130822 for x86_64-apple-darwin): + DsMonad: uninitialised ds_parr_bi + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> jmp_tbl(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c jmp_tbl.hs -O -fasm -fPIC -O >jmp_tbl.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(hpc) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fhpc -hpcdir .hpc.T7574 -no- hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fasm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(normal) 102 of 3736 [0, 2, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8124: Possible leaks when using foreign export.
by GHC 17 Mar '14

17 Mar '14

#8124: Possible leaks when using foreign export. ------------------------------+-------------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.6.3 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- When a Haskell function exported with foreign export is called from outside Haskell a new Task may be allocated for it. There will be one Task allocated for each OS thread calling into Haskell (this happens in rts_lock()). This Task is, by design, never deallocated. This works fine with a small number of threads, but if the external caller generates a lot of threads that die the Haskell RTS will just get more and more Task objects that are never freed. The Task also contains a condition variable and a mutex, which incurs a HANDLE leak on Windows. I don't see an elegant fix to this, but the attached code remembers the OS thread for "incall" Task, and every so often (every 100 Tasks created) if will scan the Tasks looking for ones where the OS thread is dead, and remove these. The fix only works on Windows, I'm afraid. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8254: confusing comment on allocate()
by GHC 27 Feb '14

27 Feb '14

#8254: confusing comment on allocate() ------------------------------------+-------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- {{{ /* ----------------------------------------------------------------------------- allocate() This allocates memory in the current thread - it is intended for use primarily from STG-land where we have a Capability. It is better than allocate() because it doesn't require taking the sm_mutex lock in the common case. Memory is allocated directly from the nursery if possible (but not from the current nursery block, so as not to interfere with Hp/HpLim). -------------------------------------------------------------------------- */ }}} Not sure what, if anything, `allocate()` is better than, but it's not `allocate()`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8254> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8512: Add flag like '-xc' that only reports uncaught exceptions
by GHC 21 Feb '14

21 Feb '14

#8512: Add flag like '-xc' that only reports uncaught exceptions ------------------------------------+------------------------------------- Reporter: blitzcode | Owner: simonmar Type: feature request | 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: | ------------------------------------+------------------------------------- The -xc RTS flag reports the stack trace of all exceptions. This can be very noisy when, for instance, certain http or parsing libraries are used that throw many exceptions, often handled fully internal, during their normal operation. Having multiple threads makes it even noisier. I'd think having a flag like -xc that only reports uncaught exceptions would be useful. It seems the GHCi debugger has a flag to only stop on uncaught exceptions, maybe this could be made available as an RTS option? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8512> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2