February 2016 - ghc-tickets

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

21 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 20 Feb '16

20 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 20 Feb '16

20 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 20 Feb '16

20 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 20 Feb '16

20 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 20 Feb '16

20 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 20 Feb '16

20 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 20 Feb '16

20 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

[GHC] #8176: Language extensions not registered
by GHC 20 Feb '16

20 Feb '16

#8176: Language extensions not registered --------------------------------+------------------------------------------ Reporter: duncan | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: tests/driver/T4437.hs Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ tests/driver/T4437.hs does not seem to be being used properly. That test is there to make sure that ghc developers do not forget to register their new extensions with Cabal. But it looks like it's just being silenced and they are being forgotten again. Recall, the protocol is that all Haskell implementations can register their extensions in the central location (which is Language.Haskell.Extensions in the Cabal package) when they are happy that they are ready for public consumption. This matters to users because extensions that are not ready for public consumption (ie not registered) cannot be used in packages uploaded to hackage. Currently `tests/driver/T4437.hs` contains: {{{ expectedGhcOnlyExtensions = [ "AllowAmbiguousTypes", "RelaxedLayout", "AlternativeLayoutRule", "AlternativeLayoutRuleTransitional", "ExplicitNamespaces", "TypeHoles", "OverloadedLists", "EmptyCase", "AutoDeriveTypeable", "NegativeLiterals", "NullaryTypeClasses"] }}} This looks like a much bigger list than it should be. Surely not all of these extensions are private to ghc or are still under development and not to be used? But if they are listed here, then the test doesn't complain about them. And the whole point of this test is to stop ghc devs from forgetting to register them. I think we need to change the test so that we distinguish between extensions that are really not ready, and ones that are on-track to be public. It should be a release blocker for the "on-track to be public" ones to still not be registered. The test should have comments giving this guidance for ghc contributors. I'm not quite sure how we adjust the test to make that happen (ie different behaviour for RC-build vs normal hacking validate). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17