September 2015 - ghc-tickets

[GHC] #8082: Ordering of assembly blocks affects performance
by GHC 10 May '17

10 May '17

#8082: Ordering of assembly blocks affects performance ----------------------------------+--------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- During my work on #6135 I noticed that performance of reverse-complem benchmark in nofib depends highly on the order in which assembly block are laid out. With my patches I am consistently getting a 18-20% speed-up. In theory my patches should not impact performance of existing programs, but for some reason they affect the ordering of generated assembly blocks. On of the earlier versions of my patch I noticed that kahan benchmark suffered a 16% performance hit and again the only difference I noticed in the generated assembly was ordering of blocks. I did a more in-depth investigation in case of kahan and it turned out that this difference results from the way Core is generated: the difference between HEAD and my patches was that a worker function had its three parameters passed in different order. I did not investigate this for reverse-complem because Core is considerably larger, but I could spend some time on it if it might be relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8332: hp2ps does not escape parentheses
by GHC 09 May '17

09 May '17

#8332: hp2ps does not escape parentheses ------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | 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: | ------------------------------------+------------------------------------- If some symbol name in the key includes a (, but is cut off before the ), hp2ps generates an invalid postscript file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code
by GHC 07 May '17

07 May '17

#8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code -------------------------+------------------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- {{{ {-# OPTIONS_GHC -Wall #-} module A where data ABC = A | B | C abc :: ABC -> Int abc x = case x of A -> 1 }}} {{{ $ ghc -fno-code -fforce-recomp /tmp/A.hs [1 of 1] Compiling A ( /tmp/A.hs, nothing ) }}} {{{ $ ghc -fobject-code -fforce-recomp /tmp/A.hs [1 of 1] Compiling A ( /tmp/A.hs, /tmp/A.o ) /tmp/A.hs:7:9: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: B C }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10431: EqualityConstraints extension?
by GHC 06 May '17

06 May '17

#10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, writing an equality constraint in a type requires at least one of the `GADTs` or `TypeFamilies` extensions. However, each of these has other effects. Could we have an `EqualityConstraints` extension to permit equality constraints in types, but neither GADTs nor type families? Presumably this extension should imply `MonoLocalBinds`. The `GADTs` extension could then become precisely the conjunction of `GADTSyntax`, `EqualityConstraints` and `ExistentialQuantification`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9557: Deriving instances is slow
by GHC 06 May '17

06 May '17

#9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | 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: -------------------------------------+------------------------------------- Let's take [https://raw.githubusercontent.com/haskell-suite/haskell-src- exts/8e0153d33b66add96fd5606614ce7938d2029510/src/Language/Haskell/Exts/Annotated/Syntax.hs this file] (from haskell-src-exts) and build it with -O0. On my machine it takes 55s. If we remove deriving of all classes except Functor (which is the only one used by the module itself), the time will drop down to 4s. Different classes vary in their compile-time cost, but there's no single culprit. Among the costly ones are Generic, Data, Show, Ord. haskell-src-exts users are very annoyed by its long compile time, about 10 minutes, especially because we don't compile with -O0 by default. It would be nice to get this fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #10230: multiline literals doesn't work with CPP extension.
by GHC 02 May '17

02 May '17

#10230: multiline literals doesn't work with CPP extension. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If LANGUAGE CPP is enabled then multiline literals stops working. Steps to reproduce. 1. write a program with multiline literal: cat 1.hs {{{#!hs test = "mutli\ \line" main = putStrLn test }}} 2. it should compile without CPP: ghc 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) Linking 1 ... 3. compile it with CPP extension Expected result: program compiles {{{ ghc 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) Linking 1 ... }}} Actual result: compilation breaks {{{ ghc -XCPP 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) [flags changed] 1.hs:1:18: lexical error in string/character literal at character 'l' }}} At least ghc-7.8.4 and ghc-7.10 are affected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8443: cannot find normal object file when compiling TH code
by GHC 01 May '17

01 May '17

#8443: cannot find normal object file when compiling TH code ----------------------------+---------------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects valid program (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Unfortunately, I haven't been able to whittle this down to a smaller test case. In order to reproduce, just run `cabal install yesod-core-1.2.4.5 --enable-tests`. The result is: {{{ test/YesodCoreTest/NoOverloadedStrings.hs:16:26: cannot find normal object file ‛dist/build/tests/tests- tmp/YesodCoreTest/NoOverloadedStringsSub.dyn_o’ while linking an interpreted expression }}} Tested using: The Glorious Glasgow Haskell Compilation System, version 7.7.20131012 cabal-install version 1.18.0.2 using version 1.18.0 of the Cabal library I'm on Ubuntu 12.04 64-bit. Compiling with GHC 7.6.3 and 7.4.2 works correctly. Let me know if there's any other information I can provide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8996: mark more things as const in C codegen
by GHC 24 Apr '17

24 Apr '17

#8996: mark more things as const in C codegen -------------------------------------------+------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 Keywords: | 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: -------------------------------------------+------------------------------- Recently i've tried to build ghc-7.8.2 on ia64 and it overflows so called "short data" section. (it's where global 'static' variables live). I've looked at low-hanging fruits of squashing such global "variables". One source of them seems to be a string literal. Consider one-line module: {{{ module B (v) where v = "hello" }}} in '''-fvia-C''' (or unreg) mode it generates code like {{{ static char gibberish_str[] = "hello"; }}} It uselessly eats data section. The patch switches generator to emit: {{{ static const char gibberish_str[] = "hello"; }}} Some notes: 1. as far as I see native codegens already put ot to .rodata, thus it should be safe. 2. I likely didn't cover more cases, like - RelocatableReadOnlyData - and mysterious '''pprTop (CmmData _section (Statics lbl [CmmUninitialised size]))''' Size of unreg-stage2 on amd64 before and after the patch: {{{ $ size inplace/lib/bin/ghc-stage2 (unpatched) text data bss dec hex filename 81986382 20776344 44096 102806822 620b526 inplace/lib/bin/ghc-stage2 $ size inplace/lib/bin/ghc-stage2 (patched) text data bss dec hex filename 83648494 19062936 44096 102755526 61fecc6 inplace/lib/bin/ghc-stage2 }}} Text section increased for 1.6MBs (consts moved here, likely .rodata actually), data section decreased for 1.7MBs. I think with minor fiddling with linker flags we can merge equal constants later on. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10709: Using ($) allows sneaky impredicativity on its left
by GHC 24 Apr '17

24 Apr '17

#10709: Using ($) allows sneaky impredicativity on its left -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Observe the following shady interaction with GHCi: {{{ GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.IO Prelude GHC.IO> import Control.Monad Prelude GHC.IO Control.Monad> :t mask mask :: forall b. ((forall a. IO a -> IO a) -> IO b) -> IO b Prelude GHC.IO Control.Monad> :t replicateM 2 . mask <interactive>:1:16: Couldn't match type ‘a’ with ‘(forall a2. IO a2 -> IO a2) -> IO a1’ ‘a’ is a rigid type variable bound by the inferred type of it :: a -> IO [a1] at Top level Expected type: a -> IO a1 Actual type: ((forall a. IO a -> IO a) -> IO a1) -> IO a1 In the second argument of ‘(.)’, namely ‘mask’ In the expression: replicateM 2 . mask Prelude GHC.IO Control.Monad> :t (replicateM 2 . mask) undefined <interactive>:1:17: Cannot instantiate unification variable ‘a0’ with a type involving foralls: (forall a1. IO a1 -> IO a1) -> IO a Perhaps you want ImpredicativeTypes In the second argument of ‘(.)’, namely ‘mask’ In the expression: replicateM 2 . mask Prelude GHC.IO Control.Monad> :t (replicateM 2 . mask) $ undefined (replicateM 2 . mask) $ undefined :: forall a. IO [a] }}} Due to the way that GHC processes `($)`, it allows this form of impredicativity on the LHS of `($)`. This case is inspired by https://github.com/ghc/nofib/blob/master/smp/threads006/Main.hs which contains the line {{{ tids <- replicateM nthreads . mask $ \_ -> forkIO $ return () }}} I think that line should be rejected. The problem stems from the treatment of `OpenKind` as described in `Note [OpenTypeKind accepts foralls]` in TcMType. Unrelated work changes this behavior by rejecting the nofib program. The point of this ticket is to provoke discussion about what is right and what is wrong here, not to request a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8808: ImpredicativeTypes type checking fails depending on syntax of arguments
by GHC 24 Apr '17

24 Apr '17

#8808: ImpredicativeTypes type checking fails depending on syntax of arguments -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- g1 and g2 below type check, but g1', g2', and g2'' don't even though the types are exactly the same. {{{ {-# LANGUAGE ImpredicativeTypes, NoMonomorphismRestriction #-} module Test where f1 :: Maybe (forall a. [a] -> [a]) -> Maybe ([Int], [Char]) f1 (Just g) = Just (g [3], g "hello") f1 Nothing = Nothing f2 :: [forall a. [a] -> [a]] -> Maybe ([Int], [Char]) f2 [g] = Just (g [3], g "hello") f2 [] = Nothing g1 = (f1 . Just) reverse g1' = f1 (Just reverse) g2 = f2 [reverse] g2' = f2 ((:[]) reverse) g2'' = f2 (reverse : []) }}} Compiling it with HEAD gives these errors: {{{ [1 of 1] Compiling Test ( test.hs, test.o ) test.hs:12:16: Couldn't match expected type ‛forall a. [a] -> [a]’ with actual type ‛[a2] -> [a2]’ In the first argument of ‛Just’, namely ‛reverse’ In the first argument of ‛f1’, namely ‛(Just reverse)’ test.hs:15:17: Couldn't match expected type ‛forall a. [a] -> [a]’ with actual type ‛[a0] -> [a0]’ In the first argument of ‛: []’, namely ‛reverse’ In the first argument of ‛f2’, namely ‛((: []) reverse)’ test.hs:16:12: Couldn't match expected type ‛forall a. [a] -> [a]’ with actual type ‛[a1] -> [a1]’ In the first argument of ‛(:)’, namely ‛reverse’ In the first argument of ‛f2’, namely ‛(reverse : [])’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8808> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2