March 2018 - ghc-tickets

[GHC] #13520: instance Alternative ZipList
by GHC 26 Apr '18

26 Apr '18

#13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- The paper "From monoids to near-semirings: the essence of MonadPlus and Alternative`" mentions > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. Like the `Alternative` instance for `Maybe`, the one for `ZipList` has a left bias. > > {{{#!hs > instance Alternative ZipList where > empty :: ZipList a > empty = ZL [] > > (<|>) :: ZipList a -> ZipList a -> ZipList a > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > }}} Has this been considered for base? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13876: Check 'pure' method of 'Applicative (WrappedMonad m)'
by GHC 26 Apr '18

26 Apr '18

#13876: Check 'pure' method of 'Applicative (WrappedMonad m)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- Should {{{#!hs instance Monad m => Applicative (WrappedMonad m) where pure = WrapMonad . pure WrapMonad f <*> WrapMonad v = WrapMonad (f `ap` v) }}} not use `return`? {{{#!hs instance Monad m => Applicative (WrappedMonad m) where pure = WrapMonad . return WrapMonad f <*> WrapMonad v = WrapMonad (f `ap` v) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13876> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14200: Deprecate WrappedMonad
by GHC 26 Apr '18

26 Apr '18

#14200: Deprecate WrappedMonad -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 libraries/base | 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 believe that `Control.Applicative.WrappedMonad` is obsolete now that AMP is implemented. I would propose deprecating `WrappedMonad` as a result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14200> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8406: Invalid object in isRetainer() or Segfault
by GHC 25 Apr '18

25 Apr '18

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- When compiling with -rtsopts -threaded -prof -fprof-auto -caf-all and running with -N4 -hr I get a "Segmentation fault" every time. If I run with -N4 -qg1 -hr, I either get a segfault or internal error: Invalid object in isRetainer(): 40 When the segfault happens, it happens quickly. If the segfault doesn't happen, the program runs for about 5 seconds and I get "invalid object" error (always 40). Without -hr, I have never gotten a segfault. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples
by GHC 25 Apr '18

25 Apr '18

#14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.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: -------------------------------------+------------------------------------- It seems that it should be okay to `unsafeCoerce` between types that wrap certain things in unboxed unary tuples and ones that do not. For example, {{{#!hs unsafeCoerce :: (A -> B) -> A -> (# B #) unsafeCoerce :: ((# A #) -> B) -> A -> B }}} Generally, I believe `unsafeCoerce :: E1 -> E2` should be okay when the only differences are in what is wrapped in an unboxed unary tuple and both of the following hold: 1. Each new unary tuple wrapper in `E2` is in a positive position. 2. Each new unary tuple wrapper in `E1` is in a negative position. Semantically, {{{#!hs unsafeCoerce :: (A -> B) -> A -> (# B #) = \f a -> let !fa = f a in (# fa #) unsafeCoerce :: ((# A #) -> B) -> A -> B = \f !a -> f a }}} Am I correct in this interpretation? If so, is this something the developers would be willing to commit to and document? The first version in particular (a new unary tuple wrapper in positive position in the result) would be very useful for reducing both source code and generated code size in libraries supporting both strict and lazy operations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14806> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10296: Segfaults when using dynamic wrappers and concurrency
by GHC 25 Apr '18

25 Apr '18

#10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I had a largish program that sometimes segfaulted, the segfault seemingly coming from the code that gets a C pointer from an Haskell function. After much sweat I've managed to produce a self-contained program that exhibits the same behavior: {{{ bitonic@clay /tmp/ptr-crash % uname -a Linux clay 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux bitonic@clay /tmp/ptr-crash % cabal configure --disable-library-profiling -w ghc-7.11.20150411 Resolving dependencies... Configuring ptr-crash-0... bitonic@clay /tmp/ptr-crash % cabal build Building ptr-crash-0... Preprocessing executable 'ptr-crash' for ptr-crash-0... [1 of 1] Compiling Main ( Main.hs, dist/build/ptr-crash/ptr- crash-tmp/Main.o ) Linking dist/build/ptr-crash/ptr-crash ... bitonic@clay /tmp/ptr-crash % strace -f -r -o strace-out ./dist/build/ptr- crash/ptr-crash +RTS -N2 -RTS [1] 26612 segmentation fault (core dumped) strace -f -r -o strace-out ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS }}} I'm running GHC HEAD on a Linux 64bit machine. In the larger program, I'm pretty sure the segfaults happened on GHC 7.8.4 too, but currently I can reproduce it only on 7.10 and later. More details (thanks to Sergei Trofimovich on #ghc for helping me in investigating this): * The segfault only happens when using `-N2` or more. * Curiously, the segfault seems to happen much more often when compiling the program with `-g`. * `strace`ing the program when segfaulting shows that all the threads crash together right after some calls to `mremap`. I've attached the end of the output of `strace`. * `gdb`ing the program and breaking on `mremap` shows that all the calls to `mremap` originate from `getStablePtr`. I've attached a run of `gdb` that shows this pattern. Sergei had a hunch that this had to do with thread-unsafe calls to `mremap`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10296> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13623: join points produce bad code for stream fusion
by GHC 24 Apr '18

24 Apr '18

#13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 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: -------------------------------------+------------------------------------- Below, I am generating to stream fusion streams xs and ys. Both parameterized on k l. The two streams are then concatenated. Finally I do a strict left fold. This example needs the 'vector' package but nothing else. {{{ module Test where import Data.Vector.Fusion.Stream.Monadic as S foo :: Int -> Int -> IO Int foo = \i j -> S.foldl' (+) 0 $ xs i j S.++ ys i j where xs k l = S.enumFromStepN k l 2 ys k l = S.enumFromStepN k l 3 {-# Inline xs #-} {-# Inline ys #-} {-# Inline foo #-} }}} With ghc-8.0.1 I get nice core: {{{ $wfoo_r1Ai $wfoo_r1Ai = \ ww_s1q5 ww1_s1q9 w_s1q2 -> letrec { $s$wfoldlM'_loop_s1xc $s$wfoldlM'_loop_s1xc = \ sc_s1x7 sc1_s1x5 sc2_s1x6 sc3_s1x4 -> case tagToEnum# (># sc2_s1x6 0#) of _ { False -> (# sc_s1x7, I# sc3_s1x4 #); True -> $s$wfoldlM'_loop_s1xc sc_s1x7 (+# sc1_s1x5 ww1_s1q9) (-# sc2_s1x6 1#) (+# sc3_s1x4 sc1_s1x5) }; } in letrec { $s$wfoldlM'_loop1_s1x3 $s$wfoldlM'_loop1_s1x3 = \ sc_s1x2 sc1_s1x0 sc2_s1x1 sc3_s1wZ -> case tagToEnum# (># sc2_s1x1 0#) of _ { False -> $s$wfoldlM'_loop_s1xc sc_s1x2 ww_s1q5 3# sc3_s1wZ; True -> $s$wfoldlM'_loop1_s1x3 sc_s1x2 (+# sc1_s1x0 ww1_s1q9) (-# sc2_s1x1 1#) (+# sc3_s1wZ sc1_s1x0) }; } in $s$wfoldlM'_loop1_s1x3 w_s1q2 ww_s1q5 2# 0# }}} Now the same with ghc-8.2-rc1. Here, [https://github.com/haskell/vector/blob/master/Data/Vector/Fusion/Stream/Mon… Stream.++] function is not fully optimized away (Left and Right constructors!). Instead we have a join point that executes either of the two parts (xs or ys) based on a case w2_s1U2 of {Left -> ; Right ->}. {{{ $wfoo_r23R $wfoo_r23R = \ ww_s1Ue ww1_s1Ui w_s1Ub -> let { x1_a1tj x1_a1tj = I# ww_s1Ue } in let { tb_a1wC tb_a1wC = (x1_a1tj, lvl1_r23Q) } in let { lvl2_s1Yh lvl2_s1Yh = Right tb_a1wC } in joinrec { $wfoldlM'_loop_s1U8 $wfoldlM'_loop_s1U8 w1_s1U0 ww2_s1U6 w2_s1U2 w3_s1U3 = case w1_s1U0 of { __DEFAULT -> case w2_s1U2 of { Left sa_a1yP -> case sa_a1yP of { (w4_a1zr, m1_a1zs) -> case m1_a1zs of { I# x2_a1zw -> case tagToEnum# (># x2_a1zw 0#) of { False -> jump $wfoldlM'_loop_s1U8 SPEC ww2_s1U6 lvl2_s1Yh w3_s1U3; True -> case w4_a1zr of { I# y_a1xT -> jump $wfoldlM'_loop_s1U8 SPEC (+# ww2_s1U6 y_a1xT) (Left (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#))) w3_s1U3 } } } }; Right sb_a1z3 -> case sb_a1z3 of { (w4_a1zr, m1_a1zs) -> case m1_a1zs of { I# x2_a1zw -> case tagToEnum# (># x2_a1zw 0#) of { False -> (# w3_s1U3, I# ww2_s1U6 #); True -> case w4_a1zr of { I# y_a1xT -> jump $wfoldlM'_loop_s1U8 SPEC (+# ww2_s1U6 y_a1xT) (Right (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#))) w3_s1U3 } } } } } }; } in jump $wfoldlM'_loop_s1U8 SPEC 0# (Left (x1_a1tj, lvl_r23P)) w_s1Ub }}} For my stream-fusion heavy code, this yields a slowdown of approximately x4 (10 seconds with ghc-8.2-rc1, 2.5 seconds with ghc-8.0.1). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9678: Warning about __sync_fetch_and_nand semantics from gcc
by GHC 24 Apr '18

24 Apr '18

#9678: Warning about __sync_fetch_and_nand semantics from gcc -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When building ghc, I'm getting warnings about __sync_fetch_and_nand that the semantics have changed for gcc 4.4+. I'm building on Windows, but I don't think that matters. Is this an indication of a problem or does that warning just need to be silenced? I ran the build with gcc 4.8.3: $ inplace/mingw/bin/gcc -v Using built-in specs. COLLECT_GCC=C:\msys64\home\Gintas\ghc\inplace\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=C:/msys64/home/Gintas/ghc/inplace/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.3 /lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-4.8.3/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with- sysroot=/c/mingw483/x86_64-483-posix-seh-rt_v3-rev0/mingw64 --with-gxx- include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable- languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version- specific-runtime-libs --disable-isl-version-check --disable-cloog-version- check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with- tune=core2 --with-libiconv --with-system-zlib --with- gmp=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- mpfr=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- mpc=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- isl=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- cloog=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --enable-cloog- backend=isl --with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw483/x86_64-483-posix-seh- rt_v3-rev0/mingw64/opt/include -I/c/mingw483/prerequisites/x86_64-zlib- static/include -I/c/mingw483/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw483/x86_64-483-posix-seh- rt_v3-rev0/mingw64/opt/include -I/c/mingw483/prerequisites/x86_64-zlib- static/include -I/c/mingw483/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw483/x86_64-483-posix-seh- rt_v3-rev0/mingw64/opt/lib -L/c/mingw483/prerequisites/x86_64-zlib- static/lib -L/c/mingw483/prerequisites/x86_64-w64-mingw32-static/lib' Thread model: posix gcc version 4.8.3 (x86_64-posix-seh-rev0, Built by MinGW-W64 project) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10607: Auto derive from top to bottom
by GHC 22 Apr '18

22 Apr '18

#10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: deriving, | Type of failure: None/Unknown typeclass, auto | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It is very good to see that Template Haskell types are now `Generic` and `DeriveAnyClass` have been implemented. I suppose that this auto-deriving thing can go even further. The problem is like the following: When we manipulate a complex composite JSON object, we need to define a dozen of data types for each of the dozen we may need to derive `Eq`, `Show`, `Generic` etc. Another situaition can be manipulating the AST of a language, there may be dozens of data type definitions, also, for each of them, we need to derive `Show`, `Eq`, `Generic`. Take the old Template Haskell types without `Generic` as an example, I want to make them instances of `Generic` type class, I wrote: {{{#!hs deriving instance Generic FixityDirection deriving instance Generic Inline deriving instance Generic RuleBndr deriving instance Generic Match deriving instance Generic Name deriving instance Generic RuleMatch deriving instance Generic Pred deriving instance Generic Phases deriving instance Generic Con deriving instance Generic Module deriving instance Generic AnnTarget deriving instance Generic Type deriving instance Generic TyVarBndr deriving instance Generic TyLit deriving instance Generic Exp deriving instance Generic Lit deriving instance Generic Pat deriving instance Generic Dec deriving instance Generic Clause deriving instance Generic FunDep deriving instance Generic Foreign deriving instance Generic Fixity deriving instance Generic Pragma deriving instance Generic FamFlavour ... }}} How can we use `Generic`? Say we want to serialize Template Haskell data type with `Binary` type class, Of course, by writing `Binary` empty instances or just derive it with `DeriveAnyClass` extension. However, the problem is that we still need to write deriving Binary dozens of times, as many as the trivial `Generic` deriving declaration above. What if GHC can attemp to derive the instance from the top of the tree down to the leaf in the data type declarations? For example: {{{#!hs data Person = Person Names Address | Student Names Address deriving Generic data Names = Names String deriving Generic data Address = Address Gate deriving Generic type Gate = (String,Int) deriving topdown Eq Person }}} It will generate `Eq` instances of `Person`, `Names` and `Address`, since it is in the Person data declaration tree. I tried to implement a prototype see https://github.com/HaskellZhangSong /derive-topdown It is rather an experiment tryout than a formal implementation. If you think this feature is attractive, I would like to discuss it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do
by GHC 20 Apr '18

20 Apr '18

#10412: isAlphaNum includes mark characters, but neither isAlpha nor isNumber do -------------------------------------+------------------------------------- Reporter: | Owner: Artyom.Kazak | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: unicode | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs > isMark '\768' True > isAlphaNum '\768' True > (isAlpha '\768', isNumber '\768') (False,False) }}} This behavior comes from this piece in WCsubst.c: {{{ unipred(u_iswalnum,(GENCAT_LT|GENCAT_LU|GENCAT_LL|GENCAT_LM|GENCAT_LO| GENCAT_MC|GENCAT_ME|GENCAT_MN| GENCAT_NO|GENCAT_ND|GENCAT_NL)) }}} I'm not sure what should be done here. Is it a bug with isAlpaNum? Or with isAlpha? How does it correspond to iswalnum's behavior in C++? (And if it's a feature and not a bug, then it should definitely be documented.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10412> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11