April 2018 - ghc-tickets

[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

Re: [GHC] #5467: Template Haskell: support for Haddock comments
by GHC 25 Apr '18

25 Apr '18

#5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.2.1 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 kanetw): Do we have a specification for this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5467#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #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

Re: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations
by GHC 23 Apr '18

23 Apr '18

#5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #3872 #5400 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): comment:5 make it panic (with a helpful message) rather than looping. So that's an improvement. Better still would be to avoid looping or running out of fuel. But I have no idea how to do that. A modest improvement would be to produce a more civilised halt rather than a panic. But I don't think it's trivial to do so, and it's cosmetic so perhaps not that important. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5448#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations
by GHC 23 Apr '18

23 Apr '18

#5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #3872 #5400 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This ticket isn't marked as fixed and I'm not sure if others would consider it fixed (a compiler should never reject a program because of an optimization pass). That's why I put fixed in quotes above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5448#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15077: Suggest NoMonomorphismRestriction or type signature
by GHC 22 Apr '18

22 Apr '18

#15077: Suggest NoMonomorphismRestriction or type signature -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.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: -------------------------------------+------------------------------------- The following program results in a compile error. To fix the error one can either give an explicit signature or turn on `NoMonomorphismRestriction`. Could the compile error please mention both of these options (and provide the exact type signature required)? {{{ type family G a b data D a = D (G a ()) d = D () }}} {{{ • Couldn't match expected type ‘G a0 ()’ with actual type ‘()’ The type variable ‘a0’ is ambiguous • In the first argument of ‘D’, namely ‘()’ In the expression: D () In an equation for ‘d’: d = D () • Relevant bindings include d :: D a0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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

Re: [GHC] #5448: GHC stuck in infinite loop compiling with optimizations
by GHC 22 Apr '18

22 Apr '18

#5448: GHC stuck in infinite loop compiling with optimizations -------------------------------------+------------------------------------- Reporter: ronwalf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #3872 #5400 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): sgraf do you know where i can see this bug current status? When i search on this page i don't find "fixed" apart from your comment. What would be interesting is to test all the test cases (found in related bugs) with the last version of GHC 8.4.* I think this Panic is very helpful. It could be further improved to give some tips on how the code can be rewritten to have it compiled correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5448#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3872: New way to make the simplifier diverge
by GHC 22 Apr '18

22 Apr '18

#3872: New way to make the simplifier diverge -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5400 #5448 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #5400 #5448 Comment: This doesn't loop infinitely anymore with GHC 8.2.1 and instead panics: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone rir_s1bm To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 11721 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\simplCore\SimplMonad.hs:199:31 in ghc:SimplMonad }}} I think this should result in a warning rather than in a crash. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3872#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0