- ghc-tickets - Haskell.org

[GHC] Batch modify: #13072, #13078, #13090, #13091, #13092, #13093, ...
by GHC 21 Jun '18

21 Jun '18

Batch modification to #13072, #13078, #13090, #13091, #13092, #13093, #13152, #13153, #13154, #13176, #13189, #13225, #13226, #13243, #13253, #13309, #13331, #13346, #13357, #13360, #13363, #13390, #13406 by bgamari: milestone to 8.6.1 Comment: This will not be addressed in GHC 8.6. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=13072%2C13078%2C13090%2C13091%2C13…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14413: Profiling breaks determinism
by GHC 21 Jun '18

21 Jun '18

#14413: Profiling breaks determinism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: determinism | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While looking at #5889 I noticed that `CostCentre` currently includes a `Unique` (although it's represented as an `Int` for reasons that aren't relevant here; I change this in Phab:D4148). This unique identifies the cost centre and appears to be derived from the unique of a binder. This presumably breaks determinism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13240: Make it easier to find builds we may want to cancel
by GHC 21 Jun '18

21 Jun '18

#13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Trac & Git | 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: -------------------------------------+------------------------------------- I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples: 1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest. 2. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific. 3. Only documentation files have changed. Building these on one platform should be sufficient. 4. A differential was closed by a commit. Only the most recent build will be useful, if that. It would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13205: Run `validate --slow` during CI at least sometimes.
by GHC 21 Jun '18

21 Jun '18

#13205: Run `validate --slow` during CI at least sometimes. -------------------------------------+------------------------------------- Reporter: dobenour | Owner: 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: -------------------------------------+------------------------------------- We really should run `validate --slow` at times. It would catch #13204. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10059: :i doesn't work for ~
by GHC 21 Jun '18

21 Jun '18

#10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs Prelude> :set -XTypeOperators Prelude> :i (~) <interactive>:1:2: parse error on input ‘~’ Prelude> :k (~) (~) :: k -> k -> Constraint }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15297: Add support for insert, extract and broadcast SIMD instructions for native X86 codegen
by GHC 21 Jun '18

21 Jun '18

#15297: Add support for insert, extract and broadcast SIMD instructions for native X86 codegen -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15297> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

21 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 simonpj): PS: the bad-ness of 'make clean' is also a worry. It wasted a lot of your time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

21 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 simonpj): Well this is surprising news, but I think good news too. Maybe we can kill off the state hack altogether! But before we do that, let's really understand our data. (A minor point: in the nfib-analyse output, the column headings are cut off in the summary table; can you use shorter file names?) * I'm astounded by the reduction in compile time (and compiler allocation), in both variants. Is that caused by (a) a faster GHC stage 2, or (b) smaller Core sizes? Could you pick a module with a particularly big reduction, and dig into why? I confess that I am a bit suspicious. Compile times don't usually halve! * Binary sizes go up 5% when "GHC is compiled with -fno-state-hack". I think that the important thing is that the '''libraries''' (which are linked into the nofib binary) are compiled with -fno-state-hack. I doubt it's caused by the fact that ghc-stage2 is compiled with -fno-state-hack. Can you confirm? * And if binary sizes go up by 5% because the libraries are getting bigger, is that a generic 5% increase in .o file size? Or do a few key modules get a lot bigger? It's puzzling because the per-moudule "Module Sizes" stats in the nofib log suggest that there is an essentially-zero effect on nofib module sizes. * As I wrote above, the motivation for the state hack is functions lie {{{ f :: [Int] -> IO () f xs = print ys >> print xs where ys = reverse xs test 0 = return () test n = f [1,n] >> test (n-1) }}} which I expected to be much less efficient without the state hack. Would it be worth trying to demonstrate a program that does get worse in this way? I'm still amazed at how good the results are! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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