November 2016 - ghc-tickets

[GHC] #11629: reify returns Dec that use ConT instead of PromotedT
by GHC 29 Nov '16

29 Nov '16

#11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object
by GHC 29 Nov '16

29 Nov '16

#9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object ----------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Building HEAD on Debian wheezy with the Debian packaging setup fails: {{{ configure: Building in-tree ghc-pwd /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status configure: error: Building ghc-pwd failed }}} http://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.bu… This is possibly related to the Hardening flags added by Debian: {{{ ~ $ dpkg-buildflags --get LDFLAGS -Wl,-z,relro ~ $ dpkg-buildflags --get CFLAGS -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror =format-security }}} Other related bug might be #3668 and https://bugs.debian.org/712228 I’ll disable the hardening flags and see if it helps. The error first occurred 2014-03-27. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11656: Alllow static pointers to local closed definitions
by GHC 29 Nov '16

29 Nov '16

#11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- A limitation of the original patch implementing `-XStaticPointers` is that while the following all work, {{{#!hs t1 = static not t2 = static (\x -> case x of True -> False; False -> True) }}} the below does not: {{{#!hs t3 = static foo where foo True = False }}} Yet `foo` is perfectly "static": it's a closed expression that can readily be floated to top-level. So in short: `-XStaticPointers` should not consider only expressions with top-level identifiers, but in general any closed expression (which may involve local closed identifiers too). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12869: getChar doesn't work on a new Windows build
by GHC 28 Nov '16

28 Nov '16

#12869: getChar doesn't work on a new Windows build -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Last night I updated my PC to the 14965 Windows insider build. Today I notice that `getLine` no longer terminates (pressing enter just goes to a new line), but I'm suspecting that the root cause it that `getChar` returns `'\NUL'` no mather what is input. I've tried this both GHCi and in a compiled program. This is only broken if I set my codepage to 65001 (UTF-8). If I set it to something like 850 it works as it should. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12888: ‘Identity instance’: Outputable SDoc
by GHC 28 Nov '16

28 Nov '16

#12888: ‘Identity instance’: Outputable SDoc -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 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: -------------------------------------+------------------------------------- Is there reason why there isn't an ‘identity instance’¹ for `Outputable`? {{{#!hs class Outputable a where ppr :: a -> SDoc instance Outputabe SDoc where ppr :: SDoc -> SDoc ppr = id }}} A benefit: lets me always use `pprTraceIt :: Outputable a => String -> a -> a`, I know I can use `pprTrace` but I like not having to think about the type of what I'm tracing and neither functions work to debug something like `Either SDoc Name`. ---- ¹ For lack of a better term, something like {{{#!hs class Foo a where foo :: a -> A instance Foo A where foo :: A -> A foo = id @A }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12888> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12892: Improve type safety in the RTS
by GHC 28 Nov '16

28 Nov '16

#12892: Improve type safety in the RTS -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 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: -------------------------------------+------------------------------------- The RTS must (by virtue of its job) be type unsafe, but it doesn't need to be gratuitously so. Currently, there are a lot of dubious conversions, pointer casts that cast away `const`, and other questionable practices. This task covers improving the RTS's type safety. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12892> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12558: GHCi Segmentation fault/access violation in generated code
by GHC 28 Nov '16

28 Nov '16

#12558: GHCi Segmentation fault/access violation in generated code ------------------------------+------------------------------- Reporter: lazac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+------------------------------- GHCi crashes with the error message `Segmentation fault/access violation in generated code`. The problem arises when trying to use the [https://github.com/haskell-tools/haskell-tools Haskell Tools project] from GHCi. The program can be successfully compiled with the ghc compiler. The cause of this behavior is that there are elements thats type is computed by a type family application. When I changed the representation to eliminate these, the problem was gone. I can turn the problem on and off only by adding an import or removing it. To solve the problem simply comment out the modules that use the information with the complex calculated type, as done in the attached diff. To try out use a minimal program: {{{#!hs module Main where import Language.Haskell.Tools.Refactor main = demoRefactor "" "." "A" }}} Execute the `ghci -package ghc -isrc\ast;src\ast-ghc;sr c\ast-trf;src\ast-ppr;src\ast-gen;src\refactor;src Main` command from the project root. That will search for a simple `A.hs` file in the working directory. A minimalistic module is enough to trigger the problem: {{{#!hs module A where }}} PS: I tried to create a smaller example, but the problem just appears and disappears without "reason" when I try to modify the code. (For example importing a module that is not actually used.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12890: Stdcall - treating as CCall (bogus warning on win 64 bit)
by GHC 28 Nov '16

28 Nov '16

#12890: Stdcall - treating as CCall (bogus warning on win 64 bit) -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On windows you generally have the stdcall calling convention so you're average foreign import looks like this: {{{ foreign import stdcall "someFile.h getFoo" getFoo :: IO Foo }}} But on a 64 bit system, GHC warns: {{{ C:\Some\Path.hs:35:1: warning: [-Wunsupported-calling-conventions] * the 'stdcall' calling convention is unsupported on this platform, treating as ccall * When checking declaration: foreign import stdcall safe "static someFile.h getFoo" getFoo :: IO Foo }}} Both stdcall & ccall are not applicable to a 64 bit system as far as I know, and if it was really treating it as ccall it would have segfaulted at runtime. So the warning is a bit of a lie anyway. So far some developers generally have resorted to creating c preprocessor macros like this: [https://www.mail-archive.com/cvs- libraries(a)haskell.org/msg09725.html] Apologies if this is a dupe, I thought someone already reported this a long time ago but I can't seem to find the ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12889: memory leak
by GHC 28 Nov '16

28 Nov '16

#12889: memory leak -------------------------------------+------------------------------------- Reporter: zoranbosnjak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- This simple test program leaks memory for no obvious reason. {{{#!hs module Main where import Control.Monad import Control.Monad.Trans.Reader main :: IO () main = do runReaderT task () main task :: ReaderT () IO () task = forM_ [(1::Integer)..] $ \cnt -> do return cnt }}} However, there are some minor changes that (each individual change alone) make this program run in constant memory. 1. If I remove {{{#!hs module Main where }}} 2. If I remove recursive call to main 3. If I put task definition under the scope of main, like so {{{#!hs module Main where import Control.Monad import Control.Monad.Trans.Reader main :: IO () main = do runReaderT task () main where task :: ReaderT () IO () task = forM_ [(1::Integer)..] $ \cnt -> do return cnt }}} Any of the changes above make the program run OK, but I belive that this should be also true for the original test program. I am not sure where the problem is (if at all), but it's extremely difficult to isolate this kind of problem in the real application. Please check if anything can be done on the compiler or runtime to prevent this kind of problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12889> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12887: Make each RTS header self-contained
by GHC 28 Nov '16

28 Nov '16

#12887: Make each RTS header self-contained -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 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: -------------------------------------+------------------------------------- We should make each header in the RTS self-contained – that is, make sure that it is valid when included on its own. Otherwise, some tools (such as the YouCompleteMe semantic completion system for Vim) report spurious errors when editing header files. (Also, not sure if this belongs here, or as a task on Phabricator) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12887> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1