- ghc-tickets - Haskell.org

Re: [GHC] #7606: Stride scheduling for Haskell threads with priorities
by GHC 12 Apr '18

12 Apr '18

#7606: Stride scheduling for Haskell threads with priorities -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 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: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7606#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted
by GHC 12 Apr '18

12 Apr '18

#13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: simplifier | Operating System: Unknown/Multiple ticks | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: dynamic-paper | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- on ghc 8.2.1-rc2 on a mac running the latest Xcode and os {{{ make TEST=dynamic-paper WAY=profasm fails with ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone delta ... Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad it also fails with 1000 ticks make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick- factor=1000' so there may be an infinite loop -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15026: Type deduction panic
by GHC 11 Apr '18

11 Apr '18

#15026: Type deduction panic -------------------------------------+------------------------------------- Reporter: moomin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!lhs > {-# LANGUAGE DeriveFunctor #-} > module Bug where > import qualified Data.Set as S > import Data.Foldable (fold, foldMap, toList) > import Data.List.Split (splitOn) > import Data.Monoid -- ((<>), Sum, mempty, mappend) > import Data.Functor.Foldable > newtype Component = Component (Int,Int) deriving (Eq, Ord, Show) > data Day24State v a = Day24State { > valueToMatch :: Int, > componentsToUse :: S.Set Component, > componentMetric :: v, > nextStates :: [a] > } deriving (Functor, Show) > type Day24StateFix v a = Fix (Day24State v) }}} Now in GHCI type > :t Data.Functor.Foldable.ana f (undefined :: Day24StateFix Component) Produces ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] f_akbJ :: t_akbI[tau:3] (CHoleCan: f)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15026> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10010: LLVM/optimized code for sqrt incorrect for negative values
by GHC 10 Apr '18

10 Apr '18

#10010: LLVM/optimized code for sqrt incorrect for negative values -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (LLVM) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The LLVM sqrt intrinsic is undefined below values of -0.0 See http://llvm.org/docs/LangRef.html#llvm-sqrt-intrinsic In some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined. This causes the result of Haskell's sqrt to vary at negative values based on the codegen and optimization flags chosen. {{{ main = print (sqrt (-7 :: Double)) }}} {{{ $ ghc -O -fllvm Sqrt.hs [1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o ) Linking Sqrt ... $ ./Sqrt 0.0 $ ghc -O Sqrt.hs [1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o ) Linking Sqrt ... $ ./Sqrt NaN }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character)
by GHC 10 Apr '18

10 Apr '18

#8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) ----------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: OpenBSD Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I get the following error... {{{ <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) }}} When running following program: {{{#!haskell {-# LANGUAGE OverloadedStrings #-} import qualified Data.Text as T import qualified Data.Text.IO as T main = T.putStrLn "čušpajž日本語" }}} Was tested in #haskell and I have all the UTF-8 Settings set and so forth. It compiles just fine, but crashes during runtime. gcc -v: {{{ Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd5.4/4.2.1/specs Target: amd64-unknown-openbsd5.4 Configured with: OpenBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

Re: [GHC] #4942: GHC.ConsoleHandler does not call back application when Close button is pressed
by GHC 10 Apr '18

10 Apr '18

#4942: GHC.ConsoleHandler does not call back application when Close button is pressed -------------------------------------+------------------------------------- Reporter: Amatic | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pdedecker): I have an console application that communicates with external hardware (scientific instruments). This hardware needs to be initialized at application start and cleanly shut down at application end, otherwise damage or increased wear can result. Unfortunately, many users close the program by hitting the "X" close button on the console window, even when trained not to. Years of routine are hard to beat. This bug prevents me from solving this, by making it impossible to run safely shut down the equipment in response to a close event. Please make it possible to handle these events and run cleanup code. Regarding the possibility of the Haskell code leading to an unkillable window: google suggests that the application will be terminated after a timeout, even if the handler function hasn't returned yet. So this may not be an issue in practice? (e.g. https://stackoverflow.com/questions/47041407/why-does-my-windows-console- close-event-handler-time-out) ALSO: the documentation for GHC.ConsoleHandler should reflect that Close events are ignored, which does not appear to be the case at present. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4942#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4020: Please consider adding support for local type synonyms
by GHC 09 Apr '18

09 Apr '18

#4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym 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 Tritlo): * cc: Tritlo (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4020#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10424: Build path leaks into ABI hashes
by GHC 09 Apr '18

09 Apr '18

#10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The build path of GHC leaks into the ABI hashes, i.e. if you build GHC in /tmp/fooADDF and then in /tmp/fooSDFS, you get different ABI hashes. This is a serious problem for distributions, as it means that we cannot rebuild the GHC package without rebuilding all Haskell packages as well. The (or at least one) problem is include paths. We have {{{ include-dirs: /home/jojo/build/haskell/ghc/rts/dist/build /home/jojo/build/haskell/ghc/includes /home/jojo/build/haskell/ghc/includes/dist- derivedconstants/header }}} in `inplace/lib/package.conf.d/builtin_rts.conf`, so when running the preprocessor, GHC passes this full path to the preprocessor: {{{ /usr/bin/gcc -E -undef -traditional -DOPTIMISE_INTEGER_GCD_LCM -include libraries/base/dist-install/build/autogen/cabal_macros.h -I libraries/base /dist-install/build -I libraries/base/dist-install/build -I libraries/base /dist-install/build/autogen -I libraries/base/include -I /home/jojo/build/haskell/ghc/libraries/integer-gmp/include -I /home/jojo/build/haskell/ghc/rts/dist/build -I /home/jojo/build/haskell/ghc/includes -I /home/jojo/build/haskell/ghc/includes/dist-derivedconstants/header '-D__GLASGOW_HASKELL__=711' -include /home/jojo/build/haskell/ghc/includes/ghcversion.h '-Dlinux_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' '-D__SSE__=1' '-D__SSE2__=1' -x assembler- with-cpp libraries/base/System/Info.hs -o /tmp/ghc14804_0/ghc14804_1.hscpp }}} It then reads the included files from the `hscpp` file : {{{ $ grep home /tmp/ghc14830_0/ghc14830_1.hscpp # 1 "/home/jojo/build/haskell/ghc/includes/ghcversion.h" 1 # 1 "/home/jojo/build/haskell/ghc/includes/ghcplatform.h" 1 }}} and puts it into the interface, where it becomes part of the hash: {{{ $ ./inplace/bin/ghc-stage1 --show-iface ./libraries/base/dist- install/build/System/Info.hi |grep Dep addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcplatform.h" addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcversion.h" addDependentFile "libraries/base/dist- install/build/autogen/cabal_macros.h" addDependentFile "/usr/include/stdc-predef.h" }}} Clearly, the end result is undesirable (changing hashes due to path names) and actually useless, as the build path will not be there later anyways. I’m not sure what the best way to fix this is. Here are a few ideas: * Do not include the path of `addDependentFile` entries in the hash, but only the file hash. Should solve the ABI hash. * Use relative paths in `inplace/lib/package.conf.d/builtin_rts.conf`. Not sure what breaks. This bug appeared in 7.8.4 and is present in both 7.10 and current HEAD. Any other ideas? (Debian bugreport at http://bugs.debian.org/785282) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15015: Parsing of exp_doc loses section markers
by GHC 09 Apr '18

09 Apr '18

#15015: Parsing of exp_doc loses section markers -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 (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: -------------------------------------+------------------------------------- This was originally filed as a Haddock issue, but was traced back to a parsing issue with GHC itself. See here for details: https://github.com/haskell/haddock/issues/797 There's a work-around (by putting extra empty lines) but that's quite fragile and would be best to fix directly in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15008: Type synonyms with hidden, determined type variables
by GHC 09 Apr '18

09 Apr '18

#15008: Type synonyms with hidden, determined type variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.5 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 found myself wanting to write (simplified) {{{ type MyMonad m = (MonadReader r m, Show r) }}} but GHC does not accept this, it wants `r` as part of the type synonym. So why did I think this could work? Because `MonadReader` has a functional dependency: {{{ class Monad m => MonadReader r m | m -> r }}} so if `m` determines `r`, why do I have to write `MyMonad r m` and not just `MyMonad m`? Can I not “hide” the fact that, somewhere internal to the `MyMonad` synonym, there is an additional variable `r` around? Clearly supporting this would need a language proposal, but I wanted to open a ticket here first to hear if this would even be possible to implement. ([https://stackoverflow.com/questions/29686920/is-it-possible-to-have- forgetful-type-synonyms-in-haskell Others have wanted this before as well.]) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8