January 2019 - ghc-tickets

[GHC] #16217: check-api-annotations should check that an annotation does not precede its span
by GHC 04 Mar '19

04 Mar '19

#16217: check-api-annotations should check that an annotation does not precede its span -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 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 an API annotation to be useful, it must not occur before the span it is enclosed in. So, for `check-api-annotation` output, a line such as {{{ ((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]), }}} should be flagged as an error, as the `AnnOpenP` location of `3:21` precedes its enclosing span of `3:22-26`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary
by GHC 04 Mar '19

04 Mar '19

#16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- hadrian.cabal specifies alex and happy as build-tools, we should make hadrian pass them to ./configure when hadrian is running with {{{-c}}} (Migrated from https://github.com/snowleopard/hadrian/issues/706) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[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