April 2014 - ghc-tickets

Re: [GHC] #2528: documentation for nub and nubBy should be corrected, extended or removed.
by GHC 25 Apr '14

25 Apr '14

#2528: documentation for nub and nubBy should be corrected, extended or removed. -----------------------------------+------------------------------------ Reporter: jdressel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by ekmett): * cc: ekmett@…, hvr, ekmett (added) Comment: Jeremy, Reflexivity is violated in base by the instances for `Float`/`Double`, by the behavior around NaN so that law falls apart quickly. `Eq` is also not structural (as demonstrated by `-0` and `0` being `(==)` in `Float`/`Double`), though you didn't offer that one. `Ord` for those is a bit like a funhouse playground. ;) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2528#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 25 Apr '14

25 Apr '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): Not sure what you mean. (1) Short example, we just need the types: {{{ context :: a1 ~ a2 => a1 -> a2 context = undefined }}} We should see {{{context :: (~) a1 a2 => a1 -> a2}}} without {{{ -fprint-explicit-kinds }}} but we see {{{context :: (~) * a1 a2 => a1 -> a2}}} as if {{{ -print-explicit-kinds }}} is on. This is because I don't know yet how to suppres kinds from the {{{IfaceTyConApp}}} tys. Same with: {{{ data A x y fun :: A x y -> a fun = undefined }}} where {{{:info}}} shows {{{fun :: A k1 k2 x y -> a}}} (2) {{{ data STest = P !Int | Q {-# UNPACK #-} !Int | R {-# NOUNPACK #-} !Int }}} We see only {{{ IfStrict }}} comming out, so when doing :info we get {{{ data STest = P !Int | Q !Int | R !Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 25 Apr '14

25 Apr '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): Can you give example tests to demonstrate the issues in (1) and (2)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 25 Apr '14

25 Apr '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): I have implemented what we discussed ,{{{IfaceTyConParent}}} , the new constructor {{{IfaceDFunTy}}} to {{{IfaceType}}} and printing of extra information when using {{{-dppr-debug}}}. I have submitted a patch for review and also so that we can have something to discuss on. The patch has no tests or new comments yet, it is just work in progress. Every thing works as expected except: 1. I don't really know how to suppress kinds on {{{IfaceTyConApp}}} , when printing {{{TyConApp}}} from {{{TyThing}}} the {{{TyCon}}} is passed along but I don't know what to do in this case. Ex. Something like {{{(~) a a1}}} would actually print {{{(~) * a a1}}} 2. Although I thought I could solve this, strictness annotations are printed as decided not as typed by the user. These are the problems I'm stuck on right now, I just need to clear my head and I'll probably come with solutions, but I can always use some guidance and feedback. Andrei -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8741: `System.Directory.getPermissions` fails on read-only filesystem
by GHC 24 Apr '14

24 Apr '14

#8741: `System.Directory.getPermissions` fails on read-only filesystem -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: Component: | Version: 7.6.3 libraries/directory | Operating System: POSIX Keywords: | Type of failure: Incorrect result Architecture: Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Alain O'Dea reports in an [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078 email] that: {{{ Prelude> System.Directory.getPermissions "/usr/bin/ld" *** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system) }}} > That seems wrong. > > An `access(*, W_OK)` syscall by design should return `EROFS` on a read- only file system by specification. > > This breaks Cabal on SmartOS since `/usr` is read-only by design and Cabal calls `getPermissions "/usr/bin/ld"`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #5578: write access permission of binary result different on OpenBSD
by GHC 24 Apr '14

24 Apr '14

#5578: write access permission of binary result different on OpenBSD --------------------------------------+--------------------------- Reporter: ivdsangen | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Test Suite | Version: 7.2.1 Resolution: duplicate | Keywords: Operating System: OpenBSD | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: getPermissions001 | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------- Changes (by AlainODea): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Duplicate of #8741 which is fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5578#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8965: bootstrapping failure on Linux/ppc64el
by GHC 24 Apr '14

24 Apr '14

#8965: bootstrapping failure on Linux/ppc64el -----------------------------+-------------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: GHC doesn't work at all Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+-------------------------------------------- A few distributions, including Ubuntu which I work on, have a new little- endian Linux ppc64 port (known variously as ppc64el, ppc64le, powerpc64le, etc.). As well as the obvious endianness difference, this varies from traditional ppc64 in that it uses a new version of the ELF ABI. https://bugs.openjdk.java.net/browse/JDK-8035647 has a useful set of links explaining the changes. I've been trying to bootstrap GHC on this architecture, but I've been running into failures, which I explained here along with my procedure: https://lists.ubuntu.com/archives/ubuntu-devel- discuss/2014-April/014922.html Things that I believe I have ruled out so far: * It's not libffi. In the above procedure I was missing unpacking libffi6:ppc64el in the sysroot and configuring using `--with-system- libffi` (our libffi is newer), but that makes no difference; furthermore, breakpoints set on all exposed `ffi_*` symbols and on `createAdjustor` never fire. * It's not signal handling. I replaced unlit with a shell script that sleeps 5 and then execs the real unlit, and ghc-stage2 segfaulted before it returned; strace shows that SIGSEGV is the first signal received. * It's not buggy native code generation. Although getting an NCG up on this platform might be tractable later, for now I added a `powerpc64le*) $2="powerpc64le" ;;` case before `powerpc64*` to `GHC_CONVERT_CPU` and added powerpc64le to the `ArchUnknown` list in `FPTOOLS_SET_HASKELL_PLATFORM_VARS`. Everything should be going via GCC. * I don't think I'm taking a fundamentally wrong bootstrapping approach; I'm using the exact same procedure and in fact I started from the exact same git tree that I just used to successfully bootstrap GHC on arm64. Here's a gdb trace showing the location of the segfault: {{{ *** Literate pre-processor: ../inplace/lib/unlit -h HelloWorld.lhs HelloWorld.lhs /tmp/ghc6597_0/ghc6597_1.lpp Breakpoint 1, 0x000000001507daac in runInteractiveProcess () (gdb) bt #0 0x000000001507daac in runInteractiveProcess () #1 0x000000001507d968 in c8z6_entry () #2 0x00003fffb7804a20 in ?? () Cannot access memory at address 0xf (gdb) finish Run till exit from #0 0x000000001507daac in runInteractiveProcess () 0x000000001507d968 in c8z6_entry () (gdb) stepi 0x000000001507d96c in c8z6_entry () (gdb) 0x000000001507d970 in c8z6_entry () (gdb) 0x000000001507d974 in c8z6_entry () (gdb) 0x000000001507d978 in c8z6_entry () (gdb) 0x000000001507d97c in c8z6_entry () (gdb) 0x000000001507d980 in c8z6_entry () (gdb) 0x000000001507d984 in c8z6_entry () (gdb) 0x000000001507d988 in c8z6_entry () (gdb) 0x000000001507d98c in c8z6_entry () (gdb) 0x000000001507d990 in c8z6_entry () (gdb) 0x000000001507d994 in c8z6_entry () (gdb) 0x000000001507d998 in c8z6_entry () (gdb) 0x000000001507d99c in c8z6_entry () (gdb) 0x000000001507d9a0 in c8z6_entry () (gdb) 0x000000001507d9a4 in c8z6_entry () (gdb) 0x000000001507d9a8 in c8z6_entry () (gdb) 0x000000001507d9ac in c8z6_entry () (gdb) 0x000000001507d9b0 in c8z6_entry () (gdb) 0x000000001507d9e8 in c8z6_entry () (gdb) Cannot access memory at address 0xf (gdb) disas /rm Dump of assembler code for function c8z6_entry: 0x000000001507d8ec <+0>: 6f 16 40 3c lis r2,5743 0x000000001507d8f0 <+4>: 20 9c 42 38 addi r2,r2,-25568 0x000000001507d8f4 <+8>: a6 02 08 7c mflr r0 0x000000001507d8f8 <+12>: 10 00 01 f8 std r0,16(r1) 0x000000001507d8fc <+16>: c1 ff 21 f8 stdu r1,-64(r1) 0x000000001507d900 <+20>: 00 00 00 60 nop 0x000000001507d904 <+24>: 60 92 22 39 addi r9,r2,-28064 0x000000001507d908 <+28>: 68 03 49 e9 ld r10,872(r9) 0x000000001507d90c <+32>: 10 00 4a 39 addi r10,r10,16 0x000000001507d910 <+36>: 68 03 49 f9 std r10,872(r9) 0x000000001507d914 <+40>: 58 03 69 e9 ld r11,856(r9) 0x000000001507d918 <+44>: 08 00 0b e8 ld r0,8(r11) 0x000000001507d91c <+48>: 70 03 29 e9 ld r9,880(r9) 0x000000001507d920 <+52>: 40 48 aa 7f cmpld cr7,r10,r9 0x000000001507d924 <+56>: 90 00 9d 41 bgt cr7,0x1507d9b4 <c8z6_entry+200> 0x000000001507d928 <+60>: 40 00 6b e8 ld r3,64(r11) 0x000000001507d92c <+64>: 38 00 8b e8 ld r4,56(r11) 0x000000001507d930 <+68>: 48 00 ab e8 ld r5,72(r11) 0x000000001507d934 <+72>: 50 00 cb e8 ld r6,80(r11) 0x000000001507d938 <+76>: 58 00 eb e8 ld r7,88(r11) 0x000000001507d93c <+80>: 10 00 0b e9 ld r8,16(r11) 0x000000001507d940 <+84>: 30 00 2b e9 ld r9,48(r11) 0x000000001507d944 <+88>: 28 00 4b e9 ld r10,40(r11) 0x000000001507d948 <+92>: 20 00 8b e9 ld r12,32(r11) 0x000000001507d94c <+96>: 20 00 81 f9 std r12,32(r1) 0x000000001507d950 <+100>: 00 00 8b e9 ld r12,0(r11) 0x000000001507d954 <+104>: 28 00 81 f9 std r12,40(r1) 0x000000001507d958 <+108>: 30 00 01 f8 std r0,48(r1) 0x000000001507d95c <+112>: 18 00 6b e9 ld r11,24(r11) 0x000000001507d960 <+116>: 38 00 61 f9 std r11,56(r1) 0x000000001507d964 <+120>: 19 01 00 48 bl 0x1507da7c <runInteractiveProcess+8> 0x000000001507d968 <+124>: 00 00 00 60 nop 0x000000001507d96c <+128>: 00 00 00 60 nop 0x000000001507d970 <+132>: 60 92 22 39 addi r9,r2,-28064 0x000000001507d974 <+136>: 68 03 49 e9 ld r10,872(r9) 0x000000001507d978 <+140>: f6 ff e2 3c addis r7,r2,-10 0x000000001507d97c <+144>: 30 17 07 39 addi r8,r7,5936 0x000000001507d980 <+148>: f8 ff 0a f9 std r8,-8(r10) 0x000000001507d984 <+152>: 68 03 49 e9 ld r10,872(r9) 0x000000001507d988 <+156>: b4 07 63 7c extsw r3,r3 0x000000001507d98c <+160>: 00 00 6a f8 std r3,0(r10) 0x000000001507d990 <+164>: 68 03 49 e9 ld r10,872(r9) 0x000000001507d994 <+168>: f9 ff 4a 39 addi r10,r10,-7 0x000000001507d998 <+172>: 18 00 49 f9 std r10,24(r9) 0x000000001507d99c <+176>: 58 03 49 e9 ld r10,856(r9) 0x000000001507d9a0 <+180>: 60 00 0a 39 addi r8,r10,96 0x000000001507d9a4 <+184>: 58 03 09 f9 std r8,856(r9) 0x000000001507d9a8 <+188>: 60 00 2a e9 ld r9,96(r10) 0x000000001507d9ac <+192>: 00 00 69 e8 ld r3,0(r9) 0x000000001507d9b0 <+196>: 38 00 00 48 b 0x1507d9e8 <c8z6_entry+252> 0x000000001507d9b4 <+200>: 00 00 00 60 nop 0x000000001507d9b8 <+204>: 60 92 22 39 addi r9,r2,-28064 0x000000001507d9bc <+208>: 10 00 40 39 li r10,16 0x000000001507d9c0 <+212>: a0 03 49 f9 std r10,928(r9) 0x000000001507d9c4 <+216>: da ff 42 3d addis r10,r2,-38 0x000000001507d9c8 <+220>: 38 36 4a 39 addi r10,r10,13880 0x000000001507d9cc <+224>: f8 ff 4b f9 std r10,-8(r11) 0x000000001507d9d0 <+228>: 18 00 09 f8 std r0,24(r9) 0x000000001507d9d4 <+232>: 58 03 49 e9 ld r10,856(r9) 0x000000001507d9d8 <+236>: f8 ff 4a 39 addi r10,r10,-8 0x000000001507d9dc <+240>: 58 03 49 f9 std r10,856(r9) 0x000000001507d9e0 <+244>: 3b ff e2 3c addis r7,r2,-197 0x000000001507d9e4 <+248>: 60 c0 67 38 addi r3,r7,-16288 0x000000001507d9e8 <+252>: 40 00 21 38 addi r1,r1,64 => 0x000000001507d9ec <+256>: 10 00 01 e8 ld r0,16(r1) ---Type <return> to continue, or q <return> to quit--- 0x000000001507d9f0 <+260>: a6 03 08 7c mtlr r0 0x000000001507d9f4 <+264>: 20 00 80 4e blr 0x000000001507d9f8 <+268>: 00 00 00 00 .long 0x0 0x000000001507d9fc <+272>: 00 00 00 01 .long 0x1000000 0x000000001507da00 <+276>: 80 00 00 00 .long 0x80 End of assembler dump. (gdb) }}} Let me know what else I could try. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8965> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9030: An async exception handler that blocks throwTo until handler finishes running
by GHC 24 Apr '14

24 Apr '14

#9030: An async exception handler that blocks throwTo until handler finishes running ------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | ------------------------------------+------------------------------------- I'd like to be able to handle an async exception in thread `A` such that if another thread `B` calls `throwTo`, that call blocks until my handler in `A` has a chance to ''finish''. Currently `throwTo` only blocks until the exception is "received" (which I don't understand precisely). My application is a concurrent FIFO queue library, in which a blocked reader must perform a cleanup action on async exceptions, else the next write will be lost: {{{ testBlockedRecovery = do c <- newChan started <- newEmptyMVar rid <- forkIO (putMVar started () >> readChan c) takeMVar started >> threadDelay 1000 throwTo rid ThreadKilled -- we race the exception-handler in `readChan` here... writeChan c () -- If this write won, then the write was lost and we block indefinitely below: readChan c putStrLn "OK" }}} If in my library I could catch the exception in such a way that `throwTo` blocked until I could handle it, then the test above would pass and the behavior of my Chan would match the standard library. This might seem like a lame example, but I think this functionality would be very generally useful. It would let you recover to a state using an exception handler such that you can reason in terms of linearizability about the pre- and post- exception states; I assume that's sort of the thinking behind making `throwTo` synchronous in the first place. Thanks and please let me know if there's actually a way to do what I'm asking currently, or if any of that wasn't clear. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5630: External Core needs love
by GHC 22 Apr '14

22 Apr '14

#5630: External Core needs love ---------------------------------------+----------------------------------- Reporter: quux | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by kosmikus): * cc: mail@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5630#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9019: Ambiguity checker overeager on "ambiguous" kind variables
by GHC 22 Apr '14

22 Apr '14

#9019: Ambiguity checker overeager on "ambiguous" kind variables ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | ------------------------------------+------------------------------------- Consider the following shenanigans: {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies, ExistentialQuantification #-} module Bug where import Data.Proxy data TyFun :: * -> * -> * type family Apply (f :: TyFun k1 k2 -> *) (x :: k1) :: k2 data LeftSym0 l = forall arg. Apply LeftSym0 arg ~ Left arg => LS0KI (Proxy arg) }}} Compiling (with `-fprint-explicit-foralls -fprint-explicit-kinds`) gives this error message: {{{ /Users/rae/temp/Bug.hs:12:3: Could not deduce ((~) (Either k3 k0) (Apply (Either k3 k0) k3 (LeftSym0 k0 k3) arg) ('Left k3 k0 arg)) from the context ((~) (Either k3 k2) (Apply (Either k3 k2) k3 (LeftSym0 k2 k3) arg) ('Left k3 k2 arg)) bound by the type of the constructor ‘LS0KI’: (~) (Either k3 k2) (Apply (Either k3 k2) k3 (LeftSym0 k2 k3) arg) ('Left k3 k2 arg) => Proxy k3 arg -> LeftSym0 k k1 l at /Users/rae/temp/Bug.hs:12:3 The type variable ‘k0’ is ambiguous In the ambiguity check for: forall (k :: BOX) (k1 :: BOX) (l :: TyFun k1 (Either k1 k)) (k2 :: BOX) (k3 :: BOX) (arg :: k3). (~) (Either k3 k2) (Apply (Either k3 k2) k3 (LeftSym0 k2 k3) arg) ('Left k3 k2 arg) => Proxy k3 arg -> LeftSym0 k k1 l To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the definition of data constructor ‘LS0KI’ In the data declaration for ‘LeftSym0’ }}} The file compiles without incident with `-XAllowAmbiguousTypes`. What's interesting is that, then, the following separate module compiles: {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeFamilies #-} module B2 where import Bug import Data.Proxy type instance Apply LeftSym0 x = Left x foo = LS0KI Proxy }}} It seems that `LS0KI`'s type was not so ambiguous after all. I would want to reduce the test case, but it's hard to figure out what GHC is thinking here, as it reports an ambiguous `k0` variable, which does not appear in the type it is examining. A few rather naive attempts to reduce failed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2