September 2018 - ghc-tickets

[GHC] #15660: source file modify race leads to inconsistent error message
by GHC 20 Nov '18

20 Nov '18

#15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got this odd error message from ghc: {{{ Command/AddUrl.hs:120:32: error: lexical error in string/character literal at character '-' | 120 | BatchNull -> '\0' | ^ }}} Part of the error message says that '-' is the problem character, but the quoted line of code does not contain that. What happened is I started the build, noticed I had typoed '\-' and quickly corrected it in my editor and saved. It seems ghc must have read the source file twice, so I raced it and so experienced this inconsistency. I wonder if it could display the wrong line entirely if a larger change was made to the file? Thanks for your time with such a minor thing as this bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10445: Wrong stack space size when using -Ksize
by GHC 19 Nov '18

19 Nov '18

#10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After compiling the first example in https://wiki.haskell.org/Performance/Accumulating_parameter: {{{ $ cat Test.hs len :: [a] -> Int len [] = 0 len (x:xs) = len xs + 1 main :: IO () main = print $ len [1..1000000] }}} {{{ $ ghc Test.hs -rtsopts }}} and running {{{ ./Test +RTS -K10K }}} GHC 7.6.3 reports {{{ Stack space overflow: current size 10240 bytes. }}} GHC 7.8.4 reports {{{ Stack space overflow: current size 33632 bytes. }}} and GHC 7.10.1 reports {{{ Stack space overflow: current size 99136 bytes. }}} GHC 7.8.3 and 7.10.1 report an incorrect stack space size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10347: Spurious "unused constructor" warning with Coercible
by GHC 19 Nov '18

19 Nov '18

#10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RoleAnnotations #-} module Bug (N, twiddle) where import Data.Coerce newtype N a = MkN Int type role N representational twiddle :: N a -> N b twiddle = coerce }}} I get {{{ Bug.hs:7:15: warning: Defined but not used: data constructor ‘MkN’ }}} But the constructor ''is'' used, in order to do the coercion. The role annotation is to force GHC to use the constructor to do the coercion -- otherwise, it might not have. This bug exists in 7.10 and in HEAD. I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15126: Opportunity to compress common info table representation.
by GHC 18 Nov '18

18 Nov '18

#15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: CodeGen | 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've looked at a lot of GHC produced assembly recently and noticed that most info tables describing stacks have the form: {{{ .align 8 .long SDjR_srt-(block_cHmk_info)+296 .long 0 .quad 6151 .quad 4294967326 }}} I haven't managed to dig fully into the description however some observations: * I noticed that the second .long directive almost always ends up being zero. * When figuring out what is what I realized the first quad (describing the pointers) is almost never fully used. * The last entrie (closure type + ?), here `4294967326` also seems quite repetitive given the size reserved. So I looked in detail at spectral/simple: * There are 2012 info tables of this sort with all of them having a zero in the second long. * We also reserve 8 byte for the stack layout. However only a single of these tables requires more than 4 byte. The compiled module has a size of 276384 Bytes, with 16092 being redundant: * 4 bytes for 0 * 4 bytes unused stack description * times 2012 info tables. That is an overhead of 5,8% which seems like quite a lot to me. The questions where to put that information is a different one. But only looking at the data and not how it is used tagging the pointer to the SRT table seems like a possibility. The info table description `4294967326` also appeared over 1k times. Maybe it's possible to come up with a more efficient encoding there as well. I didn't give it much thought yet since I don't have the time to do anything about it in the near future. But putting it here in case anyone is interested or looks into this in the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9207: Detect obvious cases of infinite recursion.
by GHC 18 Nov '18

18 Nov '18

#9207: Detect obvious cases of infinite recursion. --------------------------------------+------------------------------------ Reporter: mrugiero | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: infinite recursion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: --------------------------------------+------------------------------------ Pure functions are guaranteed to return the same value if the same arguments are used. Because of that, a compiler could be able to detect infinite recursion in the form of a function calling itself with the same arguments (case, some distracted programmer forgot to apply the function tail to a list). The way I see it, one of Haskell's main selling points is that it helps the programmer to avoid sources of bugs as much as it can, and infinite recursion is one of the few that stand unchecked. I specifically point to this example because both, I'm a newbie and made that newbie mistake, and think it shouldn't be hard to implement to the parsing stage of the compiler/interpreter. It probably should throw an error when this happens in pure functions, and maybe an opt-in warning if it happens in monads. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12906: GHC fails to typecheck Main module without main
by GHC 17 Nov '18

17 Nov '18

#12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given a `Main` module without a `main` value, GHC 8 reports the missing `main` and then exits, without bothering to typecheck the rest of the module. Previous versions, I believe, had the more useful behavior of reporting type errors regardless. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12525: Internal identifiers creeping into :show bindings
by GHC 17 Nov '18

17 Nov '18

#12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.1 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: -------------------------------------+------------------------------------- When binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list. {{{#!html <pre class="wiki"> GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help > :show bindings > x = () > :show bindings <b>$trModule :: GHC.Types.Module = _</b> x :: () = _ > class Foo a > :show bindings x :: () = _ class Foo a <b>$tcFoo :: GHC.Types.TyCon = _ $tc'C:Foo :: GHC.Types.TyCon = _ $trModule :: GHC.Types.Module = _</b> </pre> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13704: -main-is flag should change exports in default module header
by GHC 17 Nov '18

17 Nov '18

#13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- The -main-is option to GHC should probably change the export list for the default module header. It doesn't. {{{ $ cat Main.hs program = return () $ ghc -main-is Main.program Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:1:1: error: Not in scope: ‘main’ Perhaps you meant ‘min’ (imported from Prelude) Main.hs:1:1: error: The main IO action ‘program’ is not exported by module ‘Main’ }}} I cannot imagine any possible use case for a feature that changes the entry point name to something else, and then deliberately fails to export the symbol by that name. This seems like an obvious thing to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11477: Remove -Wamp
by GHC 17 Nov '18

17 Nov '18

#11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This warning is intended as a temporary measure to aid the Applicative- Monad Proposal transition. It should be eventually removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11477> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15124: Improve block layout for the NCG
by GHC 17 Nov '18

17 Nov '18

#15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (NCG) | Keywords: CodeGen | 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 current codegen tries to place two blocks A and B next to each other if they are "close". = Drawbacks of the current algorithm Blocks are only considered close if one jumps to the other via a unconditional jump instructions. This is a fast and reasonable approximation. But we might be able to do better. == Calls are not considered even if they always return to the same block. For example it's clear that if foo == bar we jump to C here: {{{ A: movq $block_C_info,-16(%rbp) cmp foo,bar jne D B: jmp *(%rbx) #Returns to C ... .align 8 .infotable block_C_info: C: doThings }}} == Conditional jumps are never considered. The following block either jumps directly to c3mQ or returns there from a call. Yet that is completely ignored by the current algorithm. {{{ _c3mG: movq $block_c3mQ_info,-8(%rbp) ... jne _c3mQ jmp *(%rbx) #returns to c3mQ }}} == Likelyhood of branches is not considered. We track information about branches which are rarely taken at the cmm level. However this information is currently lost during the Cmm -> Asm transformation which happens before we do code layout. This means for Cmm code where one branch is never executed the branch that's never executed might be the only one considered relevant. This happens for example for this stack check: {{{ if ((Sp + -40) >= SpLim) (likely: True) goto c5PS; else goto c5Q3; }}} = Potential gains If nothing else this would allow some Cmm optimizations which are made useless by the current code layout algorithm. I have hit cases where the block layout algorithm turned optimizations into pessimizations of 2-5% by pulling obvious loops apart. Given that the scenario that leads to loops being pulled apart doesn't seem that unlikely I assume some loops are also pulled apart like this in HEAD. Cleaning this up ideally would also make it possible to move blocks which are not part of loops out of them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11