April 2014 - ghc-tickets

[GHC] #8982: Heap profile restricted by biography of GHC segfaults
by GHC 10 Apr '14

10 Apr '14

#8982: Heap profile restricted by biography of GHC segfaults ----------------------------------+---------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Steps to reproduce: 1. Build GHC with profiling on 64-bit Linux 2. Run T1969 with RTS options -hc -hbvoid {{{ [ezyang@hs01 compiler]$ '/home/hs01/ezyang/ghc-compalloc/inplace/bin/ghc- stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T1969.hs +RTS -V0 -tT1969.comp.stats --machine- readable -RTS -dcore-lint -static +RTS -hc -hbvoid Segmentation fault }}} Interestingly enough, I don't see the problem with other types of profiling, e.g. '-hd'. I tried a few simpler, nontrivial Haskell programs but I couldn't reproduce the segfault, so this is some sort of bug that only shows up in complex setting (maybe multithreading is the issue?) It reproduces quite reliably for me. When I build the runtime system with debugging, I get a useful assert failure: {{{ ghc-stage2: internal error: ASSERTION FAILED: file rts/ProfHeap.c, line 201 (GHC version 7.8.0.20140408 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This assert is complaining that the cost center (CCS_SYSTEM) never made it into the hash table for era 149. I'll try looking for a simpler test-case later, but maybe someone can figure out what this bug is by sight. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 10 Apr '14

10 Apr '14

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * cc: johan.tibell@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 10 Apr '14

10 Apr '14

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): FYI, Johan (@tibbe) is interested in this. Carter, have you started the implementation somewhere? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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

Re: [GHC] #7068: Extensive Memory usage (regression)
by GHC 10 Apr '14

10 Apr '14

#7068: Extensive Memory usage (regression) -------------------------------------------------+------------------------- Reporter: waldheinz | Owner: Type: bug | simonpj Priority: high | Status: new Component: Compiler | Milestone: 7.8.1 Resolution: | Version: 7.4.1 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time performance bug | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by gidyn): * cc: gideon@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7068#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 10 Apr '14

10 Apr '14

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------ Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8977 -------------------------------------+------------------------------------ Changes (by trommler): * version: 7.6.2 => 7.8.1 * os: Linux => Unknown/Multiple * related: => #8977 * milestone: 7.8.1 => 7.8.2 Comment: This was also reported on Solaris. See #8977. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8977: GHC infinite loop on Solaris
by GHC 10 Apr '14

10 Apr '14

#8977: GHC infinite loop on Solaris ------------------------------------+--------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Solaris Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Hello, sometimes on Solaris ghc gets into infinite loop while trying to print something. E.g. ghc --version or ghc --info are good examples. This also happens for example while trying to build another ghc by already installed ghc. The reason for loop is simple: ghc is using libiconv for printing and libiconv is using its own libraries/binary tables. The problem arise when libiconv is not able to find the appropriate library/table file, then it tries to print error message (or GHC itself) which results in calling libiconv for printing which goes to search for appropriate library/table file and loop is closed. Please note that library/table file is different for different LANG settings. That also means that if you are able to invoke ghc --version on command line, still your ./configure of a new ghc may stuck on checking ghc version since configure sets LANG=C while on command line you may have LANG=en_US.UTF-8. Running ghc --version in truss shows this issue nicely as: {{{ /1: munmap(0xFF210000, 8790) = 0 /1: access("/usr/lib/iconv/geniconvtbl/binarytables/646%UTF-32BE.bt", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/646%UTF-32BE.so", R_OK) Err#2 ENOENT /1: lwp_unpark(2) = 0 /2: lwp_park(0x00000000, 0) = 0 /2: clock_gettime(4, 0xFF0D9E68) = 0 /2: lwp_unpark(1) = 0 /1: lwp_park(0x00000000, 0) = 0 /1: access("/usr/lib/iconv/geniconvtbl/binarytables/646%UTF-32BE.bt", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/646%UTF-32BE.so", R_OK) Err#2 ENOENT /1: open("/usr/lib/iconv/alias", O_RDONLY) = 7 /1: fstat64(7, 0xFFBFD388) = 0 /1: fstat64(7, 0xFFBFD5C8) = 0 /1: mmap(0x00000000, 8790, PROT_READ, MAP_SHARED, 7, 0) = 0xFF210000 /1: close(7) = 0 /1: munmap(0xFF210000, 8790) = 0 /1: access("/usr/lib/iconv/geniconvtbl/binarytables/646%UTF-32BE.bt", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/646%UTF-32BE.so", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/geniconvtbl/binarytables/646%UTF-32BE.bt", R_OK) Err#2 ENOENT /1: access("/usr/lib/iconv/646%UTF-32BE.so", R_OK) Err#2 ENOENT /1: open("/usr/lib/iconv/alias", O_RDONLY) = 7 /1: fstat64(7, 0xFFBFD388) = 0 /1: fstat64(7, 0xFFBFD5C8) = 0 }}} So, the solution on Solaris is simple. Install appropriate libiconv files. Usually if you are hit by this issue, then at least on Solaris 11 you are missing unicode-core package and this may be installed by: {{{ # pkg install unicode-core }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8977> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8979: matching type function application with type synonym application
by GHC 10 Apr '14

10 Apr '14

#8979: matching type function application with type synonym application -------------------------------------------+------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- When compiling this module: {{{ {-# LANGUAGE TypeFamilies #-} type family F a type family G a type H a = G a newtype T0 a = Cons0 (F (G a)) newtype T1 a = Cons1 (F (H a)) f :: T0 Char -> T1 Char f (Cons0 a) = Cons1 a }}} I get the type error {{{ MatchTypeFunction.hs:12:21: Couldn't match expected type ‘F (H Char)’ with actual type ‘F (G Char)’ NB: ‘F’ is a type function, and may not be injective In the first argument of ‘Cons1’, namely ‘a’ In the expression: Cons1 a }}} The code works with GHC-7.8 RC2 and GHC-7.4.2, but no longer with GHC-7.8.1. I guess there was some change in how deep GHC resolves type function application and type synonyms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8979> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8958: Allow role inference on datatype contexts
by GHC 10 Apr '14

10 Apr '14

#8958: Allow role inference on datatype contexts ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, role inference on a datatype examines the use of a type parameter in all constructors of that datatype. This, of course, includes any constraint contexts on these datatypes. But, the (stupid) datatype context is not consulted, as there is no need to do so for type safety. However, by examining the datatype context, we can create a lightweight way of annotating roles, like this: {{{ class Nominal a instance Nominal a type role Nominal nominal -- this is redundant, but here for completeness class Representational a instance Representational a type role Representational representational -- this requires -XIncoherentInstances class Phantom a -- any use of this class is redundant, but here for completeness instance Phantom a type role Phantom phantom data (Nominal k, Representational v) => Map k v = ... }}} Because of the universal instances, these constraints never get in the way. This is admittedly an abuse of existing constructs, but it seems so useful that it's worth a little abuse. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8982: Add Pertness to Your Rear With Buttlifter Slimming
by GHC 10 Apr '14

10 Apr '14

#8982: Add Pertness to Your Rear With Buttlifter Slimming -------------------------------------+------------------------------------- Reporter: scydv1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (FFI) | Version: 6.5 Keywords: | Operating System: Irix Architecture: m68k | Type of failure: Installing GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- One of the most common "difficulty areas" we women surface is that dreaded lower intumesce jut or a not-as-toned-as-we'd equivalent face. This capital that act skirts and dresses, peculiarly those that are especially formfitting, are not the most pleasant or sureness boosting have. These garments incline to swing work to those difficulty areas, and too many times, the cutest dresses and skirts are the ones that pretense off that dimpled bum or swell imperfections the most. But before you depart yourself to a sentence without the latest fashions or those artful short drawing, learn out the capability of slimming nightwear on move. [http://try100puregarciniacambogia.com/ 100 Pure Garcinia Cambogia] You can flatten and deposition and give your stooge a actuation a slimming result, rule in unclaimed fat, and make a ingratiatory silhouette - are an surprising conception for us women who aren't perfect but would equal to be able to accentuate what we bang, and reduce from what we'd kinda not nidus on. With slimming nightwear, those formfitting skirts and dresses are no yearner an unattainable envisage. These undergarments are designed to be imperceptible - so nobody leave live you fuck a bit of service - but firmly regard in that tumefy fat, employ your laughingstock that good make, and pee those bed you a Brazilian goat rise, but without the expense. This implementation that you can assume that artful pencil touch or hot garb, and time wearing one of these undergarments you faculty not score throwaway bulges, dimples, or hump handles on pass, upright a unsubdivided, upturned, slimmed downward body regulate that is to die for. Now you can bear your skirts and dresses with certainty, and also be trusty that you can get the perfect undergarment for whatsoever you are act. Buttlifter Process undergarment oft comes in nasal wave forms, boy pants, or something a bit writer kindred to cycling trunks. This way that whether your skirt or fix is tangency or oblong, you can pronounce a unify that does what you condition, and fits with assist. Unlike word fabrication undergarments of the bypast, you can now incessant motion or bulging of these undergarments and you leave never feature to anxiety near anyone lettered you are act them. '''100 Pure Garcinia Cambogia''' Help your confidence and increase your make horizons with these buttlifter, tum flattening, and constructive undergarments. Don't be agoraphobic to don that clenched less sarcastic position on your incoming night out on the municipality with friends, and don't be hydrophobic of all day suffering as a outcome of act these undergarments for interminable periods of example. They are rich, employ incredibly shaft, are surprisingly cheap, and they present excrete http://try100puregarciniacambogia.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0