June 2018 - ghc-tickets

[GHC] #15288: Figure out what to do about retainer profiling debugging code
by GHC 21 Jun '18

21 Jun '18

#15288: Figure out what to do about retainer profiling debugging code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- `rts/RetainerProfile.c` has a hope pile of code guarded by the unset-by- default `DEBUG_RETAINER` macro. I tried to resuscitate it while debugging #15287, but it seems like a bit of a lost cause. In particular, the `cost()` function which seems to be critical to the accounting done by in this code was removed in dbef766ce79e37a74468a07a93b15ba1f06fe8f8. While I can't tell for certain, it's possible that this "cost" notion coincides with the value currently computed by `closure_sizeW`. Regardless, we should either drop this code if it's beyond saving or fix it to do something useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15288> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15257: Broken symlinks in lndir build tree
by GHC 20 Jun '18

20 Jun '18

#15257: Broken symlinks in lndir build tree -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I routinely create separate build trees using lndir (per wiki:WorkingConventions/Git#Creatingabuildtreewithlndir). However it seems this is currently broken by the code to copy `fs.{c,h}` to various places in `./configure` (see Phab:D4416): {{{ $ mkdir ghc-validate $ cd ghc-validate $ lndir ../ghc $ ln -s ../ghc/.git $ ./boot [...] $ ./configure [...] $ find . -name "fs.*" | xargs file ./rts/fs.c: broken symbolic link to ../../../ghc/utils/fs/fs.c ./rts/fs.h: broken symbolic link to ../../../ghc/utils/fs/fs.h ./utils/fs/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c ./utils/fs/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h ./utils/unlit/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c ./utils/unlit/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h ./utils/lndir/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c ./utils/lndir/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h ./libraries/base/include/fs.h: broken symbolic link to ../../../ghc/utils/fs/fs.h ./libraries/base/cbits/fs.c: broken symbolic link to ../../../ghc/utils/fs/fs.c }}} This can be fixed by manually correcting the symlinks, but it is a bit of pain, especially for `./validate`. {{{ ln -fs ../../ghc/utils/fs/fs.c rts/fs.c ln -fs ../../ghc/utils/fs/fs.h rts/fs.h ln -fs ../../../../ghc/utils/fs/fs.c libraries/base/include/fs.c ln -fs ../../../../ghc/utils/fs/fs.h libraries/base/include/fs.h ln -fs ../../../../ghc/utils/fs/fs.c libraries/base/cbits/fs.c }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15294: Unused "foralls" prevent types from being Coercible
by GHC 20 Jun '18

20 Jun '18

#15294: Unused "foralls" prevent types from being Coercible -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: Roles | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just a quick question, do these have the same representation? {{{#!hs newtype A where A :: (Int -> Bool) -> A newtype B where B :: (forall (a::Type). Int -> Bool) -> B }}} I'm wondering because they aren't `Coercible` {{{ > :t coerce :: A -> B <interactive>:1:1: error: • Couldn't match representation of type ‘forall a. Int -> Bool’ with that of ‘Int -> Bool’ arising from a use of ‘coerce’ • In the expression: coerce :: A -> B }}} What about a new type `C`, that isn't `Coercible` to `B` either {{{#!hs newtype C where C :: (forall k (a :: k). Int -> Bool) -> C }}} Some is true when it's just the order of variables {{{#!hs -- D is not Coercible to E, "can't match type ‘Bool’ with ‘Ordering’" newtype D where D :: (forall (a::Bool) (b::Ordering). Int -> Bool) -> D newtype E where E :: (forall (a::Ordering) (b::Bool). Int -> Bool) -> E }}} My question is is this intended? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15294> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 20 Jun '18

20 Jun '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, so it turns out that make clean doesn't actually clean things up thoroughly enough. I did another test run, building both GHC and nofib from a fresh checkout for each run, and now everything works just fine. So it seems that the core dumps I got earlier were somehow caused by artifacts from a previous build still being in the build tree somewhere; clearly if you link things together in ways they weren't meant to, strange behavior is to be expected. Now armed with that, and a fixed `fasta` implementation from #15225, I managed to do six nofib runs; the interesting ones are: - Both GHC and nofib compiled with the state hack in place - this is the current situation (`nofibrun-gs_ns2.log`) - GHC with the state hack, nofib compiled with `-fno-state-hack` (`nofibrun-gs-nn2.log` - Both GHC and nofib compiled with `-fno-state-hack` (`nofibrun- gn_nn2.log`) Results from nofib-analyse attached; key takeaway however is that the difference overall is small and slightly in favor of removing the state hack. A few interesting deviations that stand out: - GHC compiled with `-fno-state-hack` consistently produces larger binaries, by about 5% - Programs compiled with a GHC compiled with `-fno-state-hack` run faster by 3.2% on average, but there is a lot of deviation - Most of the above improvements seem to be from more efficient GC - Compile times differ drastically; vanilla GHC compiling programs with `-fno-state-hack` is 23.6% faster on average than the same compiler with the state hack; compiling GHC itself with `-fno-state-hack` and then compiling the nofib suite also with `-fno-state-hack` is almost 50% faster than compiling everything normally. The difference in allocations is even more whopping, with 35.5% and 58.3% respectively. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 20 Jun '18

20 Jun '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-analyse.log.gz" added. nofib analyse output (gzipped because of size limit) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15098: Missing instances for Down
by GHC 20 Jun '18

20 Jun '18

#15098: Missing instances for Down -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | 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: -------------------------------------+------------------------------------- `Down` in `Data.Ord` is missing the instances for `Monad`, `MonadFix`, `MonadZip`, `Eq1`, `Ord1`, `Show1`, `Read1`, `Data`, `Generic`, `Generic1`, `Foldable`, `Traversable`. We added a bunch of common sense 'only one definition' instances over the last few GHC releases, but apparently we missed `Data.Ord.Down`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14023: Split up glasgow_exts.rst
by GHC 19 Jun '18

19 Jun '18

#14023: Split up glasgow_exts.rst -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | 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: -------------------------------------+------------------------------------- The `docs/users-guide/glasgow_exts.rst` is crazy large. This makes it difficult to navigate both while editing and reading. It should probably be split up into multiple files along the top-level headings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15291: Incorrect SCC name parsing according to user manual
by GHC 19 Jun '18

19 Jun '18

#15291: Incorrect SCC name parsing according to user manual -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- The user manual says this about SCC names: > The syntax of a cost centre annotation for expressions is > > {-# SCC "name" #-} <expression> > > where "name" is an arbitrary string, that will become the name of your cost centre as it appears in the profiling output, and <expression> is any Haskell expression. However GHC is actually more strict about SCC strings, for example, it doesn't accept spaces: {{{ $ cat test.hs main = {-# SCC "test test" #-} return () $ ghc test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:16: error: Spaces are not allowed in SCCs | 1 | main = {-# SCC "test test" #-} return () | ^^^^^^^^^^^ }}} It's also possible that GHC is right and user manual is wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15291> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 19 Jun '18

19 Jun '18

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by carter): I'm supervising abhirr00p on this, theres a bunch of stuff still to do for even rudimentary portable SIMD support. Theres a few gotchas that will be clear from sharp edges in this first iteration -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 19 Jun '18

19 Jun '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Additional runs: - stage1 GHC without state hack and nofib without state hack -> succeeds - stage2 GHC without state hack and nofib with state hack -> succeeds So either there is something strange going on with the combination GHC + libs with state hack, nofib without state hack; or my testing leaves artifacts somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0