April 2015 - ghc-tickets

[GHC] #10363: ApiAnnotations : HsForAllTy discards parens
by GHC 21 May '15

21 May '15

#10363: ApiAnnotations : HsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The annotations for the following code {{{#!hs pTokenCostStr :: forall a .((Show a) => [a] -> Int -> String) }}} have detached annotations for the parens around `(Show a)... String`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7
by GHC 19 May '15

19 May '15

#10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: arm | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Phab:D33 broke the build on ARM pre-ARMv7, because there is no definition of `store_load_barrier` or `load_load_barrier` for those platforms. (Granted, the old fall-back behavior of doing nothing was almost certainly incorrect.) I don't know whether we need CPU-level barriers here, or whether they are available. At a minimum, we need a compiler-level barrier. If we need a CPU-level barrier and it isn't provided by the instruction set, then I guess we should disable SMP for these platforms in `mk/config.mk.in`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8555: Simplify given `Coercible` constraints
by GHC 19 May '15

19 May '15

#8555: Simplify given `Coercible` constraints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8503 | -------------------------------------+------------------------------------- It would be feasible and possibly useful if {{{ foo :: Coercible [a] [b] => a -> b foo = coerce }}} would work. This involve simplifying `CtGiven`s similar to how given (nominal) equalities are simplified. I’ll defer working on this, as it is not strictly required, it seems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8799: Orientation of given `Coercible` constraints
by GHC 19 May '15

19 May '15

#8799: Orientation of given `Coercible` constraints -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8555 | Test Case: | Blocking: -------------------------------------------+------------------------------- {{{ Prelude> :m + GHC.Exts Prelude GHC.Exts> let f :: Coercible a b => b -> a ; f = coerce <interactive>:3:40: Could not coerce from ‛b’ to ‛a’ because ‛b’ and ‛a’ are different types. arising from a use of ‛coerce’ from the context (Coercible a b) bound by the type signature for f :: Coercible a b => b -> a at <interactive>:3:10-32 In the expression: coerce In an equation for ‛f’: f = coerce }}} Something better could be done here (but its not clear what exactly, and to what general extend). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10349: ghc-7.10.1.20150414 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long)
by GHC 19 May '15

19 May '15

#10349: ghc-7.10.1.20150414 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long) -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.1 Component: Build | Operating System: Linux System | Type of failure: Building GHC Keywords: | failed Architecture: aarch64 | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On Fedora at least, the ghc-7.10 branch (as of yesterday) fails to configure on aarch64 when using ld.gold: {{{ checking size of long long... configure: error: in `/builddir/build/BUILD/ghc-7.10.1.20150414': configure: error: cannot compute sizeof (long long) }}} Gdb says: {{{ (gdb) r Starting program: /home/petersen/conftest During startup program terminated with signal SIGKILL, Killed. }}} Compiling the conftest.c attached with -fuse-ld=gold causes it to crash when run. {{{ $ gcc -o conftest conftest.c $ ./conftest $ gcc -o conftest -fuse-ld=gold conftest.c $ ./conftest Killed $ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10110: Compiling unit fails with Loading temp shared object failed
by GHC 19 May '15

19 May '15

#10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.10.1-rc2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #10058 Differential Revisions: | -------------------------------------+------------------------------------- @goldfire reported in #10058 in comment 1 another failure: {{{ [43 of 55] Compiling Tests.Compile.UnitParser ( Tests/Compile/UnitParser.hs, dist/build/main/main- tmp/Tests/Compile/UnitParser.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150123 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc6444_0/libghc6444_264.so: undefined symbol: DataziMetrologyziSIziUnits_zdfShowHectare_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} While on the surface this looks like a duplicate of #10058 it is not. The issue is only on Linux (travis to be precise), not OSX. Looking at the undefined symbol, here we see a symbol from the current module whereas in #10058 the undefined symbol lives in one of the packages. My theory is that the travis machine is running a modified link editor that defaults to `--as-needed` being set whereas the binutils default is `-no-as-needed`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10366: Post link to MacOS binary of 7.10
by GHC 19 May '15

19 May '15

#10366: Post link to MacOS binary of 7.10 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: highest | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- More than a month after GHC 7.10 is released, there still isn't a binary linked for MacOS at https://www.haskell.org/ghc/download_ghc_7_10_1#binaries. I see that the binary exists in https://downloads.haskell.org/~ghc/7.10.1/, but that link is critical to finding it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10366> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10335: Failure to construct superclasses in instance
by GHC 18 May '15

18 May '15

#10335: Failure to construct superclasses in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, ConstraintKinds #-} module Foo where class Eq a => C a b type X a = (Eq a, Show a) instance X a => C a [b] }}} HEAD gives {{{ Foo.hs:8:10: Could not deduce (Eq a) arising from the superclasses of an instance declaration from the context: X a bound by the instance declaration at Foo.hs:8:10-23 Possible fix: add (Eq a) to the context of the instance declaration In the instance declaration for ‘C a [b]’ }}} This is fall-out from refactoring the silent-superclass story. Patch coming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10248: GHC panic when used with deferred type errors, again
by GHC 18 May '15

18 May '15

#10248: GHC panic when used with deferred type errors, again ---------------------------------------+------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+------------------------------- Similar to previous report of mine #9834. Given `error.hs` {{{#!hs data I a = I a }}} I get the following result: {{{#!hs $ ghci -fdefer-type-errors -ignore-dot-ghci error.hs <ype-errors -ignore-dot-ghci error.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( error.hs, interpreted ) Ok, modules loaded: Main. *Main> I <$> _ I <$> _ <interactive>:2:7: Warning: Found hole ‘_’ with type: IO a0 Where: ‘a0’ is an ambiguous type variable In the second argument of ‘(<$>)’, namely ‘_’ In the first argument of ‘GHC.GHCi.ghciStepIO :: IO a_auR -> IO a_auR’, namely ‘I <$> _’ In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_auR -> IO a_auR (I <$> _) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150316 for i386-unknown-linux): nameModule $dShow_aIT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage
by GHC 18 May '15

18 May '15

#10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I encountered a situation where using a tuple constraint synonym produced an asymptotic runtime performance degradation, from linear to quadratic time. The enclosed Bug.hs reproduces the potentially relevant features of the problem. The function `test` there is quadratic, but should be linear. The file also contains a definition of `test2`, which differs only in eschewing the constraint synonym, and is linear, as it should be. In more detail: the program tries to count to 20,000 in a rather contrived way. It maintains a Box, which holds the current count and a function that can accept an increment and a count to produce a new count (namely, `(+)`). The function `do_step` lifts incrementation to Boxes, using their contained function to update their stored count. The first tricky thing is that the incrementing function stored in the Box is polymorphic in both arguments separately: it can accept increments that are not the same type as the stored count (and converts them). The second tricky thing is that I don't want to expose the type variable for the increment type (as opposed to the count type) to clients of the Box, so the Box's incrementing function is stored polymorphic (with an explicit forall). Finally, I want to impose the constraint `(Fractional num, Real num)` on allowable increments (even though this example only needs `Real num`). This constellation of desiderata conspires to produce quadratic performance: doubling the parameter to `test` (but not `test2`) multiplies its runtime by 4. Inspecting the heap profile indicates a growing accumulation of closures when running `test` (but not `test2`). Inspecting the generated stg (enclosed) locates a potential culprit: apparently when `do_step` (but not `do_step2`) reconstructs the Box, it changes the `func` stored there to be a fresh closure that destructures the `Numerical` constraint tuple, constructs a fresh one, and calls the function that was in that slot previously with it. I hypothesize that this accumulates as a chain that performs a linear number of such destructurings and restructurings at each increment, leading to the observed quadratic runtime and linear memory growth. Incidentally, I checked whether record wildcards were the issue (no: `test4`) and whether updating just the `obj` field solves it (yes: `test3`). Sadly, the latter solution is not directly usable in my actual application because of "Record update for insufficiently polymorphic field". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11