January 2016 - ghc-tickets

[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] #10691: certain operations in new integer-gmp are too lazy
by GHC 11 Mar '16

11 Mar '16

#10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This came up in #ghc the other day. {{{ rwbarton@morphism:~$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> undefined * 0 0 }}} For consistency not just with Int, but also other integer-* implementations, this should be undefined. Also affected is for example `andInteger`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10691> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11354: Install script installs docs without -version suffix
by GHC 11 Mar '16

11 Mar '16

#11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.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: -------------------------------------+------------------------------------- This is potentially bad when multiple GHC versions are installed - last installed one overwrites all the docs. It seems like docs are installed under {{{$PACKAGE_TARNAME}}}, and tarname is initialized as {{{"ghc"}}} in the {{{ac}}} file. I guess one solution would be to add version suffix to tarname (it seems like tarname is only used when installing docs) or alternatively use {{{${PACKAGE_TARNAME}-${PACKAGE_VERSION}}}} to install docs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11354> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11475: Lint should check for inexhaustive alternatives
by GHC 10 Mar '16

10 Mar '16

#11475: Lint should check for inexhaustive alternatives -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- GHC's simplifier prunes inaccessible alternatives from case expressions. E.g. {{{ case x of A y -> e1 _ -> ....(case x of A y -> r1 B -> r2 C -> r3) ... }}} It'll prune the `A` alternative from the inner case to get {{{ case x of A y -> e1 _ -> ....(case x of B -> r2 C -> r3) ... }}} BUT, there is no independent check from Lint that this pruning does the Right Thing. Trac #11172 turned out to be a bug in the pruning, which led to something like {{{ case x of Left y -> e1 }}} but in fact `x` ended up being bound to `(Right v)` for some value `v`. But because there is only a single alternative left, GHC does not test the tag, but instead goes ahead and accesses it the `Right` value as if it was a `Left` value. And because of pointer-tagging, it'll assume the wrong tag on the pointer, and very soon you are in seg-fault land. So this ticket is to suggest: make Core Lint do it's best to check that all cases are in fact exhaustive. There are two ways in which we prune cases: * Enclosing pattern matches (as above) * GADT pattern matches may be exhaustive even when they don't mention all constructors. For the latter, it's impossible for Lint to reproduce all the reasoning of the type checker, but I bet that in 99.5% of the cases the existing function `dataConCantMatch` will do the job. So if Lit * Maintains an environment saying what each variable can't match (as the simplifier does) * Does a simple-minded `dataConCantMatch` test based on the typ of the scrutinee I think we'd be a long way forward. It's possible that a valid program could trigger a Lint report, but let's see. Any volunteers? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11410: Quantification over unlifted type variable
by GHC 07 Mar '16

07 Mar '16

#11410: Quantification over unlifted type variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This silliness is accepted: {{{ data X (a :: TYPE 'Unlifted) = X }}} I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11410> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9699: TH function to list names in scope
by GHC 07 Mar '16

07 Mar '16

#9699: TH function to list names in scope -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I [asked about this on stackoverflow](http://stackoverflow.com/questions/26394199/using- templatehaskell-to-list-all-names-in-a-namespace), and apparently it doesn't exist yet. I want a TemplateHaskell function `variablesInScope :: Q [Name]` that returns a list of the `Name`'s of all the variables in scope. TemplateHaskell obviously has this information available in order to implement functions like `reify :: Name -> Q Info` and `lookupValueName :: String -> Q (Maybe Name)`. So it seems like this might be a pretty simple function to add. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11516: Panic, "falls into a hole"
by GHC 06 Mar '16

06 Mar '16

#11516: Panic, "falls into a hole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- {{{#!hs {-# language PolyKinds #-} {-# language FlexibleContexts #-} {-# language ConstraintKinds #-} {-# language FlexibleInstances #-} {-# language FunctionalDependencies #-} import GHC.Types (Constraint) class Ríki (p :: i -> i -> *) class (Ríki p) => Varpi p q f | f -> p q instance Varpi () () f => Varpi (->) (->) (Either f) where }}} causes {{{ % ghci -ignore-dot-ghci /tmp/testing.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/testing.hs, interpreted ) /tmp/testing.hs:11:10: error:ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160117 for x86_64-unknown-linux): fvProv falls into a hole {a13R} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Leaving GHCi. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10472: SigOf tests fail following renamer tidy-up
by GHC 01 Mar '16

01 Mar '16

#10472: SigOf tests fail following renamer tidy-up -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- I'm about to commit a patch that fixes #7672. Sadly, though, it causes these failures {{{ driver/sigof02 sigof02dmt [bad stderr] (normal) driver/sigof02 sigof02dt [bad stderr] (normal) driver/sigof02 sigof02mt [bad exit code] (normal) driver/sigof02 sigof02t [bad exit code] (normal) }}} with errors like {{{ Main.hs:8:13: error: Can't find interface-file declaration for variable empty 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 second argument of ‘($)’, namely ‘empty’ In the expression: insert 0 "foo" . delete 1 . insert 1 undefined . insert (6 :: Int) "foo" $ empty In an equation for ‘x’: x = insert 0 "foo" . delete 1 . insert 1 undefined . insert (6 :: Int) "foo" $ empty Main.hs:10:12: error: Can't find interface-file declaration for variable toList 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 first argument of ‘print’, namely ‘(toList x)’ In a stmt of a 'do' block: print (toList x) In the expression: do { let x = insert 0 "foo" . delete 1 . insert 1 undefined . insert (6 :: Int) "foo" $ empty; print (member 1 x); print (toList x); print x } }}} Clearly there is only one bug here, and it's in the signature-handling code, which I do not fully understand. Happily, it's Edward's territory, and he is also involved in #7672. So I plan to mark these tests as broken on this ticket, and hope that Edward can adapt the signature stuff (which in any case is in-flight) to the new code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10472> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5