March 2019 - ghc-tickets

[GHC] #16233: HIE file generation is inefficient
by GHC 04 Mar '19

04 Mar '19

#16233: HIE file generation is inefficient -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- Generating HIE files eats up a lot of memory and takes a long time. There are at least two big parts to this: * Every expression in the AST is desugared via `deSugarExpr` for the purpose of extracting a type. GHC ends up doing the same work multiple times for the same nodes. Ex: in order to desugar `HsApp _ fun arg`, GHC desugars both `fun` and `arg`, yet the HIE code doesn't cache that (so it ends up desugaring `fun` and `arg` at least once more). * There is a lot of stuff being written into these HIE files, making them quite big (even after compressing/deduplicating type information). One data point: the largest HIE file at time of writing is `Parser.hie`, which is 7.2MB, compared to just 58K for `Parser.hi`Q Writing large files is naturally going to take up memory and be slow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16233> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl
by GHC 04 Mar '19

04 Mar '19

#16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For the file {{{#!hs module ClassParens where class LiftingMonad (trans :: MTrans) where proof :: Monad m :- Monad (trans m) class LiftingMonad2 ((trans :: MTrans)) where proof :: Monad m :- Monad (trans m) }}} The parens around the kinded tyvars should be attached to the class declaration as a whole, they are attached to the tyvar instead, outside the span. An annotation must always be within the span it is contained in. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16212> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15729: Static GHCi can segfault when accessing .bss section in C
by GHC 04 Mar '19

04 Mar '19

#15729: Static GHCi can segfault when accessing .bss section in C --------------------------------------+------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- When an object file is statically linked, GHCi can return junk or segfault when trying to access data defined in .bss section via foreign call. {{{ watashi % ~/gao/ghc/inplace/bin/ghc-stage2 --info | grep Dynamic ,("Dynamic by default","NO") ,("GHC Dynamic","NO") watashi % cat bss.c int read_bss(int i) { static int bss[1 << 20]; return bss[i]; } watashi % ~/gao/ghc/inplace/bin/ghc-stage2 --interactive test.o GHCi, version 8.7.20180920: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/watashi/.ghci Prelude> :m + Foreign Foreign.C Prelude Foreign Foreign.C> foreign import ccall unsafe "read_bss" read_bss :: Int -> IO Int Prelude Foreign Foreign.C> read_bss 0 4294059519 Prelude Foreign Foreign.C> read_bss 1 65535 Prelude Foreign Foreign.C> mapM (read_bss . bit) [0 .. 19] zsh: segmentation fault (core dumped) ~/gao/ghc/inplace/bin/ghc-stage2 --interactive test.o }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol
by GHC 04 Mar '19

04 Mar '19

#15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (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: -------------------------------------+------------------------------------- When compiling code with `-prof -fPIC -fexternal-dynamic-refs`, the generated object file may contains R_X86_64_PC32 relocation to symbols defined in another object file. will add more details -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16198: Cmm string literals shouldn't be represented as [Word8]
by GHC 04 Mar '19

04 Mar '19

#16198: Cmm string literals shouldn't be represented as [Word8] -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- While we use ByteString to represent string literals in Core/STG, they are unpacked into [Word8] when compiled into Cmm. This is bad for performance, especially with large strings and there is no reason to do it. Patch coming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16222: PPC NCG: C calling convention violated for integers smaller than word size
by GHC 04 Mar '19

04 Mar '19

#16222: PPC NCG: C calling convention violated for integers smaller than word size -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 (FFI) | Keywords: big endian | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Incorrect result Test Case: | at runtime primops/should_run/PrimFFIInt8 | Blocked By: primops/should_run/PrimFFIInt16 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The C calling convention for powerpc64 and powerpc64le require simple integer types to be zero or sign extended to 64 bit. The PPC NCG assumes that all values have been promoted to word size but now we introduced integer operations on smaller than machine word size and in general we cannot assume that values have been promoted anymore. When a value is not promoted and passed to a foreign function on the stack that value will be in the wrong position within the stack slot on big endian systems and the function will deliver wrong results. On little endian systems we still get correct results as long as we stay in the smaller integer range. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16219: Backpack - TH+indefinite module interface file error
by GHC 04 Mar '19

04 Mar '19

#16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- Repro: https://github.com/LightAndLight/backpack-test I've been stuck on this for a while now. There's a weird interaction between the Template Haskell pragma and indefinite modules. When Template Haskell is enabled in this particular file (but TH features aren't used) I get an interface error. When I remove the pragma, the project successfully compiles. I hope I haven't made some trivial .cabal blunder. Anyway, I'm interested in potentially trying to fix this, but I've been digging around in GHC for a couple of days and figured it was time to ask for help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault
by GHC 04 Mar '19

04 Mar '19

#16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Keywords: llvm integer- | Operating System: Unknown/Multiple gmp | Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Although I haven't reproduced this locally yet, the `validate-x86_64 -linux-deb9-llvm` CI pipeline (which is allowed to fail) has continuously been failing for `print037(ghci-ext)`. Here's the relevant output: {{{ --- ghci.debugger/scripts/print037.run/print037.stdout.normalised 2019-01-19 11:37:48.698917882 +0000 +++ ghci.debugger/scripts/print037.run/print037.run.stdout.normalised 2019-01-19 11:37:48.698917882 +0000 @@ -1,5 +1,4 @@ smallNeg = -53 smallPos = 89 zero = 0 -largeNeg = -4123841823694876543987265438957349857349 -largePos = 5402398759384752938475029384750298347554 +ghc-stage2: ghc-iserv terminated (-11) *** unexpected failure for print037(ghci-ext) }}} Given that the crash happens only on large integers (i.e. not `S#`), something in the C FFI with the GMP code is probably to blame. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16227: T15897 causes CI failures due to timing out
by GHC 04 Mar '19

04 Mar '19

#16227: T15897 causes CI failures due to timing out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- For example: https://gitlab.haskell.org/ghc/ghc/-/jobs/16084 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16260: Use of plugins causes -XSafe to fail
by GHC 04 Mar '19

04 Mar '19

#16260: Use of plugins causes -XSafe to fail -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Use of plugins will mark safe inference as failed, even when the plugin does not modify anything. This can result in compile error when -XSafe is used. For example: {{{ $ cat DefaultPlugin.hs module DefaultPlugin (plugin) where import GhcPlugins plugin = defaultPlugin $ cat B.hs {-# OPTIONS_GHC -fplugin DefaultPlugin #-} module B (answer) where answer = 42 $ cat A.hs {-# LANGUAGE Safe #-} module A (main) where import B main = print answer $ ... A.hs:4:1: error: B: Can't be safely imported! The module itself isn't safe. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13