- ghc-tickets - Haskell.org

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

[GHC] #12662: Investivate ListSetOps module
by GHC 16 Dec '16

16 Dec '16

#12662: Investivate ListSetOps module -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | 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: -------------------------------------+------------------------------------- It seems that the `ListSetOps` module is very inefficient and there are probably better ways to do what it does elsewhere in GHC. This is an open ended ticket to: 1. Investigate where functions from `ListSetOps` are used in GHC. 2. Investigate how easy it is to remove the usages of these functions. 3. Remove the module if it is feasible to do so. Seems like it might be good for a newcomer? Someone else can tag it so if they agree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5775: Inconsistency in demand analysis
by GHC 16 Dec '16

16 Dec '16

#5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.5 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => Comment: I will not have time to look further into this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5775#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #229: Integer overflow in array allocation
by GHC 16 Dec '16

16 Dec '16

#229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: After 13 years we can at long last close this chapter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/229#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #229: Integer overflow in array allocation
by GHC 16 Dec '16

16 Dec '16

#229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"cd4b202f24da928adf66c05443b457002ab6a3e1/ghc" cd4b202/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cd4b202f24da928adf66c05443b457002ab6a3e1" array: Check for integer overflow during allocation This fixes #229, where creating a new array can cause array to allocate a smaller array than it thinks it allocates due to integer overflow, resulting in memory unsafety. This breaks the rts/overflow1 test, which relied on this unchecked overflow. I fix it by reimplementing the test in terms of newByteArray# directly. Updates the array submodule. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/229#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10301: Plugins/dynamic loading subtly broken (it seems)
by GHC 16 Dec '16

16 Dec '16

#10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.8.2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: | crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #8276 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Imported from #8276, which was originally about a Haddock bug (that was different in nature but appeared similarly): > I still experience this panic on GHC 7.8.2 with Windows x86_64: > > {{{ > $ ghci > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > λ> import StaticFlags > λ> import Data.IORef > λ> readIORef v_opt_C_ready > Loading package array-0.5.0.0 ... linking ... done. > Loading package deepseq-1.3.0.2 ... linking ... done. > Loading package bytestring-0.10.4.0 ... linking ... done. > Loading package containers-0.5.5.1 ... linking ... done. > Loading package Win32-2.3.0.2 ... linking ... done. > Loading package filepath-1.3.0.2 ... linking ... done. > Loading package old-locale-1.0.0.6 ... linking ... done. > Loading package time-1.4.2 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package pretty-1.1.1.1 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package Cabal-1.18.1.3 ... linking ... done. > Loading package binary-0.7.1.0 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hoopl-3.10.0.1 ... linking ... done. > Loading package hpc-0.6.0.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package transformers-0.3.0.0 ... linking ... done. > Loading package ghc-7.8.2 ... linking ... done. > False > λ> staticFlags > ghc.exe: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-unknown-mingw32): > Static flags have not been initialised! > Please call GHC.parseStaticFlags early enough. > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > But not with GHC 7.8.2 on Linux x86_64: > > {{{ > $ ghci > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > λ> import StaticFlags > λ> import Data.IORef > λ> readIORef v_opt_C_ready > Loading package array-0.5.0.0 ... linking ... done. > Loading package deepseq-1.3.0.2 ... linking ... done. > Loading package bytestring-0.10.4.0 ... linking ... done. > Loading package containers-0.5.5.1 ... linking ... done. > Loading package filepath-1.3.0.2 ... linking ... done. > Loading package old-locale-1.0.0.6 ... linking ... done. > Loading package time-1.4.2 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package pretty-1.1.1.1 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package Cabal-1.18.1.3 ... linking ... done. > Loading package binary-0.7.1.0 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hoopl-3.10.0.1 ... linking ... done. > Loading package hpc-0.6.0.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package transformers-0.3.0.0 ... linking ... done. > Loading package ghc-7.8.2 ... linking ... done. > True > λ> staticFlags > [] > }}} > > This has caused problems for me when running programs such as [https://github.com/ku-fpg/hermit/ HERMIT] on Windows, since at some point, {{{parseStaticFlagsFull}}} seems to be called during program execution. A workaround is to call {{{initStaticOpts}}} manually somewhere in the program, but I feel like that shouldn't be necessary. The one above was on Windows. Also reported: > Hello, > > A similar panic also happens when running Liquid Haskell [http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/] on a file that uses the Units of Measure plugin [https://github.com/adamgundry/uom- plugin] > > > {{{ > liquid: liquid: panic! (the 'impossible' happened) > (GHC version 7.10.1 for x86_64-unknown-linux): > Static flags have not been initialised! > Please call GHC.parseStaticFlags early enough. > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #10294: Missing instances if compiling with -fplugin
by GHC 16 Dec '16

16 Dec '16

#10294: Missing instances if compiling with -fplugin -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Linux Keywords: | Type of failure: GHC rejects Architecture: x86_64 | valid program (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using the example from "9.3.3.2. Using Annotations" of the GHC user manual does not work correctly with GHC 7.10. The following fails: $ ghc -c Bug1.hs -fplugin=SayAnnNames.Plugin {{{ Bug1.hs:5:1: No instance for (Data SomeAnn) arising from an annotation In the annotation: {-# ANN foo SomeAnn #-} }}} It does not seem to matter why the type class is required: $ ghc -c Bug2.hs -fplugin=SayAnnNames.Plugin {{{ Bug2.hs:10:7: No instance for (Data SomeAnn) arising from a use of ‘bar’ In the expression: bar SomeAnn In an equation for ‘baz’: baz = bar SomeAnn }}} Compiling without -fplugin works fine, though. If SomeAnn is defined in a different module than SayAnnNames.Plugin and reexported from it, the instances are in scope, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10294> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7