August 2018 - ghc-tickets

[GHC] #14784: RTS header files can't be used with a C++ compiler
by GHC 22 Nov '18

22 Nov '18

#14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: System | 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: -------------------------------------+------------------------------------- If you compile `m1.cpp`: {{{ #include "Rts.h" int main(int argc, char** argv) { } }}} with: {{{ g++ -g m1.cpp -std=c++11 -I includes/ -c }}} you get: {{{ In file included from includes/Rts.h:29:0, from m1.cpp:1: includes/Stg.h:29:3: error: #error __STDC_VERSION__ does not advertise C99 or later # error __STDC_VERSION__ does not advertise C99 or later ^ }}} It's not advertised anywhere that it should work, but it used to work. https://phabricator.haskell.org/D2045 is what introduced this check. Judging by https://stackoverflow.com/questions/48045243/ghc-gcc-compiler- issue-stdc-version-w-c99-from-stg-h-fails-for-every-packa, it affects GHC 8.2 and later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14784> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15216: plugins10 broken
by GHC 22 Nov '18

22 Nov '18

#15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- `plugins10` from Phab:D4342 is broken, but I am merging regardless and will sort it out later. {{{ =====> plugins10(normal) 7 of 22 [0, 1, 0] cd "./plugins/plugins10.run" && $MAKE -s --no-print-directory -C simple- plugin package.plugins10 TOP=/mnt/work/ghc/ghc/testsuite cd "./plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 Wrong exit code for plugins10()(expected 0 , actual 2 ) Stdout ( plugins10 ): parsePlugin() interfacePlugin: Prelude interfacePlugin: Language.Haskell.TH interfacePlugin: Language.Haskell.TH.Quote interfacePlugin: GHC.Float interfacePlugin: GHC.Base interfacePlugin: Language.Haskell.TH.Syntax interfacePlugin: GHC.Types typeCheckPlugin (rn) typeCheckPlugin (tc) interfacePlugin: GHC.Integer.Type parsePlugin(a) interfacePlugin: Language.Haskell.TH.Lib.Internal metaPlugin: return [] metaPlugin: quoteExp stringify "x" interfacePlugin: GHC.CString Stderr ( plugins10 ): plugins10.hs:9:5: fatal: cannot find object file for module ‘Simple.SourcePlugin’ while linking an interpreted expression make[2]: *** [Makefile:30: plugins10] Error 1 *** unexpected failure for plugins10(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition)
by GHC 22 Nov '18

22 Nov '18

#8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) ------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- == Abstract == Hi! I'm writing a compiler, which produces Haskell code. I've discovered it is impossible to keep currently used features / logic using GHC 7.7 instead of 7.6 Below is more detailed description of the problem: == The idea == I'm writing a [DSL][1], which compiles to Haskell. Users of this language can define own immutable data structures and associated functions. By associated function I mean a function, which belongs to a data structure. For example, user can write (in "pythonic" pseudocode): {{{#!python data Vector a: x,y,z :: a def method1(self, x): return x }}} (which is equivalent to the following code, but shows also, that associated functions beheva like type classes with open world assumption): {{{#!python data Vector a: x,y,z :: a def Vector.method1(self, x): return x }}} In this example, `method1` is a function associated with `Vector` data type, and can be used like `v.testid(5)` (where `v` is instance of `Vector` data type). I'm translating such code to Haskell code, but I'm facing a problem, which I'm trying to solve for a long time. == The problem == I'm trying to move the code from GHC 7.6 over GHC 7.7. The code works perfectly under GHC 7.6, but does not under GHC 7.7. I want to ask you how can I fix it to make it working in the new version of the compiler? == Example code == Lets see a simplified version of generated (by my compiler) Haskell code: {{{#!haskell {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FunctionalDependencies #-} import Data.Tuple.OneTuple ------------------------------ -- data types ------------------------------ data Vector a = Vector {x :: a, y :: a, z :: a} deriving (Show) -- the Vector_testid is used as wrapper over a function "testid". newtype Vector_testid a = Vector_testid a ------------------------------ -- sample function, which is associated to data type Vector ------------------------------ testid (v :: Vector a) x = x ------------------------------ -- problematic function (described later) ------------------------------ testx x = call (method1 x) $ OneTuple "test" ------------------------------ -- type classes ------------------------------ -- type class used to access "method1" associated function class Method1 cls m func | cls -> m, cls -> func where method1 :: cls -> m func -- simplified version of type class used to "evaluate" functions based on -- their input. For example: passing empty tuple as first argument of `call` -- indicates evaluating function with default arguments (in this example -- the mechanism of getting default arguments is not available) class Call a b where call :: a -> b ------------------------------ -- type classes instances ------------------------------ instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_testid out where method1 = (Vector_testid . testid) instance (base ~ (OneTuple t1 -> t2)) => Call (Vector_testid base) (OneTuple t1 -> t2) where call (Vector_testid val) = val ------------------------------ -- example usage ------------------------------ main = do let v = Vector (1::Int) (2::Int) (3::Int) -- following lines equals to a pseudocode of ` v.method1 "test" ` -- OneTuple is used to indicate, that we are passing single element. -- In case of more or less elements, ordinary tuples would be used. print $ call (method1 v) $ OneTuple "test" print $ testx v }}} The code compiles and works fine with GHC 7.6. When I'm trying to compile it with GHC 7.7, I'm getting following error: {{{ debug.hs:61:10: Illegal instance declaration for ‛Method1 (Vector a) Vector_testid out’ The liberal coverage condition fails in class ‛Method1’ for functional dependency: ‛cls -> func’ Reason: lhs type ‛Vector a’ does not determine rhs type ‛out’ In the instance declaration for ‛Method1 (Vector a) Vector_testid out’ }}} The error is caused by new rules of checking what functional dependencies can do, namely `liberal coverage condition` (as far as I know, this is `coverage condition` relaxed by using `-XUndecidableInstances`) == Some attemps to fix the problem == I was trying to overcome this problem by changing the definition of `Method1` to: {{{#!haskell class Method1 cls m func | cls -> m where method1 :: cls -> m func }}} Which resolves the problem with functional dependencies, but then the line: {{{#!haskell testx x = call (method1 x) $ OneTuple "test" }}} is not allowed anymore, causing a compile error (in both 7.6 and 7.7 versions): {{{ Could not deduce (Method1 cls m func0) arising from the ambiguity check for ‛testx’ from the context (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) bound by the inferred type for ‛testx’: (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s at debug.hs:50:1-44 The type variable ‛func0’ is ambiguous When checking that ‛testx’ has the inferred type ‛forall cls (m :: * -> *) func s. (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s’ Probable cause: the inferred type is ambiguous }}} It is also impossible to solve this issue using type families (as far as I know). If we replace `Method1` type class and instances with following code (or simmilar): {{{#!haskell class Method1 cls m | cls -> m where type Func cls method1 :: cls -> m (Func cls) instance Method1 (Vector a) Vector_testid where type Func (Vector a) = (t1->t1) method1 = (Vector_testid . testid) }}} We would get obvious error `Not in scope: type variable ‛t1’`, because type families does not allow to use types, which does not appear on LHS of type expression. == The final question == How can I make this idea work under GHC 7.7? I know the new `liberal coverage condition` allows GHC devs make some progress with type checking, but it should somehow be doable to port idea working in GHC 7.6 over never compiler version. (without forcing user of my DSL to introduce any further types - everything so far, like type class instances, I'm genarating using Template Haskell) Maybe is there a way to indroduce an extension, which will disable liberal coverage condition in such situations? There is also a StackOverflow discussion available, here: http://stackoverflow.com/questions/20778588/liberal-coverage-condition- introduced-in-ghc-7-7-breaks-code-valid-in-ghc-7-6 [1]: http://en.wikipedia.org/wiki/Domain-specific_language -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 71

[GHC] #15519: Minor code refactoring leads to drastic performance degradation
by GHC 21 Nov '18

21 Nov '18

#15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Hi! I've just observed an important performance problem. This code: {{{ test0 :: Text -> Result test0 src = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' p = many $! s1 <> s2 <> s3 <> s4 in runTokenParser p src {-# NOINLINE test0 #-} }}} runs over 10 times faster than this one: {{{ testGrammar1 :: Grammar Char testGrammar1 = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' in many $! s1 <> s2 <> s3 <> s4 {-# INLINE testGrammar1 #-} test1 :: Text -> Result test1 = runTokenParser testGrammar1 {-# NOINLINE test1 #-} }}} I've also observed another thing here, namely the former code runs also over 10 times faster than this code: {{{ test2 :: Text -> Result test2 src = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' p = X $! many $! s1 <> s2 <> s3 <> s4 in runTokenParser p src {-# NOINLINE test2 #-} }}} The only difference here is the `X` wrapper, while the `runTokenParser` is defined as `runTokenParser (X !a) = runTokenParser a`. I've created sample project for it here: https://github.com/wdanilo/ghc- bug-peg-optimization/blob/master/src/Main.hs In order to run it execute `stack build --exec test`. The results are: {{{ benchmarking test0 time 420.0 μs (417.6 μs .. 422.9 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 421.0 μs (419.2 μs .. 425.3 μs) std dev 9.286 μs (4.239 μs .. 15.30 μs) variance introduced by outliers: 14% (moderately inflated) benchmarking test1 time 6.069 ms (6.022 ms .. 6.123 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 6.065 ms (6.037 ms .. 6.117 ms) std dev 114.5 μs (74.30 μs .. 183.4 μs) benchmarking test2 time 6.070 ms (6.007 ms .. 6.137 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 6.067 ms (6.039 ms .. 6.129 ms) std dev 123.0 μs (63.88 μs .. 220.1 μs) benchmarking native time 428.0 μs (421.5 μs .. 437.4 μs) 0.998 R² (0.995 R² .. 1.000 R²) mean 427.1 μs (424.1 μs .. 434.7 μs) std dev 15.18 μs (5.678 μs .. 26.26 μs) variance introduced by outliers: 29% (moderately inflated) }}} Where "native" is just standard `Text.takeWhile ...`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15519> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #10445: Wrong stack space size when using -Ksize
by GHC 19 Nov '18

19 Nov '18

#10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 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: | -------------------------------------+------------------------------------- After compiling the first example in https://wiki.haskell.org/Performance/Accumulating_parameter: {{{ $ cat Test.hs len :: [a] -> Int len [] = 0 len (x:xs) = len xs + 1 main :: IO () main = print $ len [1..1000000] }}} {{{ $ ghc Test.hs -rtsopts }}} and running {{{ ./Test +RTS -K10K }}} GHC 7.6.3 reports {{{ Stack space overflow: current size 10240 bytes. }}} GHC 7.8.4 reports {{{ Stack space overflow: current size 33632 bytes. }}} and GHC 7.10.1 reports {{{ Stack space overflow: current size 99136 bytes. }}} GHC 7.8.3 and 7.10.1 report an incorrect stack space size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10347: Spurious "unused constructor" warning with Coercible
by GHC 19 Nov '18

19 Nov '18

#10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RoleAnnotations #-} module Bug (N, twiddle) where import Data.Coerce newtype N a = MkN Int type role N representational twiddle :: N a -> N b twiddle = coerce }}} I get {{{ Bug.hs:7:15: warning: Defined but not used: data constructor ‘MkN’ }}} But the constructor ''is'' used, in order to do the coercion. The role annotation is to force GHC to use the constructor to do the coercion -- otherwise, it might not have. This bug exists in 7.10 and in HEAD. I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15126: Opportunity to compress common info table representation.
by GHC 18 Nov '18

18 Nov '18

#15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: CodeGen | 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 looked at a lot of GHC produced assembly recently and noticed that most info tables describing stacks have the form: {{{ .align 8 .long SDjR_srt-(block_cHmk_info)+296 .long 0 .quad 6151 .quad 4294967326 }}} I haven't managed to dig fully into the description however some observations: * I noticed that the second .long directive almost always ends up being zero. * When figuring out what is what I realized the first quad (describing the pointers) is almost never fully used. * The last entrie (closure type + ?), here `4294967326` also seems quite repetitive given the size reserved. So I looked in detail at spectral/simple: * There are 2012 info tables of this sort with all of them having a zero in the second long. * We also reserve 8 byte for the stack layout. However only a single of these tables requires more than 4 byte. The compiled module has a size of 276384 Bytes, with 16092 being redundant: * 4 bytes for 0 * 4 bytes unused stack description * times 2012 info tables. That is an overhead of 5,8% which seems like quite a lot to me. The questions where to put that information is a different one. But only looking at the data and not how it is used tagging the pointer to the SRT table seems like a possibility. The info table description `4294967326` also appeared over 1k times. Maybe it's possible to come up with a more efficient encoding there as well. I didn't give it much thought yet since I don't have the time to do anything about it in the near future. But putting it here in case anyone is interested or looks into this in the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9207: Detect obvious cases of infinite recursion.
by GHC 18 Nov '18

18 Nov '18

#9207: Detect obvious cases of infinite recursion. --------------------------------------+------------------------------------ Reporter: mrugiero | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: infinite recursion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: --------------------------------------+------------------------------------ Pure functions are guaranteed to return the same value if the same arguments are used. Because of that, a compiler could be able to detect infinite recursion in the form of a function calling itself with the same arguments (case, some distracted programmer forgot to apply the function tail to a list). The way I see it, one of Haskell's main selling points is that it helps the programmer to avoid sources of bugs as much as it can, and infinite recursion is one of the few that stand unchecked. I specifically point to this example because both, I'm a newbie and made that newbie mistake, and think it shouldn't be hard to implement to the parsing stage of the compiler/interpreter. It probably should throw an error when this happens in pure functions, and maybe an opt-in warning if it happens in monads. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12906: GHC fails to typecheck Main module without main
by GHC 17 Nov '18

17 Nov '18

#12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given a `Main` module without a `main` value, GHC 8 reports the missing `main` and then exits, without bothering to typecheck the rest of the module. Previous versions, I believe, had the more useful behavior of reporting type errors regardless. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12525: Internal identifiers creeping into :show bindings
by GHC 17 Nov '18

17 Nov '18

#12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list. {{{#!html <pre class="wiki"> GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help > :show bindings > x = () > :show bindings <b>$trModule :: GHC.Types.Module = _</b> x :: () = _ > class Foo a > :show bindings x :: () = _ class Foo a <b>$tcFoo :: GHC.Types.TyCon = _ $tc'C:Foo :: GHC.Types.TyCon = _ $trModule :: GHC.Types.Module = _</b> </pre> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5