December 2015 - ghc-tickets

[GHC] #10969: Arm: Investigate Thumb2/Arm interworking
by GHC 13 Jan '16

13 Jan '16

#10969: Arm: Investigate Thumb2/Arm interworking -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: arm, thumb | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #10375 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Arm (32 bit) has two commonly used instruction sets; Thumb2 and Arm. The former is encoded in two bytes per instruction and the latter in four bytes. The CPU also has a bit in the flags register specifyng which code execution mode the CPU is currently in. The important thing to note is that executing Arm code when in Thumb2 mode (or vice versa) will sooner or later result in an illegal insruction or segfault. During debugging of #10375, I found that Haskell code compiled via the LLVM backend was generating Arm instructions, while C code compiled via GCC was generating Thumb2 code. When object code from these two paths are linked by the system linker everything is fine because the system linker knows how to link Thumb code to Arm code to produce a valid binary. The problem in #10375 was that in GHCi, the runtime linker was loading object files without the correct fixups between Thumb2 and Arm so that Thumb2 code in the `StgRun` function was jumping correctly into Arm code in the loaded object and returning to the Thumb2 code in `StgRun` while still in Arm execution mode and then crashing. In commit [changeset:"933adc0f31164cb651d11ecfcfe612ac429f714f/ghc" 933adc0f/ghc] I fixed GHCi for Arm by forcing GHC to generate only Arm code. As discussed in the associated Phab:D1323 it would be nice to investigate this further to see if its possible to make GHC generate Thumb2 code (which potentially has some performance benefits since it encodes all instructions in two bytes) and/or fix Thumb2/Arm interop. However, that interop may not be possible. In one of the comments in the Phab:D1323, @bgamari said: > That being said, I don't think we'll ever be able to support linking of Thumb Haskell code with ARM Haskell code. The reason for this is that interop requires the use of a trampoline, which breaks tables-next-to- code. Two possible outcomes for this ticket are: * We somehow get proper Thumb2/Arm code interoperation working. * We decide that interop is too difficult or not worthwhile and a) document this somewhere in the code and b) remove the Thumb2 relocation code in `rts/Linker.c` and all other references to Thumb2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10968: Type hole cause bad type checking
by GHC 12 Jan '16

12 Jan '16

#10968: Type hole cause bad type checking -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- I've tried to compile that incorrect code on ghc-7.10.2 linux x86_64: {{{#!hs import Control.Monad.Reader type Tst m = ReaderT () (ReaderT Int m) f :: Monad m => Tst m () f = return () f1 :: ReaderT () m () -> ReaderT () m () f1 ev = f >> _ >> ev main :: IO () main = print $ runReaderT (f1 (return ())) () }}} But тypechecker does not reject f1 and have that: {{{ [1 of 1] Compiling Main ( /home/ndtimofeev/tst.hs, /home/ndtimofeev/tst.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): StgCmmEnv: variable not found $dFunctor_aYS local binds for: f_rsZ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If switch hole to undefined, i have normal typechecking error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10968> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10719: Malformed data type quotation accepted
by GHC 11 Jan '16

11 Jan '16

#10719: Malformed data type quotation accepted -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This is accepted: Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A where C :: C |])}}} "[DataD [] A_1627402878 [] [ForallC [] [] (NormalC C_1627402879 [])] []]" In contrast this is rejected: Prelude Language.Haskell.TH> {{{$(stringE . show =<< [d| data A p where C :: C |])}}} <interactive>:29:22: Malformed constructor result type: C However it would make sense to form an equality constraint (for later kind/type checking) in these cases, something along the lines of: {{{#!hs data A p where C :: (A p ~ C) => C }}} as there could be type synonym (or family) `C`. I have tested various versions >= 7.8.3 and all seem to behave the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns)
by GHC 11 Jan '16

11 Jan '16

#11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) -------------------------------------+------------------------------------- Reporter: gkaracha | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: pattern | Operating System: Unknown/Multiple matching, exhaustiveness | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #595 Differential Rev(s): | Wiki Page: | PatternMatchCheck, | PatternMatchCheckImplementation -------------------------------------+------------------------------------- There are some cases where the new exhaustiveness checker emits duplicate warnings. E.g. for `f`: {{{#!hs f :: Bool -> Bool -> () f (not -> True) (not -> False) = () }}} we get: {{{ DuplicateWarn.hs:6:1: warning: Pattern match(es) are non-exhaustive In an equation for ‘f’: Patterns not matched: _ _ -- represents (not -> False) _ _ _ -- represents (not -> True) (not -> True) }}} As indicated in the comments, the two comments represent different missing cases, but since we do not print the additional information, they look alike. It would be better to either: * Give additional information to the user to distinguish between the two or * Print a single warning `(_ _)` I cannot think of a nice solution to this yet but I will keep thinking about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11302: GHC HEAD uses up all memory while compiling `genprimcode`
by GHC 11 Jan '16

11 Jan '16

#11302: GHC HEAD uses up all memory while compiling `genprimcode` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- When attempting to self-bootstrap GHC HEAD I discovered that `utils/genprimocode` can't be compiled with GHC HEAD. How to reproduce roughly: {{{ $ cd utils/genprimcode $ alex --ghc Lexer.x $ happy --ghc Parser.y $ ghc-7.11.20151226 --make Main [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) [5 of 5] Compiling Main ( Main.hs, Main.o ) ...killed by OS due to running out-of-memory after using up >10GiB ram.... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10476: Wrong ar during cross-compilation
by GHC 10 Jan '16

10 Jan '16

#10476: Wrong ar during cross-compilation -------------------------------------+------------------------------------- Reporter: jakzale | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: cross- | Type of failure: Building GHC compiling | failed Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It appears that during cross-compilation, while building stage 1 ghc, the build system uses ar for target architecture instead of ar for build/host architecture. It will cause linking errors on systems where ar for target architecture is incompatible with ar for build/host architecture (sample output attached below). {{{ (...) "rm" -f libraries/Cabal/Cabal/dist- boot/build/libHSCabal-1.22.3.0-3tdTeip89ooLNDDdwdA54s.a.contents "rm" -f libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a libraries/bin-package-db/dist- boot/build/libHSbin-package-db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents echo libraries/bin-package-db/dist-boot/build/GHC/PackageDb.o >> libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents "/Users/jakub/src/haskell/PNaCl/gsoc/wrappers/i686-unknown-nacl-ar" q libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a @libraries/bin-package-db/dist- boot/build/libHSbin-package-db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents /Users/jakub/src/nacl_sdk/pepper_canary/toolchain/mac_x86_newlib/bin/i686 -nacl-ar: creating libraries/bin-package-db/dist-boot/build/libHSbin- package-db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a "rm" -f libraries/bin-package-db/dist-boot/build/libHSbin-package- db-0.0.0.0-Gk3F1vzzO3g80wuNGtok3x.a.contents (...) ld: archive has no table of contents file '/Users/jakub/src/haskell/PNaCl /ghc-pnacl/libraries/terminfo/dist- boot/build/libHSterminfo-0.4.0.1-7qZwBlx3clR8sTBilJl253.a' for architecture x86_64 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11170: (read ".9") :: Double unable to parse
by GHC 10 Jan '16

10 Jan '16

#11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.10.2 Keywords: Read | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For most languages ".9" is a floating point number equal to 0.9, but in GHC this is unparsable. I don't know if it is by design, but it was unexpected by me. I think that it is good this to be valid parsable to Double string. What do you think of? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10776: DataKinds promotion of String -> Symbol and Natural -> Nat
by GHC 10 Jan '16

10 Jan '16

#10776: DataKinds promotion of String -> Symbol and Natural -> Nat -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: DataKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Exactly what it says on the tin. It would be nice if the following would compile: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, GADTs #-} import GHC.TypeLits import GHC.Natural data X = X String Natural data Y :: X -> * where Y :: Y (X "hello" 4) }}} I kind of assume there's already a ticket for this, but couldn't find one, so figured I'd open one in case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to <Shlobj.h>
by GHC 09 Jan '16

09 Jan '16

#10273: haskeline : Cross-compile from Linux to Windows fails due to <Shlobj.h> -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries | Version: 7.11 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #10070 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The #include of <Shlobj.h> doesn't work when cross-compiling from Linux to Windows because the Linux file system is case sensitive and on Linux the file is <shlobj.h>. Down casing the name of this include file should not cause problems on Windows as the Windows file system is case insensitive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10273> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10703: -fth-dec-file can't handle lambdas
by GHC 09 Jan '16

09 Jan '16

#10703: -fth-dec-file can't handle lambdas -------------------------------------+------------------------------------- Reporter: Fabian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10701 Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs instance Data.TH.Object.Object InputDropboxFiles String Language.JavaScript.Interpret.Primitive where toObject x@(InputDropboxFiles {}) = fromList (Data.Maybe.catMaybes [Just (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr) "root" (inputDropboxFilesRoot x)), Just (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr) "path" (inputDropboxFilesPath x)), fmap (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr) "rev") (inputDropboxFilesRev x), Just (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr) "access_token" (inputDropboxFilesAccess_token x))]) }}} {{{#!hs (\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr)) "root" (inputDropboxFilesRoot x) }}} should be {{{#!hs ((\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr))) "root" (inputDropboxFilesRoot x) }}} ie. the lambda needs parentheses around it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12