January 2014 - ghc-tickets

[GHC] #8538: confusing specialization CORE warning, also can't mark type class instances INLINEABLE unless class defn is marked INLINEABLE
by GHC 27 Jul '15

27 Jul '15

#8538: confusing specialization CORE warning, also can't mark type class instances INLINEABLE unless class defn is marked INLINEABLE ------------------------------------+------------------------------------- Reporter: carter | 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: | ------------------------------------+------------------------------------- As part of writing an array library for numerical purposes, I have a static sized strict list type for representing the Indexing tuple. One implementation strategy makes it a tad generic, and then I'm writing a bunch of manipulation utilities using Functor, Applicative and Foldable. I wrote it with all the functions marked INLINABLE so i could ensure that I could have the index arith calculations SPECIALIZE in the common cases. Unfortunately, it seems like type class instances can only marked INLINABLE if the type class definition is itself marked INLINE or INLINABLE. Considering i'm writing a numerical array library, I want to make sure that address arithmetic. This could could be argued to be by design (and thus a wont fix). That aside, I also get the following Warning for my "map2" function, which i found surprising. (and it perhaps is worth some investigation / cleanup ) {{{ src/Numerical/Types/Shape.hs:165:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor :: Functor (Shape ('S N0)) [LclId] $dFunctor = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor } in map2 @ a @ b @ c @ N2 (Numerical.Types.Shape.$fApplicativeShape @ ('S N0) (Numerical.Types.Shape.$fFunctorShape @ ('S N0) $dFunctor) (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor Numerical.Types.Shape.$fApplicativeShape0)) }}} {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import GHC.Magic import Data.Monoid import Data.Functor import Data.Foldable import Control.Applicative -- import Numerical.Types.Nat import Prelude (seq, ($!),($),Show(..),Eq(),Int) data Nat = S !Nat | Z type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 {- not doing the HLIST style shape because I don't want to have any pattern matchings going on. Also would play hell with locality quality in the address translation hackery, because there'd be an extra load to get those ints! -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving instance (Show (Shape rank a)) -- deriving instance Eq (Shape rank a) -- #if defined( __GLASGOW_HASKELL__ ) && ( __GLASGOW_HASKELL__ >= 707) --deriving instance Typeable (Shape rank a) -- #endif instance Functor (Shape Z) where fmap = \ f Nil -> Nil {-# INLINABLE fmap #-} {-# SPECIALIZE fmap :: (a ->b )-> (Shape Z a)-> (Shape Z b) #-} instance (Functor (Shape r)) => Functor (Shape (S r)) where fmap = \ f (a :* rest) -> f a :* fmap f rest {-# INLINABLE fmap #-} {-# SPECIALIZE fmap :: (a ->b )-> (Shape N1 a)-> (Shape N1 b) #-} {-# SPECIALIZE fmap :: (a ->b )-> (Shape N2 a)-> (Shape N2 b) #-} instance Applicative (Shape Z) where pure = \ _ -> Nil {-# INLINE pure #-} (<*>) = \ _ _ -> Nil {-# INLINE (<*>) #-} {-# SPECIALIZE pure :: a -> Shape Z a #-} {-# SPECIALIZE (<*>) :: Shape Z (a -> b) -> Shape Z a -> Shape Z b #-} instance Applicative (Shape r)=> Applicative (Shape (S r)) where pure = \ a -> a :* (pure a) {-# INLINE pure #-} (<*>) = \ (f:* fs) (a :* as) -> f a :* (inline (<*>)) fs as {-# INLINE (<*>) #-} {-# SPECIALIZE pure :: a -> (Shape Z a) #-} {-# SPECIALIZE pure :: a -> (Shape N1 a) #-} {-# SPECIALIZE pure :: a -> (Shape N2 a )#-} instance Foldable (Shape Z) where foldMap = \ _ _ -> mempty {-# INLINE foldMap #-} foldl = \ _ init _ -> init {-# INLINE foldl #-} foldr = \ _ init _ -> init {-# INLINE foldr #-} foldr' = \_ !init _ -> init {-# INLINE foldr' #-} foldl' = \_ !init _ -> init {-# INLINE foldl' #-} -- {-# SPECIALIZE foldMap :: Monoid m => (a -> m)-> Shape Z a -> m #-} -- {-# SPECIALIZE foldl :: (a ->b -> a) -> a -> Shape Z b -> a #-} -- {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape Z b -> a #-} -- {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape Z b -> a #-} -- {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape Z b -> a #-} instance (Foldable (Shape r)) => Foldable (Shape (S r)) where foldMap = \f (a:* as) -> f a <> foldMap f as {-# INLINE foldMap #-} foldl' = \f !init (a :* as) -> let next = f init a in next `seq` (inline foldl) f next as {-# INLINE foldl' #-} foldr' = \f !init (a :* as ) -> f a $! (inline foldr) f init as {-# INLINABLE foldr' #-} foldl = \f init (a :* as) -> let next = f init a in (inline foldl) f next as {-# INLINE foldl #-} foldr = \f init (a :* as ) -> f a $ (inline foldr) f init as {-# INLINE foldr #-} {-# SPECIALIZE foldMap::Monoid m => (a -> m)-> Shape N1 a -> m #-} {-# SPECIALIZE foldl :: (a ->b -> a) ->a -> Shape N1 b -> a #-} {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape N1 b -> a #-} {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape N1 b -> a #-} {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape N1 b -> a #-} {-# SPECIALIZE foldMap :: Monoid m => (a -> m)-> Shape N2 a -> m #-} {-# SPECIALIZE foldl :: (a ->b-> a) ->a -> Shape N2 b -> a #-} {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape N2 b -> a #-} {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape N2 b -> a #-} {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape N2 b -> a #-} -- map2 :: (Applicative (Shape r))=> (a->b ->c) -> (Shape r a) -> (Shape r b) -> (Shape r c ) map2 = \f l r -> pure f <*> l <*> r {-# INLINABLE map2 #-} {-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape Z a) -> (Shape Z b) -> (Shape Z c )#-} {-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape N1 a) -> (Shape N1 b) -> (Shape N1 c )#-} {-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape N2 a) -> (Shape N2 b) -> (Shape N2 c )#-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8538> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8327: Cmm sinking does not eliminate dead code in loops
by GHC 25 Jul '15

25 Jul '15

#8327: Cmm sinking does not eliminate dead code in loops ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Cmm code shown in #8326 is suboptimal. For this Haskell code: {{{ isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} we get Cmm that contains dead code in a loop: {{{ cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} Notice that `_sEV` is dead - we should optimize it away. This is a known deficiency in the Cmm sinking pass (i.e. it does not work for loops). I'm putting this on Trac so we have this documented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail
by GHC 25 Jul '15

25 Jul '15

#8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I have encountered a strange occurrence with GHC that was causing several GHC job failures on an SGE cluster. It turned out that there were other SGE users who needed an absurdly large stack size limit (set via 'ulimit -s') in the several gigabytes range. The default stack size limit had to be raised for the entire cluster. Any job that was run on a machine where the virtual memory limit was less than or equal to 2X the stack size limit, GHC would crash with the following message: ghc: failed to create OS thread: Cannot allocate memory I am running on GHC 7.6.3 with a 64-bit RedHat Enterprise OS, version 5.5. To reproduce the error, I was able to create the following test case: [ ~]$ ulimit -v unlimited [ ~]$ ulimit -s 10240 [ ~]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 [ ~]$ ulimit -v 200000 [ ~]$ ulimit -s 100000 [ ~]$ ghc --version ghc: failed to create OS thread: Cannot allocate memory Several other programs work find using these settings, but GHC consistently has problems. Is this a fundamental issue with how GHC operates or can this be addressed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm
by GHC 20 Jul '15

20 Jul '15

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Test case (#7571 just will not die, it seems) {{{ $ make TEST=T7571 WAY=llvm ... ====> Scanning ./all.T =====> T7571(llvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -fllvm -no-hs-main >T7571.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-07 22:18:14.132934017 -0500 +++ ./T7571.comp.stderr 2013-08-14 01:26:33.942103723 -0500 @@ -0,0 +1 @@ +WARNING: Non constant alignment value given for memcpy! Please report to GHC developers *** unexpected failure for T7571(llvm) }}} However, this test case does not fail under WAY=optllvm, which I think is worth investigating probably: {{{ $ make TEST=T7571 WAY=optllvm ... ====> Scanning ./all.T =====> T7571(optllvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -O -fllvm -no-hs-main >T7571.comp.stderr 2>&1 OVERALL SUMMARY for test run started at Wed Aug 14 01:25:42 CDT 2013 7 total tests, which gave rise to 28 test cases, of which 27 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures }}} However, there is another way to trigger this bug in *both* cases: {{{ #include "Cmm.h" testMemcpy (W_ dst, W_ src, W_ l, W_ sz) { prim %memcpy(dst, src, l, sz); return (); } }}} will fail both ways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8123: GHCi warns about -eventlog even though it's sometimes necessary
by GHC 19 Jul '15

19 Jul '15

#8123: GHCi warns about -eventlog even though it's sometimes necessary -------------------------+------------------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: GHCi | Operating System: Linux Keywords: | Type of failure: Incorrect warning at Architecture: | compile-time x86_64 (amd64) | Test Case: Difficulty: | Blocking: Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- If I invoke GHCi as {{{ghci -eventlog}}}, it says: {{{Warning: -debug, -threaded and -ticky are ignored by GHCi}}}. However, the flag does make a difference, in that GHCi will be able to load object files that were compiled using {{{-eventlog}}}. For this reason, I don't think {{{-eventlog}}} should trigger the warning. Also runghc has the same issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8709: `make 1` does not work (well)
by GHC 10 Jul '15

10 Jul '15

#8709: `make 1` does not work (well) ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Say I do a `sync-all pull` and then fix a bunch of merge errors. The changes mean that I need to recompile the stage-1 compiler. So, I dutifully `make distclean` and start rebuilding. I then find a bunch of compiler errors in my edited code. Now, I'd like to start the fix error/recompile loop. BUT, when I do `make 1` in the `compiler/` directory, I get errors: {{{ rae:13:49:29 ~/Documents/ghc/compiler> make 1 make -C .. stage=1 all_ghc_stage1 compiler_dist_NO_BUILD_DEPS=YES compiler_dist-boot_NO_BUILD_DEPS=YES compiler_dist- install_NO_BUILD_DEPS=YES NO_GENERATED_MAKEFILE_RULES=YES OMIT_PHASE_0=YES OMIT_PHASE_1=YES compiler_stage1_NO_BUILD_DEPS=YES compiler_stage2_NO_BUILD_DEPS=YES compiler_stage3_NO_BUILD_DEPS=YES ghc_stage1_NO_BUILD_DEPS=YES ghc_stage2_NO_BUILD_DEPS=YES ghc_stage3_NO_BUILD_DEPS=YES ONLY_DEPS_FOR="compiler_stage1 ghc_stage1" ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all_ghc_stage1 libraries/old-time/ghc.mk:5: libraries/old-time/dist-install/package- data.mk: No such file or directory libraries/haskell98/ghc.mk:5: libraries/haskell98/dist-install/package- data.mk: No such file or directory libraries/haskell2010/ghc.mk:5: libraries/haskell2010/dist-install /package-data.mk: No such file or directory libraries/random/ghc.mk:5: libraries/random/dist-install/package-data.mk: No such file or directory libraries/primitive/ghc.mk:5: libraries/primitive/dist-install/package- data.mk: No such file or directory libraries/vector/ghc.mk:5: libraries/vector/dist-install/package-data.mk: No such file or directory libraries/dph/dph-base/ghc.mk:5: libraries/dph/dph-base/dist-install /package-data.mk: No such file or directory libraries/dph/dph-prim-interface/ghc.mk:5: libraries/dph/dph-prim- interface/dist-install/package-data.mk: No such file or directory libraries/dph/dph-prim-seq/ghc.mk:5: libraries/dph/dph-prim-seq/dist- install/package-data.mk: No such file or directory libraries/dph/dph-prim-par/ghc.mk:5: libraries/dph/dph-prim-par/dist- install/package-data.mk: No such file or directory libraries/dph/dph-lifted-base/ghc.mk:5: libraries/dph/dph-lifted-base /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-boxed/ghc.mk:5: libraries/dph/dph-lifted-boxed /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-copy/ghc.mk:5: libraries/dph/dph-lifted-copy /dist-install/package-data.mk: No such file or directory libraries/dph/dph-lifted-vseg/ghc.mk:5: libraries/dph/dph-lifted-vseg /dist-install/package-data.mk: No such file or directory libraries/ghc-prim/ghc.mk:4: libraries/ghc-prim/dist-install/package- data.mk: No such file or directory libraries/integer-gmp/ghc.mk:4: libraries/integer-gmp/dist-install /package-data.mk: No such file or directory libraries/base/ghc.mk:4: libraries/base/dist-install/package-data.mk: No such file or directory libraries/filepath/ghc.mk:4: libraries/filepath/dist-install/package- data.mk: No such file or directory libraries/array/ghc.mk:4: libraries/array/dist-install/package-data.mk: No such file or directory libraries/deepseq/ghc.mk:4: libraries/deepseq/dist-install/package- data.mk: No such file or directory libraries/bytestring/ghc.mk:4: libraries/bytestring/dist-install/package- data.mk: No such file or directory libraries/containers/ghc.mk:4: libraries/containers/dist-install/package- data.mk: No such file or directory libraries/old-locale/ghc.mk:4: libraries/old-locale/dist-install/package- data.mk: No such file or directory libraries/time/ghc.mk:4: libraries/time/dist-install/package-data.mk: No such file or directory libraries/unix/ghc.mk:4: libraries/unix/dist-install/package-data.mk: No such file or directory libraries/directory/ghc.mk:4: libraries/directory/dist-install/package- data.mk: No such file or directory libraries/process/ghc.mk:4: libraries/process/dist-install/package- data.mk: No such file or directory libraries/hpc/ghc.mk:4: libraries/hpc/dist-install/package-data.mk: No such file or directory libraries/pretty/ghc.mk:4: libraries/pretty/dist-install/package-data.mk: No such file or directory libraries/template-haskell/ghc.mk:4: libraries/template-haskell/dist- install/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:4: libraries/Cabal/Cabal/dist-install /package-data.mk: No such file or directory libraries/binary/ghc.mk:4: libraries/binary/dist-install/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:4: libraries/bin-package-db/dist-install /package-data.mk: No such file or directory libraries/hoopl/ghc.mk:4: libraries/hoopl/dist-install/package-data.mk: No such file or directory libraries/transformers/ghc.mk:4: libraries/transformers/dist-install /package-data.mk: No such file or directory libraries/xhtml/ghc.mk:4: libraries/xhtml/dist-install/package-data.mk: No such file or directory libraries/terminfo/ghc.mk:4: libraries/terminfo/dist-install/package- data.mk: No such file or directory libraries/haskeline/ghc.mk:4: libraries/haskeline/dist-install/package- data.mk: No such file or directory libraries/integer-gmp/gmp/ghc.mk:49: libraries/integer-gmp/gmp/config.mk: No such file or directory utils/hsc2hs/ghc.mk:16: utils/hsc2hs/dist-install/package-data.mk: No such file or directory utils/ghc-pkg/ghc.mk:66: utils/ghc-pkg/dist-install/package-data.mk: No such file or directory utils/dll-split/ghc.mk:18: utils/dll-split/dist-install/package-data.mk: No such file or directory utils/ghc-pwd/ghc.mk:8: utils/ghc-pwd/dist-install/package-data.mk: No such file or directory utils/ghc-cabal/ghc.mk:67: utils/ghc-cabal/dist-install/package-data.mk: No such file or directory utils/hpc/ghc.mk:18: utils/hpc/dist-install/package-data.mk: No such file or directory utils/runghc/ghc.mk:28: utils/runghc/dist-install/package-data.mk: No such file or directory utils/mkUserGuidePart/ghc.mk:18: utils/mkUserGuidePart/dist/package- data.mk: No such file or directory utils/compare_sizes/ghc.mk:8: utils/compare_sizes/dist-install/package- data.mk: No such file or directory make[2]: *** No rule to make target `libraries/integer-gmp/gmp/config.mk'. Stop. make[1]: *** [all_ghc_stage1] Error 2 make: *** [1] Error 2 }}} Using `make stage=1` works fine, but computing the dependencies each time is annoying. In past experience, I've seen that, once the stage-1 compiler builds to completion at least once, `make 1` works just fine -- it just fails after a `clean`. I don't recall having this problem with `make 2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8206: Add support for Portable Native Client
by GHC 05 Jul '15

05 Jul '15

#8206: Add support for Portable Native Client -------------------------------------------------+------------------------- Reporter: guest | Owner: Alex Type: feature request | Sayers Priority: normal | Status: new Component: Compiler | Milestone: Keywords: NaCl PNaCl Portable Native | Version: Client pexe | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------------+------------------------- == Motivation == [http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable- native-client Portable Native Client] (PNaCl) is a feature in Google Chrome which (roughly) allows it to use LLVM bitcode like browsers use javascript today. The bitcode is downloaded, validated, compiled, and (safely) executed, with access to an API for manipulating the DOM of the page which loaded it. The dream: Haskell executed in the browser at near- native speed. Unfortunately, while GHC has an LLVM backend, the bitcode it generates doesn't satisfy the PNaCl validator. == Portable Native Client == The user visits a page with an <embed> tag pointing to a "pexe" - a PNaCl bitcode file. The bitcode is downloaded and streamed first into a code validator, and then into a compiler. The resulting machine code is then executed as a memory-protected process. The [https://developers.google.com /native-client/pepperc/ Pepper API], a library Google provides, provides access to the browser for things like connecting to websockets, playing audio, and communicating with javascript running on the page. PNaCl is present in Chrome 29 (go to chrome://flags to enable it), and will be enabled for arbitrary sources (the "open web") in Chrome 30. Mozilla have announced that they don't intend to support Native Client. == The Easily-Fixed == The pexe bitcode format is a frozen subset of LLVM bitcode. The PNaCl toolchain provides `pnacl-finalize`, which translates LLVM bitcode into pexe bitcode. PNaCl [http://www.chromium.org/nativeclient/pnacl/bitcode- abi##callingconventions only allows] the standard "ccc" calling convention, whereas GHC likes to use its own "cc 10" calling convention. You can make GHC use ccc by using an unregisterised build, for a slow-down factor of about 2. It seems likely that code-next-to-tables will upset the validator. If so, this can be turned off for a small performance hit. == The Not-So-Easily-Fixed == The validator requires that requests for IO are sent to Pepper. PNaCl also requires that you use newlib instead of glibc. Spawning new processes is forbidden (although creating pthreads is fine). It also seems likely that the validator with take umbrage at calls to `mmap`, which the GHC runtime uses to request memory allocation. It seems, therefore, that significant chunks of the RTS will have to be ported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8353: Easy way to defer type errors
by GHC 04 Jul '15

04 Jul '15

#8353: Easy way to defer type errors ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- A number of comments I've heard recently have focused on the joy of `-fdefer-type-errors`, especially for newcomers to Haskell. However, in GHCi, one has to 1. be aware that `-fdefer-type-errors` exists 2. know the `:set ...` syntax to turn it on, and then 3. is stuck with this setting on until they turn it off Instead, I propose new `:load!` and `:reload!` commands (abbreviated to `:l!` and `:r!`) which turn on `-fdefer-type-errors` just for that one command. When a load or reload fails, the error message could suggest these alternate forms. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8620: build of head on Mac 10.9 with xcode 5 fails with
by GHC 03 Jul '15

03 Jul '15

#8620: build of head on Mac 10.9 with xcode 5 fails with ----------------------------------+--------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- make -j3 fails with Configuring ghc-bin-7.7.20131217... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestar… for details. Stop. make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8620> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8363: Order matters for unused import warnings when reexporting identifiers
by GHC 01 Jul '15

01 Jul '15

#8363: Order matters for unused import warnings when reexporting identifiers ------------------------------------+------------------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Import order seem to change whether unused import warnings trigger when a module re-exports an identifier, with another module importing it and another module exporting the same identifier. Reproduction: {{{ module Foo ( (<$>) , g ) where import Control.Applicative g :: Int g = 1 }}} {{{ module Main where import Control.Applicative import Foo main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ $ ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} If Main is not using `g` then this gives a warning that the import of `Foo` is redundant. If we switch the order of the imports we do get the warning: {{{ module Main where import Foo import Control.Applicative main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ > ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Main.hs:4:1: Warning: The import of `Control.Applicative' is redundant except perhaps to import instances from `Control.Applicative' To import instances alone, use: import Control.Applicative() Linking Main ... }}} I expected both versions of Main to produce the same warning. Tested on GHC 7.7.20130824 and 7.4.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4