December 2018 - ghc-tickets

[GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found
by GHC 14 Feb '19

14 Feb '19

#9277: GHCi panic: Loading temp shared object failed: Symbol not found ----------------------------------+--------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9034, #8935 | ----------------------------------+--------------------------------- When given a Objective-C object file referencing a symbol available in a system framework, GHCi panics saying it can't find the symbol the object file relies on. {{{ $ cat >foo.m <<EOF #import <Foundation/Foundation.h> BOOL is_main_thread() { return [NSThread isMainThread]; } EOF }}} {{{ $ clang -c -o foo.o foo.m }}} {{{ $ ghci -v -framework Foundation foo.o GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3 Using binary package database: /opt/ghc-7.8.2/lib/ghc-7.8.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 --print-file-name libiconv.dylib Loading package base ... linking ... done. Loading object (static) foo.o ... Created temporary directory: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0 *** Linker: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -dynamiclib -o /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib foo.o -undefined dynamic_lookup -single_module -install_name '@rpath/ghc36377_1.dylib' -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -lHSbase-4.7.0.0-ghc7.8.2 -lHSinteger-gmp-0.5.1.0-ghc7.8.2 -lHSghc-prim-0.3.1.0-ghc7.8.2 -liconv *** Deleting temp files: Deleting: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib *** Deleting temp dirs: Deleting: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0 ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib, 9): Symbol not found: _OBJC_CLASS_$_NSThread Referenced from: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib Expected in: flat namespace in /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Note omitting `-framework Foundation` makes no difference to the output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9277> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything.
by GHC 14 Feb '19

14 Feb '19

#15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given simple code like {{{#!haskell {-# LANGUAGE RecordWildCards #-} module M (foo) where data D = D { d1 :: Int, d2 :: Int } foo :: D -> Int -> Int foo D{..} x = x + 5 }}} There is no way that I know of to get GHC to warn us that the {{{ D{..} }}} in {{{foo}}} is not binding anything at all. This is very common after refactoring (perhaps {{{foo}}} looked like {{{foo D{..} x = x + d1 + 5}}} before) and would be great to be able to get a warning about. Of course it's not _dead_ code as it still forces {{{D}}} to WHNF but if we're using {{{RecordWildCards}}} syntax then it's probably not what we were going for. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a)
by GHC 14 Feb '19

14 Feb '19

#15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes #-} {-# Language KindSignatures #-} {-# Language PolyKinds #-} import GHC.Exts newtype Foo rep = MkFoo (forall (a :: TYPE rep). a) }}} {{{ $ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot- ghci /tmp/U.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/U.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): isUnliftedType forall (a :: TYPE rep_a1AA[sk:0]). a :: TYPE rep_a1AA[sk:0] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:2332:10 in ghc:Type isUnliftedType, called at compiler/typecheck/TcTyClsDecls.hs:3055:25 in ghc:TcTyClsDecls Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13595: Should ‘coerce’ be levity polymorphic?
by GHC 14 Feb '19

14 Feb '19

#13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13592 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not able to write `coerce @Int# @Int#` or `coerce :: Double# -> Double#`, just checking to see if its intentional or not {{{ >>> :set -XTypeApplications >>> :set -XMagicHash >>> import Data.Coerce >>> import GHC.Exts >>>> :t coerce @Int coerce @Int :: Coercible b Int => Int -> b >>> :t coerce @Int# <interactive>:1:1: error: Couldn't match a lifted type with an unlifted type When matching types b :: * Int# :: TYPE 'IntRep <interactive>:1:9: error: • Expecting a lifted type, but ‘Int#’ is unlifted • In the type ‘Int#’ In the expression: coerce @Int# }}} This was needed for #13592. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15219: Implement UnliftedNewtypes proposal
by GHC 14 Feb '19

14 Feb '19

#15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple UnliftedNewtypes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The unlifted newtypes proposal is described here: https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0013-unlifted-newtypes.rst I am going to be working on it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #16051: Cross compilation broken under Hadrian
by GHC 12 Feb '19

12 Feb '19

#16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hadrian falls over essentially immediately when cross-compiling: {{{ $ ./boot $ ./configure --target=aarch64-linux-gnu $ hadrian/build.cabal.sh -j32 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16073: Hadrian build fails on Windows
by GHC 12 Feb '19

12 Feb '19

#16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See https://gitlab.haskell.org/ghc/ghc/-/jobs/2838. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16075: OPTIONS_GHC Ignored
by GHC 12 Feb '19

12 Feb '19

#16075: OPTIONS_GHC Ignored -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I enable `-Weverything`, some `OPTIONS_GHC` pragmas are respected, while others are ignored. For example, with `-Weverything`, this file {{{ main = print "hello" foo :: (Num a, Show a) => a -> IO () foo = print . show }}} generates warnings about: 1. missing an export list 2. top-level binding [main] with no type sig 3. redundant constraint [Num a] If I add `{-# OPTIONS_GHC -fno-warn-missing-signatures -fno-warn-missing- export-lists -fno-warn-redundant-constraints #-}` to the top of the file and recompile, I expect all warnings to go away. But GHC still reports that `main` has no signature. Note that this problem doesn't occur with `-Wall`. With `-Wall`, the code snippet warns about the missing signature on `main`, but when I add the `OPTIONS_GHC`, the warning goes away. Thus this problem appears to be unique to `Weverything`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed`
by GHC 11 Feb '19

11 Feb '19

#15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: base, | Operating System: Unknown/Multiple Data.Fixed | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello; I'm creating this email to propose a change to `Data.Fixed`. Full credit for this idea goes to Bhavik Mehta (@b-mehta on GitHub), who implemented it in this [https://github.com/dmcclean/exact-pi/pull/8 PR] for `exact- pi`. In `Data.Fixed` there are several `E`-prefixed datatypes used to represent a certain number of digits of precision in fixed-precision arithmetic. For example, `E1` has 1 decimal place, `E12` has 12. Each of them, `E{0,1,2,3,6,9,12}` is hardcoded. If more precision types are to be provided, they have to be hardcoded as well, and all of these types resemble each other. I think there is room for improvement here. Instead of having {{{#!hs data E0 instance HasResolution E0 where resolution _ = 1 }}} and repeating it as many times as there are `E` datatypes, I propose to add the following type: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} import GHC.TypeLits (Nat, KnownNat, natVal) data E (n :: Nat) }}} and then do {{{#!hs instance KnownNat n => HasResolution (E n) where resolution _ = 10^natVal (undefined :: E n) }}} just once, replacing `data E0` with `type E0 = E 0` (and the same for the rest of them) to continue reexporting these types. `E` should also be exported. I've sent an email to the Core Libraries Committee regarding this issue. This is my first contribution to GHC, if I'm doing something incorrectly please tell me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #16052: Core optimizations for memset on a small range
by GHC 11 Feb '19

11 Feb '19

#16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been doing some API bindings lately that require zeroing out memory before poking values into the appropriate places. Sometimes, these are small data structures. For instance, on linux, the internet socket struct `sockaddr_in` is 16 bytes. Here's an example (not involving `sockaddr_in`) of the kind of situation that arises: {{{ {-# language MagicHash #-} {-# language UnboxedTuples #-} module FillArray ( fill ) where import GHC.Exts import GHC.IO data ByteArray = ByteArray ByteArray# fill :: IO ByteArray fill = IO $ \s0 -> case newByteArray# 24# s0 of (# s1, m #) -> case setByteArray# m 0# 24# 0# s1 of s2 -> case writeWord8Array# m 4# 14## s2 of s3 -> case writeWord8Array# m 5# 15## s3 of s4 -> case unsafeFreezeByteArray# m s4 of (# s5, r #) -> (# s5, ByteArray r #) }}} This `fill` function allocates a 24-byte array, sets everything to zero, and then writes the numbers 14 and 15 to elements 4 and 5 respectively. With `-O2`, here's the relevant part of the core we get: {{{ fill1 fill1 = \ s0_a140 -> case newByteArray# 24# s0_a140 of { (# ipv_s16i, ipv1_s16j #) -> case setByteArray# ipv1_s16j 0# 24# 0# ipv_s16i of s2_a143 { __DEFAULT -> case writeWord8Array# ipv1_s16j 4# 14## s2_a143 of s3_a144 { __DEFAULT -> case writeWord8Array# ipv1_s16j 5# 15## s3_a144 of s4_a145 { __DEFAULT -> case unsafeFreezeByteArray# ipv1_s16j s4_a145 of { (# ipv2_s16p, ipv3_s16q #) -> (# ipv2_s16p, ByteArray ipv3_s16q #) } } } } } }}} And, here's the relevant assembly: {{{ fill1_info: _c1kL: addq $56,%r12 cmpq 856(%r13),%r12 ja _c1kP _c1kO: movq $stg_ARR_WORDS_info,-48(%r12) movq $24,-40(%r12) leaq -48(%r12),%rax subq $8,%rsp leaq 16(%rax),%rdi xorl %esi,%esi movl $24,%edx movq %rax,%rbx xorl %eax,%eax call memset addq $8,%rsp movb $14,20(%rbx) movb $15,21(%rbx) movq $ByteArray_con_info,-8(%r12) movq %rbx,(%r12) leaq -7(%r12),%rbx jmp *(%rbp) _c1kP: movq $56,904(%r13) movl $fill1_closure,%ebx jmp *-8(%r13) .size fill1_info, .-fill1_info }}} What a bummer that using `memset` for something as small setting three machine words (on a 64 bit platform) results in a `call` instruction getting generated. Why not simply generate three `movb` instructions for the zero initialization instead? Currently, users can work around this by translating their `setByteArray#` call to several `writeWordArray#` calls. This optimization obscures the meaning of written code and is not portable across architectures (so you have to use `CPP` to make it work on 32 bit and 64 bit). I'd like to add a cmm-to-assembly optimization to GHC that does unrolling instead so that the user can write more natural code. Specifically, here's what I'm thinking: * This only happens when the offset into the `ByteArray#` and the length of the range are constant that are multiples of the machine word size. So, `setByteArray# arr 8# 16# x` is eligible on 32-bit and 64-bit platforms. And `setByteArray# arr 4# 8# x` is eligible only on a 32-bit platform. And `setByteArray# arr 16# y x` is not eligible on any platform. * This only happens when the `call memset` instruction has a range of 32 bytes or less. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10