March 2017 - ghc-tickets

[GHC] #8697: Type rationals
by GHC 16 Jun '17

16 Jun '17

#8697: Type rationals ------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've used GHC's Type Nats to implement my own type level rationals (code below). This works fine, but the syntax is a little funky because you have to write out the number as a fraction. For example, you must write 13/10 instead of 1.3; or even worse, 13/1 instead of 13. It would be nice to just write the decimal notation. I only see one potential problem with this feature: the dot in the decimal notation could interfere with the dot in forall statements. I guess this can be parsed unambiguously, but maybe not. {{{ data Frac = Frac Nat Nat data instance Sing (n::Frac) = SFrac Integer Integer instance (SingI a, SingI b) => SingI ('Frac a b) where sing = SFrac (fromSing (sing :: Sing a)) (fromSing (sing :: Sing b)) instance Fractional r => SingE (Kind :: Frac) r where fromSing (SFrac a b) = fromIntegral a/fromIntegral b type (/) a b = 'Frac a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13267: Constraint synonym instances
by GHC 15 Jun '17

15 Jun '17

#13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something funny happens when you try to declare an instance of a constraint synonym: {{{ {-# LANGUAGE ConstraintKinds #-} module F where type ShowF a = Show (a -> Bool) instance ShowF Int where show _ = "Fun" }}} I get: {{{ F.hs:8:5: error: ‘show’ is not a (visible) method of class ‘ShowF’ | 8 | show _ = "Fun" | ^^^^ }}} OK, but it gets weirder. Look at: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances #-} module F where type ShowF a = (Show (a -> Bool)) instance ShowF Int where }}} This is accepted (with a complaint that `show` is not implemented.) It gets even more awful: {{{ {-# LANGUAGE ConstraintKinds, FlexibleContexts, FlexibleInstances, MultiParamTypeClasses #-} module F where type ShowF a = (Show Bool, Show Int) instance ShowF Int where }}} This is awful: GHC treats `Show Bool` and `Show Int` as if they were constraints, and then emits the following DFun: {{{ df9d1b4635f2a752f29ff327ab66d1cb $f(%,%)ShowShow :: (Show Bool, Show Int) DFunId {- Strictness: m, Inline: CONLIKE, Unfolding: DFun: @ a @ b. @ (Show Bool) @ (Show Int) $fShowBool $fShowInt -} }}} I don't even know what this is supposed to mean. OK, so what should we do? I think there are a few possibilities: 1. Completely outlaw instance declarations on constraint synonyms. 2. Allow instance declarations on constraint synonyms, but only if after desugaring the synonym, you end up with a single class head. I would find this useful in a few cases, for example, if you are writing `instance MonadSample (Impl t) MyMonad`, if you had `type MonadSample2 t a = MonadSample (Impl t) a` you might prefer writing `instance MonadSample t MyMonad` instead 3. Figure out what instance declarations with multiple class heads, and proceed accordingly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13429: Optimizer produces Core with an infinite <<loop>>
by GHC 15 Jun '17

15 Jun '17

#13429: Optimizer produces Core with an infinite <<loop>> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While using vector package to implement convolution and supplying `-O1` or `-02` to ghc compilation results in core with an infinite loop. In order to trigger this behavior at least two modules is required. Attached is the minimal setup that I could come up with, that demonstrates the issue. Here is the stack trace: {{{ $ stack --install-ghc --resolver lts-8.3 exec -- ghc -O1 -prof -fprof-auto main.hs && ./main +RTS -xc [1 of 2] Compiling Loop ( Loop.hs, Loop.o ) [2 of 2] Compiling Main ( main.hs, main.o ) Linking main ... *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.CAF --> evaluated by: Main.main, called from Main.CAF --> evaluated by: Loop.toKernel.\, called from Data.Vector.Fusion.Util.>>=, called from Loop.toKernel, called from Main.main, called from Main.CAF --> evaluated by: Data.Vector.Fusion.Util.>>=, called from Loop.toKernel, called from Main.main, called from Main.CAF *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.CAF main: <<loop>> }}} At first I though that it might be a bug in a vector package, which is still a possibility, but since I was not able to observe that issue with ghc-7.8.4, I decided to open an ticket here. I tested attached code with all of subsequent released ghc versions (7.10.1 - 8.0.2), which resulted in the infinite loop. Worth noting that sometimes, when recompilation of only the `main.hs` file is enforced, program starts to work as expected. Here is an example: {{{ $ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main [1 of 2] Compiling Loop ( Loop.hs, Loop.o ) [2 of 2] Compiling Main ( main.hs, main.o ) Linking main ... main: <<loop>> $ touch main.hs $ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main [2 of 2] Compiling Main ( main.hs, main.o ) Linking main ... <Image 1x1> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 47

[GHC] #12056: Too aggressive `-w` option
by GHC 13 Jun '17

13 Jun '17

#12056: Too aggressive `-w` option -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- By running {{{ ghc -w -Wunrecognised-warning-flags -Wfoo Main.hs }}} I would expect the warning {{{ on the commandline: warning: unrecognised warning flag: -Wfoo }}} however this warning isn't reported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O)
by GHC 13 Jun '17

13 Jun '17

#12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After upgrading to GHC 8.0.1 I've noticed that compilation time of one of my libraries got unacceptably long. Please find the attached test case. Here are some numbers from my machine: {{{ $ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs <<ghc: 19103924976 bytes, 1441 GCs, 73048470/256579104 avg/max bytes residency (18 samples), 542M in use, 0.000 INIT (0.002 elapsed), 14.163 MUT (14.257 elapsed), 5.707 GC (5.830 elapsed) :ghc>> real 0m20.160s user 0m19.937s sys 0m0.197s $ time ~/Prefixes/ghc-8.0.1/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs <<ghc: 147662211104 bytes, 9635 GCs, 190336418/433097448 avg/max bytes residency (38 samples), 1210M in use, 0.000 INIT (0.001 elapsed), 101.707 MUT (101.840 elapsed), 27.907 GC (28.259 elapsed) :ghc>> real 2m10.195s user 2m9.773s sys 0m0.400s }}} Both versions are the official Debian 8 x86_64 binaries from haskell.org. I also compiled the git master and unfortunately it is affected as well. It is worth mentioning that turning off optimization makes the problem disappear: {{{ $ time ~/Prefixes/ghc-8.0.1/bin/ghc -O0 -c -Rghc-timing TypeList.hs Regression.hs <<ghc: 3779057184 bytes, 225 GCs, 17923355/81566792 avg/max bytes residency (8 samples), 164M in use, 0.000 INIT (0.001 elapsed), 2.847 MUT (2.941 elapsed), 0.553 GC (0.572 elapsed) :ghc>> real 0m3.593s user 0m3.507s sys 0m0.073s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12582: HSOC Eventlog live profiling
by GHC 12 Jun '17

12 Jun '17

#12582: HSOC Eventlog live profiling -------------------------------------+------------------------------------- Reporter: NCrashed | Owner: NCrashed Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: eventlog | Operating System: Unknown/Multiple profile hsoc | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, it is ticket for results of my Haskell Summer of Code 2016 project [1]. The goal is provide feature for redirection of events to external profilers without an application termination. Proposed changes: * Changing eventlog file descriptor in runtime. {{{#!c /* * Set custom file stream for global event log sink. * * The function overwrites previous event log file pointer. Previouss * sink is closed only if closePrev flag is on. * * Writing to the sink is protected by global mutex. * * The function puts header to the new sink only when emitHeader flag * is on. User might not want the header if it is switching to * already existed eventlog handle that was switched away recently. */ void rts_setEventLogSink(FILE *sink, StgBool closePrev, StgBool emitHeader); /* * Get current file stream that is used for global event log sink. * * You shouldn't do anything with the pointer until * rts_setEventLogSink(otherFileOrNull, false) is called. After that * you can do anything with the file stream. */ FILE* rts_getEventLogSink(void); }}} * Special flag `-lm` for RTS to store eventlog in memory chunks. User space functions to retrieve the chunks from memory. {{{#!c /* * If RTS started with '-lm' flag then eventlog is stored in memory buffer. * * The function allows to pop chunks of the buffer. Return value of 0 means * that there is no any filled chunk of data. * * If the function returns nonzero value the parameter contains full chunk * of eventlog data with size of the returned value. Caller must free the * buffer, the buffer isn't referenced anywhere anymore. * * If nobody calls the function with '-lm' flag then the memory is kinda * to be exhausted. */ StgWord64 rts_getEventLogChunk(StgInt8** ptr); }}} * Feature for dynamic resize of eventlog buffers. {{{#!c /* * Reallocate inner buffers to match the new size. The size should be not * too small to contain at least one event. * * If RTS started with '-lm' the chunks of memory buffer is also resized. */ void rts_resizeEventLog(StgWord64 size); /* * Return current size of eventlog buffers. */ StgWord64 rts_getEventLogBuffersSize(void); }}} * Bindings to new features in `Debug.Trace` in `base` package. {{{#!hs -- | The 'setEventLogCFile' function changes current sink of the eventlog, if eventlog -- profiling is available and enabled at runtime. -- -- The second parameter defines whether old sink should be finalized and closed or not. -- Preserving it could be helpful for temporal redirection of eventlog data into not -- standard sink and then restoring to the default file sink. -- -- The third parameter defines whether new header section should be emitted to the new -- sink. Emitting header to already started eventlog streams will corrupt the structure -- of eventlog format. -- -- The function is more low-level than 'setEventLogHandle' but doesn't recreate underlying -- file descriptor and is intended to use with 'getEventLogCFile' to save and restore -- current sink of the eventlog. -- -- @since 4.10.0.0 setEventLogCFile :: Ptr CFile -> Bool -> Bool -> IO () -- | The 'getEventLogCFile' function returns current sink of the eventlog, if eventlog -- profiling is available and enabled at runtime. -- -- The function is intented to be used with 'setEventLogCFile' to save and restore -- current sink of the eventlog. -- -- @since 4.10.0.0 getEventLogCFile :: IO (Ptr CFile) -- | Setting size of internal eventlog buffers. The size should be not -- too small to contain at least one event. -- -- If RTS started with '-lm' the chunks of memory buffer is also resized. -- -- The larger the buffers the lesser overhead from event logging, but -- larger delays between data dumps. -- -- See also: 'getEventLogChunk', 'getEventLogBufferSize' setEventLogBufferSize :: Word -> IO () -- | Getting size of internal eventlog buffers. -- -- See also: 'setEventLogBufferSize', 'getEventLogChunk' getEventLogBufferSize :: IO Word -- | Get next portion of the eventlog data. -- -- If RTS started with '-lm' flag then eventlog is stored in memory buffer. -- -- The function allows to pop chunks out of the buffer. Return value of Nothing -- means that there is no any filled chunk of data. -- -- If the function returns nonzero value the parameter contains full chunk -- of eventlog data with size of the returned value. Caller must free the -- buffer with 'free' from 'Foreign.Marshal.Alloc', the buffer isn't referenced -- anywhere anymore. -- -- If nobody calls the function with '-lm' flag on then the memory is kinda -- to be exhausted. -- -- If '-lm' flag is off, the function returns always 'Nothing'. -- -- See also: 'setEventLogBufferSize' getEventLogChunk :: IO (Maybe CStringLen) }}} References: 1. [http://ncrashed.github.io/blog/posts/2016-06-12-hsoc-acceptance.html HSOC project description] 2. [http://ncrashed.github.io/blog/posts/2016-06-22-hsoc-rts.html Design choices for implementation] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11501: Building nofib/fibon returns permission denied
by GHC 08 Jun '17

08 Jun '17

#11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 7.10.3 benchmark suite | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building nofib/fibon returns permission denied: {{{ == make boot - --no-print-directory; in /h/ywang30/nofib/fibon/Hackage/Bzlib ------------------------------------------------------------------------ // Codec/Compression/BZip/Stream.hsc make[3]: execvp: //: Permission denied make[3]: *** [Codec/Compression/BZip/Stream.hs] Error 127 }}} Steps to reproduce: Edit nofib/mk/boilerplate.mk:35 to NoFibSubDirs = fibon make clean && make boot in nofib/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13373: Handle long file paths on Windows
by GHC 07 Jun '17

07 Jun '17

#13373: Handle long file paths on Windows ----------------------------------------+--------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In the past, Cabal and GHC have run into Windows' PATH_MAX path size limitation, which caps the length of file system paths at 260 characters. Examples: * https://github.com/haskell/cabal/issues/3972 * https://ghc.haskell.org/trac/ghc/ticket/10777 It would be really great if Haskell's base libraries handled long file system paths correctly. There are a few possibilities for achieving this: * Call GetShortPathName https://msdn.microsoft.com/en- us/library/windows/desktop/aa364989(v=vs.85).aspx before calling any Windows API function, if we notice the file path is too long. The bad: Windows has to store the alias, and this aliasing mechanism may be disabled (but maybe this never happens in practice). * Rewrite the core libraries to use the Unicode versions of functions, which support longer paths. We need to add the `\\?\` prefix in this case. However, this prefix is not supported by all functions, and it turns off automatic expansion in the path string (so `..` is not interpreted.) Care would need to be taken to not break existing code. * For Windows 10 only, opt into transparent long path support using a manifest. See the bottom of https://msdn.microsoft.com/en- us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath Downside: this only works for Windows 10 An alternative plan is to build and publish an alternative Windows IO library, which is a drop-in replacement for the IO functionality implemented in base but is long paths. We can use this to test paths and provide better functionality to old versions of GHC, before merging the changes back into base proper. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11317: Test prog003 fails with segfault on Windows (GHCi)
by GHC 07 Jun '17

07 Jun '17

#11317: Test prog003 fails with segfault on Windows (GHCi) --------------------------------------+------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: #11234 Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- On my `x86_64` Windows machine test `prog003` fails with a segfault: {{{ cd ./ghci/prog003 && ghciWayFlags=-static HC="/home/Rik/ghc/inplace/bin /ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -dno-debug-output -no- user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history " "/home/Rik/ghc/inplace/bin/ghc-stage2.exe" -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <prog003.script > prog003.run.stdout 2> prog003.run.stderr >> prog003.run.stdout 2>> prog003.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Run 1 a :: Int -> Int 168 Run 2 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 3 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 4 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 5 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 6 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 7 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 8 Segmentation fault/access violation in generated code Stderr: *** unexpected failure for prog003(ghci) }}} (I do not think it is an access violation error since when I remove [https://github.com/ghc/ghc/blob/c2fab84239299176a8e72aa26ae894019d677bd9/te… line 65] and everything below line 70, the same stdout is generated.) This looks related to ticket #11234. The GHC version used was [http://git.haskell.org/ghc.git/commit/df6cb57b32d94b7f6f7c9a86207adfeee9712… df6cb57b32d94b7f6f7c9a86207adfeee9712ed6], although I already noticed the problem with a version a few days older. If someone could point me to information about how to install GDB suitable for debugging GHC on my Windows machine I will try to post the stack trace. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8703: Use guard pages rather than heap checks
by GHC 07 Jun '17

07 Jun '17

#8703: Use guard pages rather than heap checks ------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- By mmap'ing memory using MAP_ANONYMOUS (or /dev/zero) as PROT_NONE (Windows has an equivalent functionality with VirtualAlloc), it's possible to create a page that will fault when read or written to. It may be possible to remove the heap checks in the runtime, speeding up allocations, and instead expand the heap when a fault is raised. This is likely cheaper for large pages full of many small allocations than the cost of the heap checking branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8