September 2018 - ghc-tickets

Re: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64
by GHC 19 Sep '18

19 Sep '18

#4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arrowd): It would be great if you do 8.4.3. To make the bindist be consumable by stack you'd need to compile it on the least supported FreeBSD version (10.4 at the moment). You can take a look at GHC port [1], if interested. Feel free to bug me with any questions. Thanks in advance. 1. https://svnweb.freebsd.org/ports/head/lang/ghc/Makefile?view=markup -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4022#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11295: Figure out what LLVM passes are fruitful
by GHC 19 Sep '18

19 Sep '18

#11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (LLVM) | 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: -------------------------------------+------------------------------------- Builds using GHC's LLVM backend are currently substantially slower than GHC's own native code generator. There are a few possible reasons for this, 1. the cost of forking processes and serializing/parsing LLVM's intermediate representation 2. the cost of the more powerful optimizations responsible for LLVM's (hopefully) better code generation 3. the cost of redundant optimizations overlapping effort already expended by GHC Given that some architecture (e.g. ARM) are only supported by LLVM and therefore suffer considerably at the hand of our slow builds, we should try to reduce # -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #15652: SerializedCompact has a [(Ptr a, Word)] instead of a custom datatype
by GHC 19 Sep '18

19 Sep '18

#15652: SerializedCompact has a [(Ptr a, Word)] instead of a custom datatype -------------------------------------+------------------------------------- Reporter: chessai | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: | Version: 8.4.3 libraries/compact | Keywords: ghc-compact, | Operating System: Unknown/Multiple compact regions | Type of failure: Runtime Architecture: aarch64 | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data SerializedCompact a = SerializedCompact { serializedCompactBlockList :: [(Ptr a, Word)] , serializedCompactRoot :: Ptr a } }}} I'm not sure why the first member of {{{SerializedCompact}}} isn't something like {{{#!hs data CompactBlock a = CompactBlock {-# UNPACK #-} (Ptr a) {-# UNPACK #-} Word }}} so the {{{Ptr}}} can unpack into the constructor, which isn't possible with {{{(,)}}}. {{{SerializedCompact}}} would then look like {{{#!hs data SerializedCompact a = SerializedCompact { serializedCompactBlockList :: [CompactBlock a] , serializedCompactRoot :: Ptr a } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15634: GHCi: Segmentation fault Data.List.sum large number
by GHC 19 Sep '18

19 Sep '18

#15634: GHCi: Segmentation fault Data.List.sum large number -------------------------------------+------------------------------------- Reporter: ksallberg | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: GHCi | Version: 8.0.1 Keywords: segfault | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, first bug report here, so please let me know what I should provide. I tried to search for this but didn't find it. {{{ kristian@snabbadatorn:~$ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> [1..100] [1,2,3,4,5,6,7,8,9,10,11,12... and so on Prelude> sum [1..10000000] 50000005000000 Prelude> sum [1..100000000] Segmentation fault }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64
by GHC 19 Sep '18

19 Sep '18

#4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I do intend on producing a FreeBSD bindist for 8.6.1. I can try producing one for 8.4.3 as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4022#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch
by GHC 19 Sep '18

19 Sep '18

#4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by osa1): * status: infoneeded => closed * resolution: => invalid Comment: We've fixed a lot of RTS bugs (including retainer profiler bugs) since this was submitted, so I suspect this is fixed. Please reopen if you disagree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4820#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14329: GHC 8.2.1 segfaults while bootstrapping master
by GHC 19 Sep '18

19 Sep '18

#14329: GHC 8.2.1 segfaults while bootstrapping master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Earlier this week the Linux/amd64 Harbormaster started failing somewhat reliably during validation. It seems the stage0 compiler (GHC 8.2.1) often fails with a segmentation fault. This seems to have started with ef26182e2014b0a2a029ae466a4b121bf235e4e4 although I suspect this isn't causal. I was able to capture a core dump of the crashing stage0 compiler which implicates the allocator, {{{ Reading symbols from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/ghc...(no debugging symbols found)...done. [New LWP 25151] [New LWP 25160] [New LWP 25156] [New LWP 25158] [New LWP 25157] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/opt/ghc/8.2.1/lib/ghc-8.2.1/bin/ghc -B/opt/ghc/8.2.1/lib/ghc-8.2.1 -hisuf hi -'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f836aaa2c90 in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so [Current thread is 1 (Thread 0x7f83711b5340 (LWP 25151))] (gdb) bt #0 0x00007f836aaa2c90 in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #1 0x00007f836aaa3211 in allocGroupOnNode () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #2 0x00007f836aa9dd41 in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #3 0x00007f836aa9deb9 in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #4 0x00007f836aa82a39 in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #5 0x00007f836aa7fc06 in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #6 0x00007f836aa9d461 in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #7 0x00007f836aaa423a in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #8 0x00007f836aaa4b3c in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #9 0x00007f836aa8bbc8 in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #10 0x00007f836aa8c912 in ?? () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #11 0x00007f836aa8da01 in scheduleWaitThread () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #12 0x00007f836aa99fae in hs_main () from /opt/ghc/8.2.1/lib/ghc-8.2.1/bin/../rts/libHSrts_thr-ghc8.2.1.so #13 0x0000000000427038 in ?? () #14 0x00007f83694fd2b1 in __libc_start_main (main=0x426fd0, argc=119, argv=0x7fffcfee8078, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffcfee8068) at ../csu/libc- start.c:291 #15 0x0000000000427069 in ?? () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14329> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15569: Constant folding optimises 1 into 3
by GHC 19 Sep '18

19 Sep '18

#15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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: -------------------------------------+------------------------------------- A recent Hadrian issue [1] led me to finding a rather embarrassing bug: {{{#!hs {-# NOINLINE sub #-} -- This is just subtraction in disguise minus :: Int -> Int -> Int minus x y = (8 - y) - (8 - x) {-# NOINLINE minus #-} main :: IO () main = print (2 `minus` 1) }}} When compiled using `ghc-8.6.0.20180810` without optimisation this prints `1`, as expected, but when compiled with `-O` this prints `3`. Here is the incorrect rewrite rule [2]: {{{#!hs (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `add` v) }}} This should be changed to: {{{#!hs (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `sub` v) }}} Happy to submit the fix, but I'm not yet fully convinced that there are no other lurking bugs. This whole constant folding business is very error- prone. [1] https://github.com/snowleopard/hadrian/issues/641 [2] https://github.com/ghc/ghc/blob/master/compiler/prelude/PrelRules.hs#L1786 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #12100: GHC 8.0.1 build segmentation fault in haddock
by GHC 19 Sep '18

19 Sep '18

#12100: GHC 8.0.1 build segmentation fault in haddock -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Skylake iMac OS X 10.11.5. Xcode 7.3.1. march=native. This happens each time I attempt to build 8.0.1. The release candidates were not affected: {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.12.1.1 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP- DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package-id Cabal-1.24.0.0 -package-id array-0.5.1.1 -package-id base-4.9.0.0 -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id ghc-8.0.1 -package-id ghc-boot-8.0.1 -package-id transformers-0.5.2.0 -package-id xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock- library/src/Documentation/Haddock/Types.hs -o utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.12.1.1 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP- DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package-id Cabal-1.24.0.0 -package-id array-0.5.1.1 -package-id base-4.9.0.0 -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id ghc-8.0.1 -package-id ghc-boot-8.0.1 -package-id transformers-0.5.2.0 -package-id xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/dist/build/autogen/Paths_haddock.hs -o utils/haddock/dist/build/Paths_haddock.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.12.1.1 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP- DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package-id Cabal-1.24.0.0 -package-id array-0.5.1.1 -package-id base-4.9.0.0 -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id ghc-8.0.1 -package-id ghc-boot-8.0.1 -package-id transformers-0.5.2.0 -package-id xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock- library/src/Documentation/Haddock/Utf8.hs -o utils/haddock/dist/build/Documentation/Haddock/Utf8.dyn_o make[1]: *** [utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Segmentation fault: 11 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Segmentation fault: 11 make[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Segmentation fault: 11 make[1]: *** [utils/haddock/dist/build/Paths_haddock.dyn_o] Segmentation fault: 11 make[1]: *** [utils/haddock/dist/build/ResponseFile.dyn_o] Segmentation fault: 11 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13279: Check known-key lists
by GHC 19 Sep '18

19 Sep '18

#13279: Check known-key lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I noticed that `fmap` (for example) has a known key {{{#!hs fmapName = varQual gHC_BASE (fsLit "fmap") fmapClassOpKey fmapClassOpKey = mkPreludeMiscIdUnique 173 }}} but its `RdrName` doesn't refer to it. {{{#!hs fmap_RDR = varQual_RDR gHC_BASE (fsLit "fmap") }}} Is there a reason for this? If not, it seems likely that we could get a bit of a speed-up by using `fmapName` here. We may also consider making `liftA2` known-key for `Traversable` deriving. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8