December 2016 - ghc-tickets

[GHC] #9601: Make the rewrite rule system more powerful
by GHC 16 Dec '16

16 Dec '16

#9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more | Type of failure: than a week) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be amazing if the current RULES system could be upgraded to include various predicates, or even into a full-on strategic programming system. This would allow far far more optimisations to be possible, rather than the current conservative system where you have to make sure that the optimisations ALWAYS apply. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11784: panic "hscCmmFile: no_mod" with `-v2 and above
by GHC 16 Dec '16

16 Dec '16

#11784: panic "hscCmmFile: no_mod" with `-v2 and above -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Initailly found this on powerpc when debugging #11773, but it also happens on x86_64. The command line: {{{ inplace/bin/ghc-stage1 -static -H64m -O0 -Wall -v2 -Iincludes \ -Iincludes/dist -Iincludes/dist-derivedconstants/header \ -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build \ -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts \ -irts/dist/build -irts/dist/build/autogen -Irts/dist/build \ -Irts/dist/build/autogen -O2 -Wnoncanonical-monad-instances -c\ rts/StgStartup.cmm -o rts/dist/build/StgStartup.o }}} panics with a message: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160402 for powerpc-unknown-linux): hscCmmFile: no_mod }}} The only thing that was added to the command line that is different from the normal build command is the `-v2`. This is caused by the code (in compiler/main/HscMain.hs): {{{ no_mod = panic "hscCmmFile: no_mod" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11784> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11221: Remove -fwarn-context-quantification
by GHC 16 Dec '16

16 Dec '16

#11221: Remove -fwarn-context-quantification -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- This option was deprecated and does nothing as of GHC 8.0. Remove `Opt_WarnContextQuantification` and its uses from `DynFlags`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12986: Ignore case when parsing language pragmas
by GHC 16 Dec '16

16 Dec '16

#12986: Ignore case when parsing language pragmas -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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: -------------------------------------+------------------------------------- It's annoying to have to remember exactly how a language extension is supposed to be capitalized. It seems highly unlikely that we will ever have two different language extensions that differ only by case. Therefore, I think GHC should ignore case when matching `{-# LANGUAGE #-}` pragmas. Thus, we should accept not only `UndecidableSuperClasses` but also `UndecidableSuperclasses`, etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12986> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12899: ghc panics at random places with -jX
by GHC 16 Dec '16

16 Dec '16

#12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- Affected versions: pretty much all the things from early ghc8 until most recent. Symptoms: Out of 106 clean builds 36 failed with random ghc panic. By random I mean no two are alike. There are 525 files in a project and compilation goes in parallel with -j8. Other than panic in 21 cases it generates type errors (types are perfectly fine and whatever is under "with actual type" is something that probably exists in the same file or at least in the project itself but totally unrelated to what type an expression actually is. And even in those cases where ghc fails at the same file it usually results in different panic messages. What was checked: Stale interface files: No, ghc is told to use a separate build directory build system removes it bad memory/random file system corruption: No, ghc 7.10 builds the same codebase just fine and it also fails on other machines strange packages in user package database: No, ghc is told to ignore those ghc was reinstalled several times with system package db wiped. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5654: Profiling semantics bug
by GHC 16 Dec '16

16 Dec '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: simonmar => * status: closed => new * resolution: fixed => Comment: I uncovered a bug in the patch, triggered by using GHCi with profiling. Fix incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 16 Dec '16

16 Dec '16

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Phab:D2861 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2861 Comment: `threadDelay minBound` no longer appears to block on Windows. However, `threadDelay maxBound` returns immediately. See Phab:D2861 for a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size)
by GHC 16 Dec '16

16 Dec '16

#8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: 8287 ----------------------------------------------+---------------------------- currently GHC's internals and code gen don't provide a strong distinction between Ints as data, and Ints for pointer / address arithmetic. This also comes up as being problematical in a number of ways. 1. We wind up having many portability issues around Int and pointer / address sizes. 2. adds some inessential complexity / problems to adding new architectures to ghc. eg x32 ABI which has 32bit pointers and 64bit ints somewhat breaks current assumptions in the GHC primops (because arrays are indexed by a byte offset, and the valid range for those is determined by the ABI pointer size!) 3. this Ints and Ptrs confusion we currently have, also means we can't leverage the Integer support in SIMD registers that is in most modern CPUs! If we could have those two separated better, theres a lot of low leve optimizations we could do for Int/Word data that we currently cant do! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators
by GHC 16 Dec '16

16 Dec '16

#11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Throughout GHC's source there are related pretty-printing operators with subtly different `infixr/infixl`-declarations. It would be desirable to unify those and possibly use `Semigroup((<>))` instead (where `<>` represents a semigroup/monoid operation anyway) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11243: Use Type Synonyms to Compress Errors
by GHC 16 Dec '16

16 Dec '16

#11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Error messages can be ugly, especially when working with promoted types. I've been dealing with this for a long time with [one library in particular](https://hackage.haskell.org/package/lol). But I just encountered something truly heinous. Due to a minor mistake, GHC spit out 8 errors in total, the shortest of which was 60 lines, and the longest of which was 20,046 lines long. That's no typo: the last error is over 20,000 lines long. Props to GHC for handling such a mess. As the library author, I've learned to look paste these massive errors. But I'm afraid that some user is going to have a heart attack (or worse: give up and go home). You can see in the error message that most of it is recurring blocks of {{{ PrimePower ('PP '(type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type- natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type- natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type- natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0)))))), type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type-natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0)) }}} and {{{ (NextListElt * zq ((':) * (ZqBasic * Types.Q18869761 Types.Z) ((':) * (Types.Zq * Types.Q19393921, ZQ1) ((':) * (Types.Zq * Types.Q19918081, ZQ2) ((':) * (Types.Zq * Types.Q2149056001, ZQ3) ((':) * (Types.Zq * Types.Q3144961, ZQ4) ((':) * (Types.Zq * Types.Q7338241, ZQ5) ('[] *))))))))), }}} I believe that GHC attempts to expand type synonyms as much as possible, which is great in many cases. But for this error, the repetition of fully expanded blocks completely hides the true nature of the error, especially since the user (obviously) makes heavy use of type synonyms anyway. The feature I'm requesting is the ability to somehow reduce the mess in the attached error. Here are a few ideas: 1. A flag to tell GHC to *not* expand type synonyms, i.e. if the user uses `N2` from Data.Type.Natural, GHC should print 'N2' instead of {{{ type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type-natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0) }}} 2. Allow library developers a way to tell the compiler how to print a certain entity, i.e., with a custom name. This is somewhat similar to the Custom Type Errors proposal, but I don't think that proposal includes a way to tell GHC how to print specific types/type synonyms. Has anyone else run into this issue before? Are there any existing solutions or other ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15