February 2018 - ghc-tickets

[GHC] #14755: Allow putting SCC annotations on class instance methods
by GHC 04 Feb '18

04 Feb '18

#14755: Allow putting SCC annotations on class instance methods -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Profiling | Version: 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: -------------------------------------+------------------------------------- Perhaps there's a way to do this that I don't know about. Here's a file: {{{ module Test where class C a where foo :: a -> String instance C Int where -- this would be a parse error: {-# SCC foo #-} foo a = show a }}} I want to put a cost center on `foo`. Like mentioned in the comment, doing that in the obvious way is a parse error. Interestingly `-fprof-auto-top` puts a cost center on `foo`. This came up when debugging #14637. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14755> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI
by GHC 04 Feb '18

04 Feb '18

#14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: capi capiffi | Operating System: Unknown/Multiple cpp | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the following simple module {{{#!hs {-# LANGUAGE CApiFFI #-} #include "Bar.hs.inc" module Foo where foreign import capi unsafe "cbits.h foo" c_foo :: Int -> IO () }}} The dependency information produced by `ghc -dep-suffix '' -M Foo.hs` is {{{ # DO NOT DELETE: Beginning of Haskell dependencies Foo.o : Foo.hs # DO NOT DELETE: End of Haskell dependencies }}} And neither mention the include header dependency `cbits.h` nor `Bar.hs.inc`. See also https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_co… #makefile-dependencies -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14757: ghc recompilation check doesn't take into account headers directly included by CApiFFI
by GHC 04 Feb '18

04 Feb '18

#14757: ghc recompilation check doesn't take into account headers directly included by CApiFFI -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: capi capiffi | Operating System: Unknown/Multiple cpp | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Continuing from #14756, given the following simple module {{{#!hs {-# LANGUAGE CPP, CApiFFI #-} #include "Bar.hs.inc" module Foo where foreign import capi unsafe "cbits.h foo" c_foo :: Int -> IO () }}} After having compiled `ghc -c Foo.hs` successfully, and second invocation of `ghc -c Foo.hs` - ...will properly recompile when `Bar.hs.inc` changes (or any of its recursive `#include`s!) (good!) - ...will fail to detect when `cbits.h` changes, and thus claim `compilation IS NOT required` (BAD!) Ideally, we should always run CPP for the CApiFFI-included, in order to detect when any recursive `#include`s inside `cbits.h` change, and use a recorded checksum to detect whether recompilation of the C wrapper (and thus re-linking of the haskell module; which currently forces resynthesizing the object files) is necessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14757> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers
by GHC 03 Feb '18

03 Feb '18

#14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #12537 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The comments in `compiler/prelude/primops.txt.pp` for both operations say "... Implies a full memory barrier." The implementation does not issue any barriers as exemplified by the 32-bit variants as can be seen in the excerpts from `libraries/ghc- prim/cbits/atomic.c`. {{{#!c StgWord hs_atomicread32(StgWord x) { return *(volatile StgWord32 *) x; } }}} and {{{#!c void hs_atomicwrite32(StgWord x, StgWord val) { *(volatile StgWord32 *) x = (StgWord32) val; } }}} The native code generator for X86/amd64 and the LLVM backend do not generate calls to these functions but generate the necessary barrier (`mfence`) directly and thus are not affected by this issue. There are no gcc `__sync_*` intrinsics for the two operations. The new `__atomic_*` intrinisics have the required operations but require gcc 4.7 or later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum#
by GHC 03 Feb '18

03 Feb '18

#14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I originally observed this panic in [https://travis-ci.org/haskell-compat /deriving-compat/jobs/329948624#L804 this Travis build]. The panic can be reduced to this file: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeFamilies #-} module Bug where import GHC.Base (getTag) import GHC.Exts (Int(..), tagToEnum#) data family TyFamilyEnum data instance TyFamilyEnum = TyFamilyEnum1 | TyFamilyEnum2 | TyFamilyEnum3 suc :: TyFamilyEnum -> TyFamilyEnum suc a_aaf8 = case getTag a_aaf8 of a_aaf9 -> if 2 == I# a_aaf9 then error "succ{TyFamilyEnum}: tried to take `succ' of last tag in enumeration" else case I# a_aaf9 + 1 of I# i_aafa -> tagToEnum# i_aafa :: TyFamilyEnum }}} In GHC 8.2.2, compiling this with optimization works fine. But in GHC 8.4.1-alpha, it panics: {{{ $ /opt/ghc/8.4.1/bin/ghc -fforce-recomp -O1 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.0.20171222 for x86_64-unknown-linux): Prelude.!!: index too large }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #6087: Join points need strictness analysis
by GHC 03 Feb '18

03 Feb '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by osa1): In mate with `-flate-dmd-anal` we get lots of new worker functions and the final program is quite different than the one without `-flate-dmd-anal`. I couldn't find yet what's causing the extra allocations as the changes are so big. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #14631: GHC 8.2.2 crashes when building the haskell-gi sample code
by GHC 02 Feb '18

02 Feb '18

#14631: GHC 8.2.2 crashes when building the haskell-gi sample code -------------------------------------+------------------------------------- Reporter: muscar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.2.2 crashes while building the haskell-gi sample code in a new project created with stack (see the attached project). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14736: unknown opcode in interpretBCO doesn't cause process termination in some circumstances
by GHC 02 Feb '18

02 Feb '18

#14736: unknown opcode in interpretBCO doesn't cause process termination in some circumstances ----------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- As part of my work on #14675, I ended up in a situation where `rts/Interpreter.c:interpretBCO` falls into its default case, which just does this: {{{#!c barf("interpretBCO: unknown or unimplemented opcode %d", (int)(bci & 0xFF)); }}} Which is fine. In the program from #14675, we are not processing the annotations with an external interpreter, the same runtime is compiling some module and running some code for the annotations, if my understanding is correct. And that process should therefore terminate. Except that it doesn't, not right away! And the example that uses the GHC API to load some simple module with an annotation just happily proceeds until it segfaults because `interpretBCO` didn't run to completion, probably therefore not pushing a suitable closure address or two somewhere or something along those lines. The expected behaviour here would be that the program crashes with the "unknown opcode" error message from above. So far the problem from #14675 has only been reproduced on ubuntu 16.04 with 8.4.1 alpha1, however I suspect that the bug I'm describing -- the program not terminating when we call `barf` while running code that we will splice in some module that we are compiling using the GHC API -- is independent of the particular distro or maybe even OS? Not sure, I haven't looked into that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14753: Assembly for stg_enter_info starts with a dead 'mov'
by GHC 02 Feb '18

02 Feb '18

#14753: Assembly for stg_enter_info starts with a dead 'mov' -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.4.1-alpha1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the course of my investigation in #14675, I happened to look at the x86_64 assembly for `stg_enter_info`, through gdb: {{{#!asm Breakpoint 2, stg_enter_info () at rts/HeapStackCheck.cmm:166 166 { (gdb) disassemble Dump of assembler code for function stg_enter_info: => 0x0000000002cf5900 <+0>: mov 0x0(%rbp),%rax 0x0000000002cf5904 <+4>: mov 0x8(%rbp),%rax 0x0000000002cf5908 <+8>: test $0x7,%al 0x0000000002cf590a <+10>: jne 0x2cf593d <stg_enter_info+61> 0x0000000002cf590c <+12>: mov (%rax),%rbx 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) 0x0000000002cf5913 <+19>: jb 0x2cf5947 <stg_enter_info+71> 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) 0x0000000002cf5919 <+25>: jb 0x2cf592d <stg_enter_info+45> 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) 0x0000000002cf591f <+31>: jb 0x2cf5933 <stg_enter_info+51> 0x0000000002cf5921 <+33>: mov %rbx,%rcx 0x0000000002cf5924 <+36>: mov %rax,%rbx 0x0000000002cf5927 <+39>: add $0x10,%rbp 0x0000000002cf592b <+43>: jmpq *%rcx 0x0000000002cf592d <+45>: cmpl $0x1b,-0x8(%rbx) 0x0000000002cf5931 <+49>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) 0x0000000002cf593b <+59>: jmp 0x2cf5908 <stg_enter_info+8> 0x0000000002cf593d <+61>: mov %rax,%rbx 0x0000000002cf5940 <+64>: add $0x10,%rbp 0x0000000002cf5944 <+68>: jmpq *0x0(%rbp) 0x0000000002cf5947 <+71>: cmpl $0xf,-0x8(%rbx) 0x0000000002cf594b <+75>: jb 0x2cf5969 <stg_enter_info+105> 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) 0x0000000002cf5951 <+81>: jb 0x2cf595d <stg_enter_info+93> 0x0000000002cf5953 <+83>: mov %rax,%rbx 0x0000000002cf5956 <+86>: add $0x10,%rbp 0x0000000002cf595a <+90>: jmpq *0x0(%rbp) 0x0000000002cf595d <+93>: movslq -0x8(%rbx),%rcx 0x0000000002cf5961 <+97>: cmp $0x17,%rcx 0x0000000002cf5965 <+101>: jne 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5967 <+103>: jmp 0x2cf5953 <stg_enter_info+83> 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) 0x0000000002cf596d <+109>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf596f <+111>: movslq -0x8(%rbx),%rbx 0x0000000002cf5973 <+115>: add $0xfffffffffffffff8,%rbx 0x0000000002cf5977 <+119>: jmpq *0x2e36d90(,%rbx,8) }}} Notice the first two instructions: {{{#!asm mov 0x0(%rbp),%rax mov 0x8(%rbp),%rax }}} We successively write two different things to `rax`, making the first `mov` effectively useless. I'm not quite sure the impact is of any significance but it still seems worth writing this down and addressing it at some point in the future, as there's just no way that first instruction will ever be useful. I think the assembly is generated from [https://github.com/ghc/ghc/blob/master/rts/HeapStackCheck.cmm#L164 this code], which in turns call [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L301 `ENTER`], which in turns calls [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L272 `LOAD_INFO`], which appears to rcorrespond to the first few instructions in the assembly I pasted, if we ignore the extra `mov`. (Assembly generated by ghc 8.4.1 built from the same commit as the alpha1 for 8.4.1 from hvr's PPA, in a 64bits Ubuntu VM. Not sure we generate a dead `mov` with the other codegens, haven't tested.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1