August 2014 - ghc-tickets

[GHC] #8981: ghc-pkg complains about missing haddock interface files
by GHC 19 Feb '16

19 Feb '16

#8981: ghc-pkg complains about missing haddock interface files --------------------------+------------------------------------------------ Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.8.2 Priority: normal | Version: 7.8.1 Component: | Operating System: MacOS X Compiler | Type of failure: Incorrect result at runtime Keywords: ghc- | Test Case: pkg | Blocking: Architecture: x86_64 | (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ As Conal reported on the mailing list[1], `ghc-pkg check` on Mavericks allegedly returns: {{{ bash-3.2$ ghc-pkg check Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory }}} It's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not. Marking for 7.8.2. I'm looking into this soon. [1]http://www.haskell.org/pipermail/glasgow-haskell- users/2014-April/024846.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9041: NCG generates slow loop code
by GHC 17 Feb '16

17 Feb '16

#9041: NCG generates slow loop code -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler (NCG) | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- In http://stackoverflow.com/a/23322255/263061 we compile the code {{{ main :: IO () main = do loop (maxBound :: Word32) $ \i -> do when (i `rem` 100000000 == 0) $ putStrLn "foo" }}} and compare the assembly generated by the NCG and `-fllvm`. The LLVM code is 10 times faster. While the LLVM code looks great, NCG one generated looks quite unfortunate and messy, with a lot of unnecessary `mov`ing around. I am by no means an expert in this, but some of it looks like low hanging potential improvements. This is the '''LLVM code''': {{{ Main_zdwa_info: .LBB1_1: movl $4294967295, %esi /* load the loop bound */ movabsq $-6067343680855748867, %rdi /* load a magic number for the modulus */ jmp .LBB1_2 .LBB1_4: incl %ecx /* loop core start */ .LBB1_2: cmpq %rsi, %rcx je .LBB1_6 /* check loop bound */ /* do the modulus with two multiplications, a shift and a magic number */ /* note : gcc does the same reduction */ movq %rcx, %rax mulq %rdi shrq $26, %rdx imulq $100000000, %rdx, %rax cmpq %rax, %rcx jne .LBB1_4 /* loop core end */ /* Code omitted: print, then return to loop beginning */ .LBB1_6: }}} So the core of the loop is a nice and short: {{{ incl cmpq je movq [division replaced by magic multiplication] mulq shrq imulq cmpq jne }}} Now what '''NCG''' produces: {{{ Main_zdwa_info: /* loop core start */ .Lc3JD: leaq -16(%rbp),%rax /* stack check */ cmpq %r15,%rax jb .Lc3JO /* jump not taken in the normal case */ .Lc3JP: movl $4294967295,%eax /* issue: loading the bound on every iteration */ cmpq %rax,%r14 jne .Lc3JB .Lc3JC: /* Return from main. Code omitted */ .Lc3JB: /* test the index for modulus */ movl $100000000,%eax /* issue: unnecessary moves */ movq %rax,%rbx /* and loading the modulo arg on every iteration */ movq %r14,%rax xorq %rdx,%rdx /* shorter alternative to mov $0,%rdx */ divq %rbx /* issue: doing the division (llvm and gcc avoid this) */ testq %rdx,%rdx jne .Lc3JU /* This jump is usually taken. */ .Lc3JV: /* do the printing. Code omitted. Not relevant */ .Lc3JN: /* increment index and (I guess) restore registers messed up by the printing */ movq 8(%rbp),%rax /* This code is not very relevant because we don't almost never */ incq %rax movl %eax,%r14d addq $16,%rbp jmp Main_zdwa_info .Lc3JU: leaq 1(%r14),%rax /*issue: why not just increment r14? */ movl %eax,%r14d jmp Main_zdwa_info }}} So the core of this loop is {{{ movl [stack check] cmpq jne movl movq movq xorq divq testq jne leaq movl jmp }}} Some issues here: * the stack check is inside the loop * the loop limit is loaded every time inside the loop * the modulo arg is loaded every time inside the loop * we are shuffling around registers * no strength reduction (div is not replaced by cheaper magic number imul) * weird increment using leaq It would be great if somebody with codegen insight could comment on whether these are easy targets for improvement! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8927: Multiple case match at once
by GHC 16 Feb '16

16 Feb '16

#8927: Multiple case match at once -------------------------------------------+------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Keywords: case, multiple | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- In F# we can do {{{ #!div style="font-size: 120%" {{{#!haskell match x with | 1 | 2 | 3 -> "123" | 4 | 5 | 6 -> "456" }}} }}} It will be nice if we have an extension which allows us to do {{{ #!div style="font-size: 120%" {{{#!haskell case x of 1 | 2 | 3 -> "123" 4 | 5 | 6 -> "456" }}} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8927> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8278: Improve error message when the same type is imported from two different library versions
by GHC 14 Feb '16

14 Feb '16

#8278: Improve error message when the same type is imported from two different library versions ------------------------------------+------------------------------------- Reporter: Yuras | 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: | ------------------------------------+------------------------------------- When a package indirectly depends on different versions of the same library, ghc reports cryptic error: {{{ Couldn't match expected type `ByteString' with actual type `bytestring-0.9.2.1:Data.ByteString.Internal.ByteString' }}} Error contains fully qualified type with package name and version only when the type is imported from different versions on the library, so looks like ghc knows what is wrong. Is it possible to add something like the next: {{{ Note: ByteString is imported from different package versions: bytestring-0.9.2.1 and bytestring-0.10.0.1 }}} It is inspired by a number of StackOverflow questions (e.g. http://stackoverflow.com/questions/12576817/couldnt-match-expected-type- with-actual-type-error-when-using-codec-bmp/12577025#12577025, http://stackoverflow.com/questions/18767086/bytestring-to-lazy-text-and- vice-versa/18769431?noredirect=1#comment27676563_18769431) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch
by GHC 12 Feb '16

12 Feb '16

#9022: TH pretty printer and GHC parser semicolon placement mismatch ----------------------------+---------------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- In GHC 7.8 TemplateHaskell pretty printer started inserting explicit braces and semicolons. It puts semicolons at the end of the line as opposed to the beginning of the next line. This causes GHC to fail parsing if we try to compile the pretty printed code. {{{ $ cat Foo.hs module Main where import Language.Haskell.TH main = putStrLn $ pprint foo foo :: Dec foo = barD where barD = FunD ( mkName "bar" ) [ Clause manyArgs (NormalB barBody) [] ] barBody = DoE [letxStmt, retxStmt] letxStmt = LetS [ ValD (VarP xName) (NormalB $ LitE $ IntegerL 5) [] ] retxStmt = NoBindS $ AppE returnVarE xVarE xName = mkName "x" returnVarE = VarE $ mkName "return" xVarE = VarE xName manyArgs = map argP [0..9] argP n = VarP $ mkName $ "arg" ++ show n $ ghc-7.8.2 Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo ... $ ./Foo | tee Bar.hs bar arg0 arg1 arg2 arg3 arg4 arg5 arg6 arg7 arg8 arg9 = do {let x = 5; return x} $ ghc Bar.hs [1 of 1] Compiling Main ( Bar.hs, Bar.o ) Bar.hs:2:61: parse error on input `return' }}} I don't know if this is a problem with TH pretty printer or if GHC is supposed to parse semicolons wherever they are.. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9386: GHCi cannot load .so in same ./
by GHC 11 Feb '16

11 Feb '16

#9386: GHCi cannot load .so in same ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In my directory ./ I have an empty file Foo.hs and a shared object file mylib.so. From that directory in the shell, $ ghci Foo *.so GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) mylib.so ... failed. <command line>: user specified .o/.so/.DLL could not be loaded (mylib.so: cannot open shared object file: No such file or directory) Whilst trying to load: (dynamic) mylib.so Additional directories searched: (none) It's interesting that GHCi searches ./ and identifies the correct object file, but then fails to load it. I have also tried the path ./*.so for the GHCi option. However, if I move mylib.so to a directory ./Temp, $ ghci Foo Temp/*.so loads without issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8136: arr020 test fails randomly with ghci way
by GHC 07 Feb '16

07 Feb '16

#8136: arr020 test fails randomly with ghci way -----------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------- I noticed that when I run arr020 (`make TEST=arr020`) it randomly segfaults when running `ghci` way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8265: getTokenStream fails for source using cpp
by GHC 07 Feb '16

07 Feb '16

#8265: getTokenStream fails for source using cpp -----------------------------------+--------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Calling getTokenStream (or getRichTokenStream) on a module that has CPP directives fails as the lexer is given un-preprocessed source -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8842: Make sure msys2 builds non emulating binaries
by GHC 06 Feb '16

06 Feb '16

#8842: Make sure msys2 builds non emulating binaries ------------------------------------+--------------------------------- Reporter: schyler | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I came across this in my own project. MSys2 doesn't enter #ifdef blocks which test for _WIN32. Instead, it pretends to be Linux and has a set of headers which emulate things like mmap. These emulation functions are really really slow -- in my personal tests about 10x slower than calling the WINAPI -- so this ticket is just a reminder (it may already be done) for someone to check that MSys2 builds things non-emulated in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8746: Crosscompiling
by GHC 02 Feb '16

02 Feb '16

#8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: Crosscompile | Operating System: Linux cross compile failed ncurses | Type of failure: Building GHC setupterm not found | failed Architecture: Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Hello! I tried to crosscompile from linux i386 to arm-linux-gnueabihf, but i cant make it happen, because it gives me this weird error while running 'make': {{{ checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for setupterm in -ltinfo... no checking for setupterm in -lncursesw... no checking for setupterm in -lncurses... no checking for setupterm in -lcurses... no configure: error: in '/home/edi/ghc_cross/ghc/libraries/terminfo': configure: error: curses library not found, so this package cannot be built See 'config.log' for more details make[2]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 make[1]: *** [all_libraries/terminfo] Error 2 make[1]: Leave Directory '/home/edi/ghc_cross/ghc' make: *** [all] Error 2 }}} What have i done: -) Compiled 7.8.0 from github (The log says 'That should have been 7.8.0', i chose 7.8 because i thought it would be more stable for crosscompiling) to my i386 (normal boot, configure, make, make install). This worked fine -) installed newest llvm from svn (LLVM version 3.5svn) -) replaced the libffi-3.0.11.tar.gz in ghc/libffi-tarballs with libffi-3.0.13 -) added this version of mk/build.mk: {{{ SRC_HC_OPTS = -H32m _o -fasm -Rghc-timing GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O0 -DDEBUG -Wall GhcLibHcOpts = -O -fasm -XGenerics GhcLibWays = v dyn SplitObjs = NO Stage1Only = YES }}} -) downloaded the sourcecode of ncurses from http://ftp.de.debian.org/debian/pool/main/n/ncurses/ncurses_5.9.orig.tar.gz and builded it with "./configure arm-linux-gnueabihf --with-gcc=arm-linux- gnueabihf-gcc --target=arm-linux-gnueabihf --prefix=/usr/arm-linux- gnueabihf " + "make". afterwards i added the folder to my $PATH -)did "perl boot", "./configure --target=arm-linux-gnueabihf --with-gcc =arm-linux-gnueabihf-gcc --prefix=/usr/arm-linux-gnueabihf" and "make". ./configure worked, but make gives me this weird error. I also tried copying all included files from ncurses to the libraries/terminfo folder, but that also didn't work. I think the mistake is somewhere in the building process, but i'm not exactly sure, so thats why i'm posting this bug. Does anyone have an idea about that? PS: i also made sure that i met the prerequirements mentioned in https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux and https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling Greetings, Edi -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7