August 2016 - ghc-tickets

[GHC] #11571: Need more intelligent conditionalization of libgcc rts symbols for x32
by GHC 05 Nov '16

05 Nov '16

#11571: Need more intelligent conditionalization of libgcc rts symbols for x32 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `rts/RtsSymbols.c` we have {{{ // 64-bit support functions in libgcc.a #if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32) #define RTS_LIBGCC_SYMBOLS \ SymI_NeedsProto(__divdi3) \ SymI_NeedsProto(__udivdi3) \ ... }}} The purpose is to provide these symbols to `.o` files that use these symbols, expecting to be linked against libgcc. These symbols are for things like 64-bit integer division that aren't available as machine instructions on some platforms. But the `#if` is wrong on x32, which, despite having `sizeof(void *) == 4`, naturally has a full complement of 64-bit arithmetic instructions, since its registers are 64 bits wide. So libgcc does not provide these symbols, and as a result we eventually encounter missing symbol errors when linking the rts. Some possible solutions include * Figure out if there is a CPP variable set for x32 and don't include these symbols if that variable is set. I'm not sure whether `__ILP32__` is such a variable (after all x86 is also an architecture on which int, long and pointers are 32-bits). * Use autoconf to detect the presence of these symbols in libgcc. (Probably just pick one, like `__divdi3`, and hope they are all present or all missing.) * Use weak symbols somehow to add these symbols to the RTS's internal symbol table if and only if the RTS was linked against a libgcc that provides these symbols. My Android ghci also needs lots more of these, including `__modsi3`, `__umodsi3`, `__ctzdi2`, a bunch of `__aeabi_*` and `__sync_*`, and `__sF` (no idea what that is). So I'm inclined towards the last option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12539: Possible typo causes Stack and Cabal installs to fail
by GHC 04 Nov '16

04 Nov '16

#12539: Possible typo causes Stack and Cabal installs to fail -------------------------------------+------------------------------------- Reporter: ConorIA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I have been trying to use https://github.com/thriqon/pandoc-docker or to add pandoc to https://github.com/mitchty/alpine-ghc. However, in both cases, install commands are running into an issue with the '-nopie' flag passed to GCC. The gist of the error thrown when using wither Cabal or Stack is: {{{ <no location info>: Warning: Couldn't figure out linker information! Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc. gcc: error: unrecognized command line option '-nopie'; did you mean '-no- pie'? ) }}} I am not sure where the error is, as I am really a non-expert. But the gcc linking option is "-no-pie", so if there is indeed an option "-nopie" being passed, it seems like it is a typo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9010: TemplateHaskell leads to an "unknown symbol" error
by GHC 04 Nov '16

04 Nov '16

#9010: TemplateHaskell leads to an "unknown symbol" error ------------------------------------+------------------------------------- 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: | ------------------------------------+------------------------------------- Code: {{{ {-# LANGUAGE TemplateHaskell #-} module M where import System.Console.Editline import Data.Lens.Template data S = S { _a :: EditLine } makeLens ''S }}} When compiled with `ghc link.hs`, everything is fine; {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package tagged-0.7.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-compat-0.1.1.1 ... linking ... done. Loading package contravariant-0.4.4 ... linking ... done. Loading package distributive-0.4.3.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package comonad-4.0.1 ... linking ... done. Loading package semigroupoids-4.0.1 ... linking ... done. Loading package data-lens-2.10.4 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package data-lens-template-2.1.8 ... linking ... done. }}} However, when compiling with `ghc -package-id editline-0.2.1.1-ef91ae78e7ea1b9142c2fb0b84e85c11 link.hs`, I get {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package editline-0.2.1.1 ... linking ... ghc: /home/feuerbach/work /.cabal-sandbox/lib/i386-linux- ghc-7.6.3/editline-0.2.1.1/HSeditline-0.2.1.1.o: unknown symbol `el_reset' ghc: unable to load package `editline-0.2.1.1' }}} This is a problem because that's how cabal invokes ghc. This looks similar to #4899, except there's nothing "non-standard" here (no profiling or dynamic linking). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code
by GHC 02 Nov '16

02 Nov '16

#11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Data.Aeson.TH data Record = Record { type_ :: Int } $(deriveJSON defaultOptions{ fieldLabelModifier = \x -> case x of "type_" -> "type" _ -> x } ''Record) }}} gives {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): tcMonoExpr _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10221: LLVM does not work on OSX
by GHC 31 Oct '16

31 Oct '16

#10221: LLVM does not work on OSX -------------------------------------------+---------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+---------------------------- I can't seem to be able to use the LLVM backend on OSX. I get the error: {{{ error: unknown directive .macosx_version_min 10, 0 ^ <no location info>: Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) <no location info>: ghc: phase `Clang (Assembler)' failed (exitcode = 1) }}} This is on GHC 7.10.1 {{{ % clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix yongqli@auxiliary ~/secrets/projects/stocvol % opt --version LLVM (http://llvm.org/) LLVM version 3.5.1 Optimized build with assertions. Built Jan 15 2015 (18:24:46). Default target: x86_64-apple-darwin14.1.0 Host CPU: core-avx2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12536: Clarify commentary surrounding unboxed tuples and kind invariant
by GHC 28 Oct '16

28 Oct '16

#12536: Clarify commentary surrounding unboxed tuples and kind invariant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ticket:12115#comment:8 notes that there are a few inconsistencies in the comments describing these areas. Simon, could you have a look? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker
by GHC 26 Oct '16

26 Oct '16

#12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure if this is a bug or hanging the compiler is expected here. This was the minimal example that causes GHC to hang: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE AllowAmbiguousTypes #-} main = return $ f (Just 'c') data D1 x data D2 type family TF x = t | t -> x type instance TF (D1 x, a) = Maybe (TF (x, a)) type instance TF (D2, ()) = Char class C p where f :: TF (x, a) -> () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9858: Typeable instance for datatype and its promoted constructor is the same
by GHC 26 Oct '16

26 Oct '16

#9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable data A = A main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) }}} This returns `True`, but it should return `False`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 119

[GHC] #12507: Can't deduce implicit parameter
by GHC 24 Oct '16

24 Oct '16

#12507: Can't deduce implicit parameter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried running a [https://gist.github.com/llelf/6c01ded225877914f38a gist] {{{#!hs {-# LANGUAGE GADTs, ConstraintKinds, Rank2Types, ImplicitParams #-} data Rec fields where Rec :: fields => Rec fields infixr 1 ? (?) :: Rec fields -> (fields => r) -> r Rec ? e = e record :: Rec (?a :: Int, ?b :: String) record = Rec where ?a=42 ?b="hey" access :: Int access = record ? ?a }}} and got {{{ $ ghci -ignore-dot-ghci tCHB.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tCHB.hs, interpreted ) tCHB.hs:15:19: error: • Could not deduce: ?a::Int arising from a use of implicit parameter ‘?a’ from the context: (?a::Int, ?b::String) bound by a type expected by the context: (?a::Int, ?b::String) => Int at tCHB.hs:15:10-20 • In the second argument of ‘(?)’, namely ‘?a’ In the expression: record ? ?a In an equation for ‘access’: access = record ? ?a Failed, modules loaded: none. Prelude> }}} I would certainly expect the context `(?a::Int, ?b::String)` to imply `?a::Int`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12507> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12174: Recursive use of type-in-type results in infinite loop
by GHC 24 Oct '16

24 Oct '16

#12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- Typechecking this module results in an infinite loop: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeInType #-} module X where data V a data T = forall (a :: S). MkT (V a) data S = forall (a :: T). MkS (V a) }}} There's a mutually recursive reference so it should be rejected but maybe the check is not happening early enough (or the existing check is only for self-reference.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9