August 2016 - ghc-tickets

[GHC] #11706: Increase precedence of statements (if-then-else, case-of, do)
by GHC 02 Feb '18

02 Feb '18

#11706: Increase precedence of statements (if-then-else, case-of, do) -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: ⊥ Component: Compiler | Version: (Parser) | 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: -------------------------------------+------------------------------------- Warning: Skip to the {{{TL; DR}}}, and maybe the {{{How it works}}} section; You don't want to read this. (I've warned you.) == The problem == We do it all the time: Writing that one dollar sign just before our expressions, just because Haskell can't parse it: {{{#!hs f x = g $ if x then {- ... -} else {- ... -} f x = g $ case x of {- ... -} f x = g $ do {- ... -} }}} However, we programmers are lazy and want to type as few characters as possible. Think about the precious characters we would save if we could write code this way: {{{#!hs f x = g if x then {- ... -} else {- ... -} f x = g case x of {- ... -} f x = g do {- ... -} }}} Wow, our productivity just shot up by a whopping 6%! However, this code looks ugly, noone would ever write this... Right? There has to be some way to catagorize this feature with others people would never use... == Pragmas to the rescue! == The {{{LANGUAGE}}} pragma! Of course! We can add a syntactic extension to enable above syntax! But how should we name it... {{{InlineStatements}}}? {{{InfixStatements}}}? {{{ParenthesizedStatements}}}? {{{IncreasedStatementPrecedence}}}? {{{StatementsWithoutParenthesis}}}? I don't know. I am [1] not the parents who might one day give birth to this feature. I am merely the one who conceptualized it. [1] (probably, unless this request remains unnoticed for another 20 years or so) == How it works == * Implicit parenthesis will be put around ''all'' statements, according to the following rules: 1. Parenthesis will be opened at the start of the statement. 2. Parenthesis will be closed at the end of the statement. The end of the statement is determined by 1. The curly brackets around the statement, or; 2. The indentation of the statement Basically, these are the rule Haskell already uses. Sorry if this is obvious, but some people seemed to get confused, so here's some examples: === (Correct) Examples === Examples are in the form: {{{#!hs implicitParenthesis -- New syntax explicitParenthesis -- Old syntax }}} Call {{{idM :: Monad m => m a -> m a}}} as {{{idM :: IO String -> IO String}}}. {{{#!hs idM do putStrLn "What's my name?" getLine idM (do { putStrLn "What's my name?"; getLine; }) }}} Create function {{{whatsMyName :: Maybe String -> String}}}. {{{#!hs whatsMyName x = id case x of Just name = "My name is " ++ name Nothing = "What's my name?" whatsMyName x = id (case x of { Just name = "My name is " ++ name; Nothing = "What's my name?"; }) }}} Another example using {{{let}}} and {{{if-then-else}}}. {{{#!hs main = putStrLn (++) "I've been tryna work it out... The square root of 69 is 8 something, right? " let eight_something = 8.306623862918075 in if sqrt 69 == eight_something then "Yeah" else "Oh na na" main = putStrLn ((++) "I've been tryna work it out... The square root of 69 is 8 something, right? " (let eight_something = 8.306623862918075 in (if sqrt 69 == eight_something then "Yeah" else "Oh na na")) }}} === Incorrect examples === {{{#!hs f do putStrLn "This won't work..." True f (do { putStrLn "This won't work..."; True; }) }}} {{{#!hs f do putStrLn "This won't work..." True -- Indented by extra space f (do { putStrLn "This won't work..."; True; }) }}} == TL; DR == What there is: {{{#!hs main = when $ do putStrLn "Parenthesis..." main = when True (do putStrLn "Parenthesis...") }}} What I want: {{{#!hs when (doBlocksNeedParenthesis) do putStrLn "This code is invalid." when (doBlocksNeedParenthesis) $ do putStrLn "This code is valid." when (doBlocksNeedParenthesis) (do putStrLn "This code is valid aswell.") when (thisIsImplemented) do putStrLn "These are all equal" when (thisIsImplemented) (do putStrLn "These are all equal") when (thisIsImplemented) $ do putStrLn "These are all equal" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11195: New pattern-match check can be non-performant
by GHC 01 Feb '18

01 Feb '18

#11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 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: -------------------------------------+------------------------------------- In my work in merging Phab:D808 (and originally pointed out by thomie), I ran into a peculiar bug: the new pattern-match check took gobs of memory (~10GB) to check !OptCoercion in the stage-2 compiler. My analysis got only as far as nailing the problem down to `pmTraverse`, which took 80% of the time, and got called roughly a gajillion times. To reproduce, simply compile !OptCoercion (with `-package ghc`) and you'll see your memory usage explode. So that you'll be able to build GHC until this is fixed, I've disable the pattern-match check in that file. There is a good chance that this is caused by an interaction between the pattern-match check and the type=kind code. I'm happy to probe further, but I'd want George's help. NB: This applies only after my patch is merged. Which should be today. For some value of today. Hopefully today's value of today. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10855: GHC rejects code that Haskell 2010 report accepts
by GHC 31 Jan '18

31 Jan '18

#10855: GHC rejects code that Haskell 2010 report accepts -------------------------------------+------------------------------------- Reporter: goldfire | 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 Revisions: | -------------------------------------+------------------------------------- According to [https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003 The Haskell 2010 Report], the following two modules should compile. But they don't, failing with parse errors: {{{ {-# LANGUAGE Haskell2010 #-} module Bug where bool = - case b of False -> 0; True -> (-1) }}} {{{ {-# LANGUAGE Haskell2010 #-} instance Num (IO a) where negate = id main = - do putStrLn "hi!" }}} Note the unary `-` signs. I'm not sure whether we should complicate the parser to fix these, but we should document the compliance-failure in the manual. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10855> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10074: Implement the 'Improved LLVM Backend' proposal
by GHC 31 Jan '18

31 Jan '18

#10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice thoughtpolice | Status: new Type: task | Milestone: 7.12.1 Priority: high | Version: Component: Compiler | Operating System: Unknown/Multiple (LLVM) | Type of failure: None/Unknown Keywords: llvm, | Blocked By: codegen | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: Phab:D530 | -------------------------------------+------------------------------------- This is a meta ticket designed to reflect the current implementation status of the 'Improved LLVM Backend' proposal, documented here: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #12245: Deriving Data at higher kinds
by GHC 31 Jan '18

31 Jan '18

#12245: Deriving Data at higher kinds -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Here's what [https://mail.haskell.org/pipermail/generics/2016-June/000564.html Lennart Spitzner wanted to do]: {{{ > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE DeriveDataTypeable #-} > {-# LANGUAGE FlexibleInstances #-} > > import Data.Data ( Data ) > > data Foo f = Foo (f Bool) (f Int) > > deriving instance Data (Foo []) > deriving instance Data (Foo Maybe) }}} Of course you can't derive `Data` for `Foo` because we don't know what `f` is, so Lennart is making multiple instances, one for each instance of `f`. It's a bit clumsy. What we would really like is {{{ deriving instance (forall a. Data => Data (f a)) => Data (Foo f) }}} but we don't have higher order instances yet! So Lennart is manually making two instances. This should work, but he gets {{{ > Main.hs: line 45, column 1: > Multiple declarations of ‘$cr2C’ > Declared at: Main.hs:44:1 > Main.hs:45:1 > Main.hs: line 45, column 1: > Multiple declarations of ‘$tr2D’ > Declared at: Main.hs:44:1 > Main.hs:45:1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10754: truncate /= double2Int
by GHC 28 Jan '18

28 Jan '18

#10754: truncate /= double2Int -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: truncate, | Operating System: Unknown/Multiple double2Int, rewrite, rule | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- There is a rule in libraries/base/GHC/Float.hs: {{{#!hs "truncate/Double->Int" truncate = double2Int }}} But it is not true for some values. Particularly, {{{#!hs let infinity = 1/0 :: Double truncate infinity :: Int == 0 double2Int infinity == -9223372036854775808 -- minBound }}} As a result, the value of {{{truncate (1/0 :: Double) :: Int}}} depends on optimization level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11138: Kill the terrible LLVM Mangler
by GHC 23 Jan '18

23 Jan '18

#11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since its introduction the LLVM backend has had a mangler which transforms assembler produced by LLVM. In the past this mangler was responsible for shuffling around code to make tables-next-to-code work, but the need for this has past with the resolution of #4213. At this point the only reason it exists is to mangle AVX instructions to 1. rewriting all symbols of type `@function` to `@object` to prevent symbol references from going through the PLT, which would be bad due to tables-next-to-code. 2. On x86_64, rewrite AVX instructions that require alignment to their unaligned counterparts, since the stack is only 16-byte aligned but these instructions require 32-byte alignment. While it's unclear that we will ever be able to discharge (1), it would be nice to investigate whether we can at least do something about (2) (there may even be performance to be gained!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12470: Move LLVM code generator to LLVM bitcode format
by GHC 23 Jan '18

23 Jan '18

#12470: Move LLVM code generator to LLVM bitcode format -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | 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: -------------------------------------+------------------------------------- Currently GHC produces LLVM's textual intermediate representation. While this is easy to produce, it's not the path recommended by LLVM's developers. Instead, they [[http://llvm.org/docs/DeveloperPolicy.html#ir- backwards-compatibility|recommend]] that compilers produce LLVM bitcode, which they maintain much stronger backwards compatibility guarantees on. It seems sensible to move the backend over to this format. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12470> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9885: ghc-pkg parser eats too much memory
by GHC 21 Jan '18

21 Jan '18

#9885: ghc-pkg parser eats too much memory -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Moderate (less | performance bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Parsing of spec files in ghc-pkg scales very poorly. The following script demonstrates memory consumption growth as a function of the number of tokens in ld-options (16K leads to ~6G) #!/bin/bash # Demonstrates memory consumption behavior of ghc-pkg as a function of # the number of ld-options arguments. for i in {10..14}; do size=$((1 << $i)) echo $size rm -fr a.packages /usr/bin/ghc-pkg init a.packages cat > a.spec <<EOF name: project id: project license: AllRightsReserved version: 1.0 EOF echo -n ld-options: >> a.spec for i in $(seq 1 $size); do echo -n "x "; done >> a.spec /usr/bin/time /usr/bin/ghc-pkg --global-package-db a.packages register --force a.spec done exit 0 # This was collected with ghc-7.6.3. 7.8.3 fares as badly. % bash a.sh 1024 Reading package info from "a.spec" ... done. 0.03user 0.00system 0:00.03elapsed 97%CPU (0avgtext+0avgdata 17848maxresident)k 0inputs+32outputs (0major+4973minor)pagefaults 0swaps 2048 Reading package info from "a.spec" ... done. 0.09user 0.01system 0:00.10elapsed 99%CPU (0avgtext+0avgdata 60872maxresident)k 0inputs+56outputs (0major+15723minor)pagefaults 0swaps 4096 Reading package info from "a.spec" ... done. 0.41user 0.07system 0:00.49elapsed 99%CPU (0avgtext+0avgdata 294340maxresident)k 0inputs+104outputs (0major+74090minor)pagefaults 0swaps 8192 Reading package info from "a.spec" ... done. 1.72user 0.30system 0:02.04elapsed 99%CPU (0avgtext+0avgdata 1168836maxresident)k 0inputs+192outputs (0major+292716minor)pagefaults 0swaps 16384 Reading package info from "a.spec" ... done. 9.11user 1.38system 0:10.51elapsed 99%CPU (0avgtext+0avgdata 5396932maxresident)k 0inputs+376outputs (0major+1349736minor)pagefaults 0swaps -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11645: Heap profiling - hp2ps: samples out of sequence
by GHC 21 Jan '18

21 Jan '18

#11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #664 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `make TEST=hpc_fork WAY=prof` is failing, but it has nothing to do with `hpc`. {{{ hp2ps: hpc_fork.hp, line 9, samples out of sequence hp2ps error when processing heap profile for hpc_fork }}} hpc_fork.hs: {{{ module main where import system.posix.process import control.concurrent main = do pid1 <- forkprocess $ do threaddelay 100000 pid2 <- forkprocess $ do threaddelay 100000 print () }}} To reproduce: {{{ $ ghc-8.0.1 hpc_fork.hs -fforce-recomp -prof $ ./hpc_fork +RTS -hc $ hp2ps hpc_fork.hp }}} Example hpc_fork.hp: {{{ JOB "hpc_fork +RTS -hc" DATE "Thu Feb 25 22:37 2016" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.000000 END_SAMPLE 0.000000 BEGIN_SAMPLE 0.005672 END_SAMPLE 0.005672 BEGIN_SAMPLE 0.003167 END_SAMPLE 0.003167 BEGIN_SAMPLE 0.003311 END_SAMPLE 0.003311 }}} This is a regression from 7.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12