February 2019 - ghc-tickets

[GHC] #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications
by GHC 04 Mar '19

04 Mar '19

#16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.7 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When you compile this file with GHC 8.6.3 and HEAD: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Data.Kind type F = $([t| (Maybe :: Type -> Type) Int |]) }}} You get two different results: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:12-45: Splicing type [t| (Maybe :: Type -> Type) Int |] ======> (Maybe :: Type -> Type) Int $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:12-45: Splicing type [t| (Maybe :: Type -> Type) Int |] ======> Maybe :: Type -> Type Int }}} Notice how in the GHC HEAD output, GHC forgets to put parentheses around `Maybe :: Type -> Type`, leading to the utterly nonsensical type `Maybe :: Type -> Type Int`. The commit that introduced this regression is [https://gitlab.haskell.org/ghc/ghc/commit/ae2c9b40f5b6bf272251d1f4107c60003… ae2c9b40f5b6bf272251d1f4107c60003f541b62]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16210: Hadrian devel2 flavour builds profiling way
by GHC 04 Mar '19

04 Mar '19

#16210: Hadrian devel2 flavour builds profiling way -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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 the make build system `devel2` doesn't build profiled libraries but hadrian does. This makes the build quite a lot slower. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set
by GHC 04 Mar '19

04 Mar '19

#16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set -------------------------------------+------------------------------------- Reporter: ethercrow | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I started implementing this in https://gitlab.haskell.org/ghc/ghc/merge_requests/27 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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