- ghc-tickets - Haskell.org

Re: [GHC] #7198: New codegen more than doubles compile time of T3294
by GHC 14 Mar '16

14 Mar '16

#7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): This sounds interesting and I wanted to attempt to fix this. :-) I'm not very familiar with the code, so some help would be super useful. IIRC there are a few things happening here: - We have a bunch of nested `let`s that we could try to flatten based on a heuristic that considers how many free variables the `let` has. - We generate a lot of unnecessary code for copying the values from the stack to the heap (using local variables instead of assigning them directly). - The original description also mentions reloads for unused variables. But I'm not sure I understand what exactly is this referring to. (Some example would be nice!) Based on that I have a few questions on how to approach solving this: - What would be a good place in the code to consider flattening of `let`s? - What code is responsible for the unnecessary code for copying the values? It seems that this is would be the `StgCmm*` modules that compile STG to cmm, is that correct? Note: looking at Cmm when compiled with optimizations, it seems to me that the sinking pass is able to optimize the unnecessary copying of values through local variables (the assignment are of the form `F64[Hp - 312] = F64[Sp + 8];`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9887: No message when GCHI reusing compiled code
by GHC 13 Mar '16

13 Mar '16

#9887: No message when GCHI reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Running ":l Main.hs" at the GHCI prompt would load the compiled module. I am new to Haskell and this was a stumbling block that made it so that I could not interactively debug my code with GHCI. Deleting the object files was suggested to me on IRC and that allowed me to get the "*Main" prompt I was looking for. A message warning users "reusing compiled code" would likely save some future users some time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9887> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF)
by GHC 13 Mar '16

13 Mar '16

#11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) -------------------------------------+------------------------------------- Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: m68k | Type of failure: GHC doesn't work | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc is generating C code like in the following simplified example: demo1.c: {{{ #include <assert.h> extern void* int_returning_function(); typedef int (*int_f_ptr)(); int main(void) { int result; { int_f_ptr correctly_typed_pointer; correctly_typed_pointer = (int_f_ptr)int_returning_function; result = correctly_typed_pointer(); } assert(result == 42); return 0; } }}} demo2.c: {{{ int int_returning_function() { return 42; } }}} This code fails to work on m68k with gcc-5.3.1 if optimization is turned on. The real-life example from ghc is rts/Schedule.c:raiseExceptionHelper as int_returning_function and rts/Exception.cmm:stg_raisezh as main. The reason it fails is that on m68k, a function returning a pointer returns the result in %a0, while a function returning an integer returns it in %d0. If optimization is enabled, gcc elides the function pointer and calls the function as-if it were called directly. Without optimization, gcc expects the result to be in %d0, where it actually is. In my oppinion, gcc is allowed to do that, because according to N843 (C99 draft), 6.2.7 #2 "All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined." is violated in this example. Compatibility of return types is defined in 6.7.5.3 #11 "For two function types to be compatible, both shall specify compatible return types. Moreover, [...]" which is clearly violated. If you just look at demo1.c and assume that 6.2.7 #2 is *not* violated, int_returning_function would in fact be a function returning a pointer. In that case, compiling demo1.c would violate 6.3.2.3 #8 "If a converted pointer is used to call a function whose type is not compatible with the pointed-to type, the behavior is undefined." and/or 6.5.2.2 "If the function is defined with a type that is not compatible with the type (of the expression) pointed to by the expression that denotes the called function, the behavior is undefined." You might want to discuss this issue with the gcc developers, but I don't see a standard claus justifying the approach of declaring all functions returning StgFunPtr and casting them to the right type. If you cross-compile the source tarball Debian claims to be 7.10.3-rc1 to m68k using gcc 5.3.1, ghc crashes on startup because stg_raisezh gets a wrong value as frame_type and tries to cancel an STM transaction that does not exist at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #11494: Add -Wcompat to -Wall
by GHC 12 Mar '16

12 Mar '16

#11494: Add -Wcompat to -Wall -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- As discussed in the call today we will add the `-Wcompat` warnings to `-Wall` pending discussion with the CLC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11681: ghc panic with TypeError
by GHC 12 Mar '16

12 Mar '16

#11681: ghc panic with TypeError -------------------------------------+------------------------------------- Reporter: inaki | 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: -------------------------------------+------------------------------------- When playing around with `TypeError` I got a ghc panic with the following code: {{{#!hs {-# LANGUAGE DataKinds, FlexibleContexts, TypeOperators, FlexibleInstances, UndecidableInstances #-} import GHC.TypeLits class C t where instance (TypeError (Text "A" :<>: {- Text -} "B")) => C t where main :: IO () main = return () }}} Compiling this results in {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160204 for x86_64-unknown-linux): fvProv falls into a hole {a1bh} }}} Commenting "in" the second `Text` removes the panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11681> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] Batch modify: #8953, #10141, #10249, #10332, #10343, #10383, ...
by GHC 12 Mar '16

12 Mar '16

Batch modification to #8953, #10141, #10249, #10332, #10343, #10383, #10431, #10506, #10770, #10830, #10878, #10915, #10962, #10972, #11096, #11457, #10582 by bgamari: milestone to 8.2.1 Comment: This bug won't be fixed in 8.0.1; bumping to 8.2. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=8953%2C10141%2C10249%2C10332%2C103…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11694: The function `lift'ghc: panic! (the 'impossible' happened)
by GHC 11 Mar '16

11 Mar '16

#11694: The function `lift'ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Sventimir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The error message I got doesn't even make much sense (or at least I don't understand it). Here it is: {{{ src/Splices.hs:22:18: Couldn't match kind `* -> *' with `*' Expected type: (a1 -> a1) -> heist-0.14.1.1:Heist.Internal.Types.HeistState.HeistT m m Text Actual type: (a1 -> a1) -> heist-0.14.1.1:Heist.Internal.Types.HeistState.HeistT m m Text Kind incompatibility when matching types: a_t -> a_t :: * -> * a1 -> a1 :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As far as I understand it says that two things of the same type (a -> a) have different kind... And the offending function is really simple: {{{#!hs import Happstack.Server (path) import Heist.Interpreted (textSplice) insertFromPath :: Splice m insertFromPath = lift path id >>= textSplice }}} I believe that `m` should evaluate to `ServerPartT IO` from Happstack.Server module. I append the whole source code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope
by GHC 11 Mar '16

11 Mar '16

#11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code no longer works: {{{ -- A.hs-boot module A where concat :: Int -> Int -- overlaps with Prelude's concat -- B.hs module B where import Prelude () import {-# SOURCE #-} A x = concat 3 -- A.hs module A where import B concat n = n + 2 }}} Building `ghc --make A`, this crashes with: {{{ [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) B.hs:4:5: error: • Can't find interface-file declaration for variable concat Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the expression: concat 3 In an equation for ‘x’: x = concat 3 }}} The trouble is that renaming has botched up the top-level declaration for boot: {{{ ezyang@sabre:~$ ghc-8.0 -c A.hs-boot -ddump-rn -dppr-debug A.hs-boot:1:1: ==================== Renamer ==================== {A.hs-boot:2:1-20} base-4.9.0.0:Data.Foldable.concat{v r2S} :: {A.hs-boot:2:11-20} ghc-prim-0.5.0.0:GHC.Types.Int{(w) tc 3J} -> ghc-prim-0.5.0.0:GHC.Types.Int{(w) tc 3J} }}} Is a regression from 7.10. The dodginess is proximal to renameSig but I haven't quite narrowed it down yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens`
by GHC 11 Mar '16

11 Mar '16

#11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: (Type checker) | 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 just updated the GHC 8.0 snapshot I was using from 8.0.0.20160214-g977fb8 to 8.0.0.20160218-g23baff7, and suddenly hackage:microlens-0.4.2.0 fails to build with {{{ ... Preprocessing library microlens-0.4.2.0... [1 of 4] Compiling Lens.Micro.Type ( src/Lens/Micro/Type.hs, dist/build/Lens/Micro/Type.o ) [2 of 4] Compiling Lens.Micro.Internal ( src/Lens/Micro/Internal.hs, dist/build/Lens/Micro/Internal.o ) src/Lens/Micro/Internal.hs:184:3: error: • Couldn't match type ‘s’ with ‘g0 a’ ‘s’ is untouchable inside the constraints: (Traversable g, s ~ g a, t ~ g b, Applicative f) bound by the type signature for: each :: (Traversable g, s ~ g a, t ~ g b, Applicative f) => (a -> f b) -> s -> f t at src/Lens/Micro/Internal.hs:184:3-27 • In the ambiguity check for ‘each’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: each :: forall s t a b. Each s t a b => Traversal s t a b In the class declaration for ‘Each’ }}} ...is this a regression or a feature? :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #11697: rts/posix/Itimer.c: ignoring return value of ‘read’
by GHC 11 Mar '16

11 Mar '16

#11697: rts/posix/Itimer.c: ignoring return value of ‘read’ -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 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: -------------------------------------+------------------------------------- Builds currently failing in travis. Eg : https://travis- ci.org/ghc/ghc/jobs/115023819 {{{ rts/posix/Itimer.c: In function ‘itimer_thread_func’: rts/posix/Itimer.c:205:17: error: error: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Werror=unused-result] }}} The code being complained about is: {{{ if (USE_TIMERFD_FOR_ITIMER) { read(timerfd, &nticks, sizeof(nticks)); } else { }}} The value of `nticks` is never used, so a solution to this may be: {{{ if (USE_TIMERFD_FOR_ITIMER) { if (read(timerfd, &nticks, sizeof(nticks)) != sizeof(nticks)) nticks = 0; } else { }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8