November 2014 - ghc-tickets

[GHC] #9686: Link option detection does not work for incremental builds on Windows
by GHC 06 Feb '16

06 Feb '16

#9686: Link option detection does not work for incremental builds on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc on Linux embeds link options into the resulting binary in order to be able to tell when a binary needs to be recompiled because different link options have been passed in to ghc. This functionality is not present on Windows, forcing users to pass in -fforce-recomp. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9638: Speed up Data.Char.isDigit
by GHC 05 Feb '16

05 Feb '16

#9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | 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: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `isDigit` is currently defined like this: {{{#!hs isDigit :: Char -> Bool isDigit c = c >= '0' && c <= '9' }}} This will short-circuit the right way if you're looking for digits mixed with spaces, but the wrong way if you're looking for digits mixed with letters. It also requires a conditional jump to do that short-circuiting (confirmed by inspecting the assembly). It should be better to use an unsigned comparison instead: {{{#!hs isDigit :: Char -> Bool isDigit c = (fromIntegral (ord c) :: Word) - 48 <= 9 }}} The interesting section looks like this {{{ movq 7(%rbx),%rax addq $-48,%rax cmpq $9,%rax setbe %al movzbl %al,%eax shlq $3,%rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax),%rbx addq $8,%rbp jmp *(%rbp) }}} or like this with -fllvm: {{{ movq 7(%rbx), %rax addq $-48, %rax cmpq $10, %rax sbbq %rax, %rax andq $8, %rax movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax), %rbx movq 8(%rbp), %rax addq $8, %rbp jmpq *%rax # TAILCALL }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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

[GHC] #9105: Profiling binary consumes CPU even when idle on Linux.
by GHC 27 Jan '16

27 Jan '16

#9105: Profiling binary consumes CPU even when idle on Linux. ----------------------------+--------------------------------- Reporter: robinp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The program is main = forever $ threadDelay 1000000 >> return () . Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM), GHC 7.4.1 on Ubuntu (not VM). The non-profiling binary doesn't consume CPU, the profiling does ~10% (of a 2Ghz machine). Running with +RTS -I0, so this is not the idle gc. When strace-ing, the profiling one seems to receive a constant flow of SIGVTALRM, while the normal receives one burst each second. I see I can switch off "master tick interval" with -V0, and then CPU is not used, but the consequences of this are not very well documented (apart from context switching becoming deterministic). Interestingly, if I compile using profiling on Windows (latest haskell- platform, 64bit), it doesn't use more CPU than the non-profiling. So, the question is, why does this happen on Linux, and if it can be avoided somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8287: exploring calling convention changes and related engineering for 7.10
by GHC 25 Jan '16

25 Jan '16

#8287: exploring calling convention changes and related engineering for 7.10 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Rocket Science | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm creating this as a master ticket for systematically exploring and benchmarking (possibly breaking) changes to the GHC calling convention. This work will initially focus on x86/x86_64, but may have larger scope. Goals: 1. if possible, improve performance systematically for code run on recent CPU micro architecture generations (eg sandybridge, haswell, and future extensions like Knights Landing and Skylake), ideally without pessimizing code on other or older x86_64 micro-architectures 2. Try to bring native and llvm codegens closer to feature parity (or at the very least, do not widen their capability gap) 3. a few other pieces too, will amend this ticket as ideas / plans clarify -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9149: Description of openFileBlocking is wrong
by GHC 25 Jan '16

25 Jan '16

#9149: Description of openFileBlocking is wrong ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The documentation states: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for reading: if we open in non-blocking mode then the open will fail if there are no writers, whereas a blocking open will block until a writer appears. '' but I think this is the wrong way around, and should be: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for writing: if we open in non-blocking mode then the open will fail if there are no readers, whereas a blocking open will block until a reader appears. '' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8325: Pattern guards in anonymous functions
by GHC 25 Jan '16

25 Jan '16

#8325: Pattern guards in anonymous functions ------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- In the course of a project, I had an idea that would allow less cumbersome use of cases in anonymous functions. Here's a simple example of what I'm proposing: {{{ (\x y | x > y -> x | otherwise -> something else) }}} Currently, the only way to accomplish this is with if() then ... else syntax or the use of the MultiWayIf and LambdaCase extensions. The syntax I've proposed here matches with existing anonymous function syntax and doesn't conflict with any other GHC syntax. This would greatly improve the readability of complex anonymous functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9708: Type inference non-determinism due to improvement
by GHC 24 Jan '16

24 Jan '16

#9708: Type inference non-determinism due to improvement -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Here's an example that showed up in Iavor's test `TcTypeNatSimple`: {{{ ti7 :: (x <= y, y <= x) => Proxy (SomeFun x) -> Proxy y -> () ti7 _ _ = () }}} From the ambiguity check for `ti7` we get this constraint {{{ forall x y. (x <= y, y <= x) => ( SomeFun x ~ SomeFun alpha , alpha <= y, y <= alpha) }}} where `alpha` is the unification variable that instantiates `x`. Now, from the givens, improvement gives a derived `[D] x~y`, but we can't actually use that to rewrite anything; we have no evidence. From the wanteds we can use improvement in two alternative ways: {{{ 1. (alpha <= y, y <= alpha) => [D] alpha ~ y 2. (x <= y, y <= alpha) => [D] x <= alpha (alpha <= y, y <= x) => [D] alpha <= x And combining the latter two we get [D] (alpha ~ x) }}} It is (2) that we want. But if we get (1) and fix `alpha := y`, we get an error `Can't unify (SomeFun x ~ SomeFun y)`. I think it's a fluke that this test has been working so far; in my new flatten-skolem work it has started failing, which is not unreasonable. What I HATE is that whether type checking succeeds or fails depends on some random choice about which constraint is processed first. The real bug is that the derived Given has no evidence, and can't be used for rewriting. I think Iavor is fixing this deficiency for. I speculate that the same problem might also show up with ordinary type-class functional dependencies, but I have not found a concrete example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8572: Building an empty module with profiling requires profiling libraries for integer-gmp
by GHC 24 Jan '16

24 Jan '16

#8572: Building an empty module with profiling requires profiling libraries for integer-gmp -------------------------------------------+------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- {{{ #!haskell {-# LANGUAGE NoImplicitPrelude #-} module A where }}} {{{ $ ghc-stage2 -prof -c A.hs Top level: Failed to load interface for ‛GHC.Integer.Type’ Perhaps you haven't installed the profiling libraries for package ‛integer-gmp’? Use -v to see a list of the files searched for. }}} I can't built module `A` without profiling libraries for `integer-gmp`, even though I don't use `integer-gmp` anywhere in the module. This happens because the `Tidy Core` pass attempts to look up the `mkInteger` name (in order to desugar integer literals) even when there are no integer literals in the module. The obvious fix is to lazily look up `mkInteger` in `Coreprep.lookupMkIntegerName`: {{{ #!diff diff --git a/compiler/coreSyn/CorePrep.lhs b/compiler/coreSyn/CorePrep.lhs index 5e0cd65..9836982 100644 --- a/compiler/coreSyn/CorePrep.lhs +++ b/compiler/coreSyn/CorePrep.lhs @@ -56,6 +56,7 @@ import Config import Data.Bits import Data.List ( mapAccumL ) import Control.Monad +import System.IO.Unsafe ( unsafeInterleaveIO ) \end{code} -- --------------------------------------------------------------------------- @@ -1119,6 +1120,7 @@ lookupMkIntegerName dflags hsc_env else if thisPackage dflags == integerPackageId then return $ panic "Can't use Integer in integer" else liftM tyThingId + $ unsafeInterleaveIO $ initTcForLookup hsc_env (tcLookupGlobal mkIntegerName) mkInitialCorePrepEnv :: DynFlags -> HscEnv -> IO CorePrepEnv }}} This way, we don't attempt to look up `mkInteger` until we actually need it, i.e. if there are integer literals that we must desugar. Relevant commits are 2ef5cd26db27543ac8664a3d18f45550d0109a8b and fdd552e0ecaa17300670a48562995040e1d6687e -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8572> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8285: unexpected behavior with encodeFloat on large inputs
by GHC 23 Jan '16

23 Jan '16

#8285: unexpected behavior with encodeFloat on large inputs --------------------------+------------------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: | Version: 7.7 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ benjamin scarlet discovered some unexpected behavior in encodeFloat today {{{ <bscarlet> > map (\x -> encodeFloat 1 (shiftL 1 x)) [30,31] [23:47:47] <lambdabot> [Infinity,0.0] [23:49:09] <arkeet> > encodeFloat 1 60 [23:49:10] <lambdabot> 1.152921504606847e18 [23:49:09] <arkeet> > encodeFloat 1 60 [23:49:10] <lambdabot> 1.152921504606847e18 [23:49:18] <arkeet> er. [23:50:21] <bscarlet> down in the sane range I suspect it's just fine. [23:50:43] <bscarlet> > encodeFloat 1 1000 [23:50:44] <lambdabot> 1.0715086071862673e301 [23:50:52] <bscarlet> > encodeFloat 1 10000 [23:50:53] <lambdabot> Infinity [23:50:58] <bscarlet> That's sane. [23:51:03] <arkeet> > encodeFloat 1 (2^31) [23:51:04] <lambdabot> 0.0 [23:51:13] <bscarlet> That's what I think is weird. [23:51:19] <carter> bscarlet floats are weird [23:51:23] <arkeet> > encodeFloat 1 (2^31-1) [23:51:24] <lambdabot> Infinity }}} Benjamin did a wee bit of investigation, and the problem seems to lie in https://github.com/ghc/packages-integer- gmp/blob/master/cbits/float.c#L177 in integer-gmp, where it deliberately doesn't handle the edge cases (probably worth investigating) if integer-simple has similar behavior or not -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4