December 2016 - ghc-tickets

[GHC] #13010: module imports form a cycle instead of failing to parse
by GHC 20 Dec '16

20 Dec '16

#13010: module imports form a cycle instead of failing to parse -------------------------------------+------------------------------------- Reporter: MarcelineVQ | 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: -------------------------------------+------------------------------------- Some issue of parsing is causing certain module imports not to respect the proper format for a module name: `modid → {conid .} conid (modules)` A module import ending in numbers or a dot may be treated as if the . or .<numbers> weren't there. I would expect these to be parse errors instead of falling back to their 'parent', that's surely vague so here's examples. Minimally: `echo "module Lib where import Lib. " > test.hs && ghc test.hs` `echo "module Lib where import Lib.123 " > test.hs && ghc test.hs` Will both result in: {{{ Module imports form a cycle: module ‘Lib’ (test.hs) imports itself }}} This is an error because it's not importing itself, it's importing Lib. or Lib.123 which are invalid module names. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES
by GHC 20 Dec '16

20 Dec '16

#7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghc-e/should_run/T2228 Blocked By: | Blocking: Related Tickets: #2228 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: This is still not fixed, it seems like no one is terribly eager to see it fixed, and the fix won't be terrible simple. Consequently I'm going to un- milestone this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7298#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5775: Inconsistency in demand analysis
by GHC 20 Dec '16

20 Dec '16

#5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Bumping off to 8.4 due to lack of owner. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5775#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 19 Dec '16

19 Dec '16

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Phab:D2861 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"c0c1f801f4ca26f1db68ac527341a1cf051cb7d6/ghc" c0c1f801/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c0c1f801f4ca26f1db68ac527341a1cf051cb7d6" Mark T8089 as unbroken since #7325 is now resolved }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11522: maxStkSize can overflow
by GHC 19 Dec '16

19 Dec '16

#11522: maxStkSize can overflow -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.4 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 `maxStkSize` field of `GC_FLAGS` is a `nat`, or `unsigned int`. It's measured in words, but still 32G is not an unreasonable amount of memory by today's standards. Maybe it's unlikely that anyone would want to set the stack size limit to more than 32G. But if you happen to have just over 40G of physical memory then the default stack size limit will overflow to a value just above zero and then Bad Things would happen. If we want to actually enforce stack limits that are greater than 2^32^ words, we would need to increase the size of the `tot_stack_size` field of a TSO also. Simple test of overflow behavior: `ghci +RTS -K32.0001G` will exit with a stack overflow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11502: Scrutinize use of 'long' in rts/
by GHC 19 Dec '16

19 Dec '16

#11502: Scrutinize use of 'long' in rts/ -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 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: -------------------------------------+------------------------------------- In commit 53055bb5023e8cc145ad8a9cd36ac56cee4695b0 (#5656), several uses of `int` in the rts were replaced by `long`, to avoid potential overflows for some calculations. On Windows though, `int` and `long` have the same size (4 bytes). Carefully go through all uses of `long` in `rts/`, and replace by one of the types from `includes/stg/Types.h`: * `long` -> `StgInt` or `StgInt64` * `unsigned long` -> `StgWord` or `StgWord64` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12995: interpetBCO doesn't get stripped from executables
by GHC 19 Dec '16

19 Dec '16

#12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: footprint | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Looking at the symbols linked into a simple Hello world program (e.g. with `nm -S --size-sort hello_world`), interpretBCO from the RTS is one of the larger functions. Unless I'm missing something, a compiled program shouldn't need the bytecode interpreter. The reason it gets linked and not dead-code stripped is that the scheduler has a hardcoded reference to it in `case ThreadInterpret:`, and figuring out if that particular what_next value is possible is out of reach of the linker. I'm thinking the ThreadInterpret state could be removed, and replaced with a more generic "resume by calling C function" state, with a function pointer on the stack. Paths that enter this state would push a function pointer to interpretBCO, and so the linker will link against interpretBCO iff it's actually used. Or perhaps it would be possible to have the interpreter entry point follow STG calling conventions and use ThreadRunGHC? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13007: ghc-options -threaded present but -N option unrecognised on ARM
by GHC 19 Dec '16

19 Dec '16

#13007: ghc-options -threaded present but -N option unrecognised on ARM -------------------------------------+------------------------------------- Reporter: tmpz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: arm, | Operating System: Linux raspberrypi, raspbian, rts, | threaded | Type of failure: Incorrect result Architecture: arm | at runtime Test Case: | Blocked By: http://allocinit.io/haskell | /haskell-on-raspberry-pi-3/ | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling a program on ARM (Raspberry PI 3, OS: Raspbian Jessi) with ghc it is possible to specify as runtime options {{{ -threaded -rtsopts -with-rtsopts=-N }}} However when running the program with -N, -N is not a recognised option. See output here http://pastebin.com/sKjfkRtq Running with --info gives the following http://pastebin.com/q36Ef7y4 showing that ("RTS way", "rts_thr") is available. Investigation already done here: https://www.reddit.com/r/haskell/comments/5j0u36/getting_haskell_and_stack_… Steps used to get ghc on the system: http://allocinit.io/haskell/haskell- on-raspberry-pi-3/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots
by GHC 19 Dec '16

19 Dec '16

#10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: | Owner: scpmw thoughtpolice | Status: new Type: bug | Milestone: 7.10.1 Priority: high | Version: 7.10.1-rc1 Component: Profiling | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9961 Blocking: | Differential Revisions: Phab:D616 | -------------------------------------+------------------------------------- Split off from #9961 - the profiling results while debugging erroneously reported that most cost centre profiles were a result of `lintAnnots`, as opposed to `CSE`. This is a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12819: Pattern synonym signatures are not validity-checked
by GHC 19 Dec '16

19 Dec '16

#12819: Pattern synonym signatures are not validity-checked -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ponder this garbage: {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns, TypeFamilies, KindSignatures #-} module Bug where type family F a -- F :: * -> * data T :: (* -> *) -> * pattern Q :: T F -> String pattern Q x <- (undefined -> x) }}} This is accepted by GHC 8.0.1 and HEAD. But it has an unsaturated type family! Urk! The problem is that `TcSigs.tcPatSynSig` never does validity checking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3