December 2018 - ghc-tickets

[GHC] Batch modify: #15465, #15464, #15462, #15461, #15459, #15454, ...
by GHC 28 Dec '18

28 Dec '18

Batch modification to #15465, #15464, #15462, #15461, #15459, #15454, #15452, #15449, #15448, #15437, #15435, #15434, #15433, #15429, #15427, #15425, #15424, #15420, #15416, #15414, #15411, #15409, #15403, #15402, #15395, #15394, #15392, #15391, #15389, #15388, #15384, #15382, #15381, #15378, #15377, #15376, #15375, #15364, #15362, #15358, #15356, #15354, #15345 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=15465%2C15464%2C15462%2C15461%2C15…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #16087, #16059, #16049, #16039, #16009, #15979, ...
by GHC 28 Dec '18

28 Dec '18

Batch modification to #16087, #16059, #16049, #16039, #16009, #15979, #15969, #15908, #15899, #15890, #15842, #15831, #15821, #15819, #15774, #15753, #15731, #15719, #15717, #15690, #15681, #15678, #15677, #15662, #15654, #15653, #15652, #15651, #15644, #15642, #15621, #15596, #15560, #15549, #15536, #15534, #15510, #15483, #15477, #15474, #15471, #15470, #15468 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=16087%2C16059%2C16049%2C16039%2C16…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #14123, #14251, #14873, #14899, #15519, #15768, ...
by GHC 28 Dec '18

28 Dec '18

Batch modification to #14123, #14251, #14873, #14899, #15519, #15768, #4012, #7411, #8228, #9370, #10946, #12178, #13233, #13426, #13576, #13624, #13763, #14013, #14226, #14270, #14980, #15267, #15418, #15455, #15488 by osa1: milestone to 8.10.1 Comment: Bumping milestones of some high and highest priority tickets. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=14123%2C14251%2C14873%2C14899%2C15…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8316: GHCi debugger segfaults when trying force a certain variable
by GHC 28 Dec '18

28 Dec '18

#8316: GHCi debugger segfaults when trying force a certain variable ------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The file Test.hs has following definitions: {{{ whnf :: a -> IO () whnf a = a `seq` (return ()) foo :: [Int] foo = [1..] }}} Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}} and bebugging foo like this: {{{ *Main> :b foo Breakpoint 0 activated at Test.hs:5:7-11 *Main> foo Stopped at Test.hs:5:7-11 _result :: [Int] = _ [Test.hs:5:7-11] *Main> :p foo foo = (_t1::[Int]) [Test.hs:5:7-11] *Main> whnf _t1 }}} results in this segault: {{{ <interactive>: internal error: TSO object entered! (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 28 Dec '18

28 Dec '18

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: patch Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15219 | Differential Rev(s): Phab:D4777 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: osa1 => (none) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16099: expose st_blksize field from fstat syscall
by GHC 27 Dec '18

27 Dec '18

#16099: expose st_blksize field from fstat syscall ----------------------------------------+--------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: libraries/unix | Version: 8.6.3 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The libc manual talks about buffer sizes. https://www.gnu.org/software/libc/manual/html_node/Controlling- Buffering.html They advise: Actually, you can get an even better value to use for the buffer size by means of the fstat system call: it is found in the st_blksize field of the file attributes. See Attribute Meanings. It's just that the st_blksize field it stepped over in the haskell definition of it: https://github.com/haskell/unix/blob/8d188ed8067af17dfcc2cd6cbbfda7294ba17e… Which goes directly from filesize to accesstime See also https://linux.die.net/man/2/fstat Would be nice to expose the additional fields as well -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15911: internal error: evacuate(static): strange closure type -127533247
by GHC 27 Dec '18

27 Dec '18

#15911: internal error: evacuate(static): strange closure type -127533247 -------------------------------------+------------------------------------- Reporter: bfraikin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- internal error: evacuate(static): strange closure type -127533247 (GHC version 8.4.4 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15939: StgLint fails because Stg bindings are not dependency-ordered
by GHC 27 Dec '18

27 Dec '18

#15939: StgLint fails because Stg bindings are not dependency-ordered -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9718 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After Phab:D5370 if I enable `-dstg-lint` when running the test suite I get about a dozen failures. I didn't check all, but most of them are because Stg bindings are not dependency-ordered, so some bindings come later in the list of bindings than their uses. I added a few debug prints to figure out if we ever have the bindings ordered in the pipeline. As far as I can see, by the time we desugar we have dependency-ordered bindings, but simplifier breaks the ordering by introducing uses. There are also "implicit" bindings introduced after simplifications (e.g. in CorePrep). Because of this by the time we start Stg generation we already have incorrect ordering. I think we have these options: - Don't assume dependency ordering in StgLint. Bring all top-level binders into the scope before linting bindings. - Somehow maintain dependency ordering in all of the Core passes so that by the time we start generating Stg we have an ordered list of bindings. (seems hard) - Sort Stg bindings in `CoreToStg`. (1) and (3) are equally simple, but (3) requires an extra pass over bindings. However, to be able to do the `CafInfo` analysis for #9718 efficiently we need (3), so I suggest implementing (3). We can then enable `-dstg-lint` in the test suite for all tests (add it to `TEST_HC_OPTS` in `testsuite/mk/test/mk`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16012: set/getAllocationCounter is broken in GHCi
by GHC 27 Dec '18

27 Dec '18

#16012: set/getAllocationCounter is broken in GHCi -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- It doesn't seem obvious why it shouldn't work in GHCi, hence the report. {{{ Prelude System.Mem> getAllocationCounter 9223372036854757447 Prelude System.Mem> setAllocationCounter 0 () Prelude System.Mem> getAllocationCounter 9223372036854758855 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16079: runTestTT from ghci caused a panic.
by GHC 27 Dec '18

27 Dec '18

#16079: runTestTT from ghci caused a panic. -------------------------------------+------------------------------------- Reporter: | Owner: (none) emacstheviking | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function. I have attached the tar-balled stack project for completeness, apologies for the size but I didn't want to risk omiotting anything important to you guys if this ever gets looked at in the melee! {{{ runTestTT classificationTests ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-linux): nameModule system $dShow_a5Xw Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1