- ghc-tickets - Haskell.org

Re: [GHC] #7494: Allow compatible type synonyms to be the return type of a GADT data constructor.
by GHC 22 Feb '16

22 Feb '16

#7494: Allow compatible type synonyms to be the return type of a GADT data constructor. -------------------------------------+------------------------------------- Reporter: topi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: GADT, GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7494#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11537: GHC fails to compile if source is in /ghc
by GHC 22 Feb '16

22 Feb '16

#11537: GHC fails to compile if source is in /ghc -------------------------------------+------------------------------------- Reporter: wereHamster | 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: -------------------------------------+------------------------------------- I was building GHC in a docker image and was ignorant what the $PWD is (it is / in case you were wondering). So I cloned GHC into /ghc, and attempted to build it from there. Eventually the build fails because there is a sed expression `'s|$(TOP)/|...'` which rewrites some include paths to nonesense: /usr/lib/ghc/include/... -> /usr/libinclude/... Anchoring the expression (`'s|^$(TOP)/|...'`) helped the build process to continue past that point, but I haven't completed it due to other issue, so there may be other places where $(TOP) == /ghc breaks the build. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2289: Needless reboxing of values when returning from a tight loop
by GHC 21 Feb '16

21 Feb '16

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by twhitehead): Thanks for feedback. I follow that `loop2` in itself is not strict in the accumulators `au` and `ad`. It would seem GHC considers the context, however, as it did go ahead and create a version strict in `au` and `ad` (i.e., `main_$s$wloop2` is clearly specialized to take `au` and `ad` as unboxed `Int#`s). {{{ #!haskell main_$s$wloop2 [Occ=LoopBreaker] :: Int# -> Int# -> Int# -> (# Int, Int #) }}} Possibly the only issue left here is indeed the nested CPR then? At least it is all I can see really different from this single-return-value variant in which GHC wonderfully eliminates all boxing and unboxing. {{{ #!haskell main :: IO () main = case loop1 100 10 of a -> print a loop1 :: Int -> Int -> Int loop1 n a | n > 0 = loop1 (n-1) (-a) | otherwise = a }}} {{{ #!haskell Rec { $wloop1 :: Int# -> Int# -> Int# $wloop1 = \ (ww_s3th :: Int#) (ww1_s3tl :: Int#) -> case tagToEnum# (># ww_s3th 0) of _ { False -> ww1_s3tl; True -> $wloop1 (-# ww_s3th 1) (negateInt# ww1_s3tl) } end Rec } }}} I'm also not sure I follow you on the only-one-specialization rule. From looking at core dumps it seems GHC does do multiple specializations. For example, 1. adding an export of `loop2` causes a purely non-strict version to be generated and 2. adding a `case loop2 100 (10,undefined) of (au,_) -> ...` causes a strict-only-in-the-first-argument version to be generated all in the same code and in addition to `main_$s$wloop2` above. Perhaps things have been relaxed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2289#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7650: can't use combining characters in identifiers
by GHC 21 Feb '16

21 Feb '16

#7650: can't use combining characters in identifiers -------------------------------------+------------------------------------- Reporter: guest | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 (Parser) | Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1938 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * differential: => Phab:D1938 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7650#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors
by GHC 21 Feb '16

21 Feb '16

#11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | 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: #1544, #11529 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I run the following program `test-show.hs` on ghc 7.10.3: {{{#!hs data Y = Д星 String String deriving (Eq, Ord, Show, Read) data X = String :☆ String deriving (Eq, Ord, Show, Read) main :: IO () main = do let y = Д星 "" "" d = 0 print $ map fromEnum $ show y print $ (y, "") `elem` (readsPrec d (showsPrec d y "")) print $ (read $ show y :: Y) let x = "" :☆ "" d = 0 print $ map fromEnum $ show x print $ (x, "") `elem` (readsPrec d (showsPrec d x "")) print $ (read $ show x :: X) }}} I got the following results: {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ stack runhaskell test-show.hs [1044,26143,32,34,34,32,34,34] True Д星 "" "" [34,34,32,58,9734,32,34,34] False test-show.hs: Prelude.read: no parse }}} This behavior does not conform to Section 11.4 of Haskell 2010 Language Specification: https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18600… : > It should be the case that > (x,"") is an element of (readsPrec d (showsPrec d x "")) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11535> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 21 Feb '16

21 Feb '16

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => runghc/T6132 * status: new => closed * resolution: => fixed Comment: This was fixed in commit 7b0695a887c13a431f898d89938e127faa3f4585 (ghc-7.8.1): {{{ Author: Austin Seipp <aseipp(a)pobox.com> Date: Mon Jun 17 06:12:08 2013 -0500 Use assembler-with-cpp mode when running CPP. This is needed because Clang is very strict about C99 macro rules, which dictate that '#' in a body must have a token immediately following it for string-ification. In practice we break this all the time, because we do very weird stuff like: #define FOOBAR(xyz) \ {-# SOME PRAGMA #-} \ baz :: (xyz) \ baz = ... where the leading '#' in in the macro body clearly breaks this rule. Signed-off-by: Austin Seipp <aseipp(a)pobox.com> }}} Hurray Austin! I added a test. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 21 Feb '16

21 Feb '16

#6132: Can't use both shebang line and #ifdef declarations in the same file. ----------------------------------------------+---------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.0.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects valid program | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------------------+---------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"0b00add03043804211f567a3d0810114c0274252/ghc" 0b00add0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0b00add03043804211f567a3d0810114c0274252" Add test for #6132: hash bang + CPP }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11615: ghci -threaded
by GHC 21 Feb '16

21 Feb '16

#11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | 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: -------------------------------------+------------------------------------- ... gives: Warning: -debug, -threaded and -ticky are ignored by GHCi How can I use -threaded in ghci? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11615> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #2289: Needless reboxing of values when returning from a tight loop
by GHC 21 Feb '16

21 Feb '16

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Your example combines two issues. The big one is that you can in fact call `loop2` like this: {{{ main = case loop2 100 (undefined,undefined) of (_,_) -> return () }}} and it will terminate without evaluating `undefined`. So GHC can't eagerly evaluate `au+1` and `ad-1`, so there is thunk build-up in the argument pair, that eventually becomes the result pair. To fix this you could either * return a strict pair (`data P = P !Int !Int`, `| otherwise = P au ad`), which might be inconvenient, or * manually make the return tuple strict ({{{| otherwise = au `seq` ad `seq` (au,ad)}}}). Then, the second issue, which is the one I think you are interested in, is whether after one of these changes, the unboxed tuple returned by `loop2` contains boxed `Int`s or unboxed `Int#`s. (It can't very well contain `Int#`s without either change, since `au` and `ad` might be `undefined`! Or GHC would have to generate multiple specializations of `loop2` for different demand patterns, which it doesn't currently do.) Currently, `loop2` produces `Int#`s if its result type is a strict pair and `-funbox- small-strict-fields` is on (which it is by default), otherwise `Int`s. Unboxing the `Int`s inside the unboxed tuple is indeed nested CPR, which is the subject of this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2289#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11106: Optimizer changes behavior in 7.10.3
by GHC 20 Feb '16

20 Feb '16

#11106: Optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- The repository at https://github.com/ddssff/ghcbug contains a four module package that works when compiled with -O2, but fails when compiled with -O2. The cabal file builds working and failing executable. One of the modules has OPTIONS_GHC -O0 in the header, so the bug is related to mixing modules with different optimization levels. Other than that, I have little idea what is going on. The bug was present in 7.10,2, and is definitely still present in 7.10.3-rc1. I doubt it has been fixed since then. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19