June 2018 - ghc-tickets

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): Did 4 full runs of compiling GHC from scratch and then compiling and running nofib, with different configurations. Here's what happened. 1. "vanilla": compile everything normally (the `prof` build that comes with GHC). Everything works as expected. 2. "nsh": compile everything with `-fno-state-hack` (GHC itself, libraries, nofib). Everything works as expected. 3. "stage1": compile GHC normally, nofib with `-fno-state-hack`, but use stage1 compiler instead of stage2. Everything works as expected. 4. "nofib-nsh": compile GHC normally, nofib with `-fno-state-hack`. GHC segfaults while compiling `Main.hs` from the bernouilli program (which simply happens to be the first one it encounters). Despite passing `-dcore-lint`, I get no linter output. Here's the log: {{{ ------------------------------------------------------------------------ == Recursively making `all' in runstdtest nofib-analyse imaginary spectral real shootout ... PWD = /home/tobias/well-typed/devel/ghc/HEAD/nofib ------------------------------------------------------------------------ ------------------------------------------------------------------------ == make all ; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/runstdtest ------------------------------------------------------------------------ rm -f -f runstdtest echo '#!/usr/bin/perl' >> runstdtest echo '$RM = "rm -f";' >> runstdtest echo '$CONTEXT_DIFF = "diff -U 1";' >> runstdtest cat runstdtest.prl >> runstdtest chmod +x runstdtest Finished making all in runstdtest: 0 ------------------------------------------------------------------------ == make all ; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/nofib-analyse ------------------------------------------------------------------------ make[1]: Nothing to be done for 'all'. Finished making all in nofib-analyse: 0 ------------------------------------------------------------------------ == make all ; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/imaginary ------------------------------------------------------------------------ ------------------------------------------------------------------------ == Recursively making `all' in bernouilli digits-of-e1 digits-of-e2 exp3_8 gen_regexps integrate paraffins primes queens rfib tak wheel-sieve1 wheel- sieve2 x2n1 kahan ... PWD = /home/tobias/well-typed/devel/ghc/HEAD/nofib/imaginary ------------------------------------------------------------------------ ------------------------------------------------------------------------ == make all --no-print-directory; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/imaginary/bernouilli ------------------------------------------------------------------------ HC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -dcore-lint -rtsopts RUNTEST_OPTS = -ghc-timing ==nofib== bernouilli: time to compile Main follows... /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc- timing -H32m -hisuf hi -fno-state-hack -O2 -dcore-lint -rtsopts -c Main.hs -o Main.o ../../mk/suffix.mk:23: recipe for target 'Main.o' failed make[2]: *** [Main.o] Segmentation fault (core dumped) Failed making all in bernouilli: 1 ../mk/ghc-recurse.mk:65: recipe for target 'all' failed make[1]: *** [all] Error 1 Failed making all in imaginary: 1 mk/ghc-recurse.mk:65: recipe for target 'all' failed make: *** [all] Error 1 }}} Unfortunately I hadn't done a run with GHC stage1 compiled with `-fno- state-hack`; I'll do that next. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14502: Build Alpine Linux binary distributions
by GHC 19 Jun '18

19 Jun '18

#14502: Build Alpine Linux binary distributions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Continuous | Version: 8.2.1 Integration | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: 14057 Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At least three people have come to me asking for Alpine Linux bindists. Given that Alpine is a fair bit different from most other distributions and can be useful in containers, this seems fairly reasonable to me. Terrorjack has some useful-looking automation at https://github.com/TerrorJack/meikyu. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15043: Expand type synonym
by GHC 18 Jun '18

18 Jun '18

#15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | 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: -------------------------------------+------------------------------------- Using GHC 8.2.2 and `stack build --ghc-options=-fprint-expanded-synonyms` I have the following type synonym for servant: {{{#!hs type Get302 (cts :: [*]) (hs :: [*]) = Verb 'GET 302 cts (Headers (Header "Location" String ': hs) NoContent) }}} and get the following error message when `String` is mismatched for `Text`: {{{ • Couldn't match type ‘Text’ with ‘[Char]’ Expected type: AsServerT App :- ("login" :> ("callback" :> (QueryParam "code" Text :> (QueryParam "state" Text :> MyApp.Types.Servant.Get302 '[PlainText] '[Header "Set-Cookie" SetCookie, Header "Set-Cookie" SetCookie])))) Actual type: Maybe Code -> Maybe Text -> App (Headers '[Header "Location" Text, Header "Set- Cookie" SetCookie, Header "Set-Cookie" SetCookie] NoContent) }}} The error is confusing as type synonym is not expanded and offending `Header` is missing from the output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

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

18 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 abhir00p): Some work has been done to add the `VecFormat` although we have restructured the data representation and instead of creating a new `VecFormat` type added an additional constructor in the `Format` data type. The new representation is also likely to change depending on the use cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14283: Remove the special case for tagToEnum# in the code generator?
by GHC 18 Jun '18

18 Jun '18

#14283: Remove the special case for tagToEnum# in the code generator? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- The only remaining primop (aside from `unsafeCoerce#` and `seq`) that produces an enumeration type is `tagToEnum#`. There is some magic in the code generator to make garbage collection relating to this work as it has historically. We want to get rid of the special case. Simply removing it altogether actually does seem to work, but the code we generate likely isn't quite the same. The challenge here is that (despite what I thought earlier) we definitely ''can'' end up in code generation, under certain circumstances, with {{{#!hs case tagToEnum# @t x of ... }}} How does this happen? After all, in `caseRules` we carefully remove every case on `tagToEnum#` and `dataToTag#` applications! The trouble comes when CorePrep puts everything in A-normal form. Strict function applications are transformed into `case` forms, so {{{#!hs f (tagToEnum# x) }}} will become {{{#!hs case tagToEnum# x of y DEFAULT -> f y }}} Suddenly we have that ugly case! Hmph. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13944: Introduce synchronized FFI
by GHC 18 Jun '18

18 Jun '18

#13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- During hacking on ghc I/O libraries, i find an [https://github.com/winterland1989/stdio/tree/master/bench/diskIO interesting situation], to summarize: There're some FFI calls that vary a lot in time duration, this makes unsafe FFI bad because it make GC hard to synchronize all capacities. OTOH safe FFI 's overhead is too large to justify its usage. After some though i think we should Introduce a new FFI type, let call it `synchronized` for now, it should: 1. Have the same requirement as safe FFI of what kind of argument we can pass, e.g. pinned ByteArray, pass by value primitive type, etc. 2. It works like unsafe FFI call by directly jump to c code using current capacity's stack. 3. It should mark current capacity GC ready, and doesn't participate next GC. The point is that if a FFI call doesn't need GC guarantee, then it shouldn't stop GC running. The next GC will not be running with all threads, but that's not too terrible since it doesn't scale too much anyway. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13709: Drop GCC Driver
by GHC 18 Jun '18

18 Jun '18

#13709: Drop GCC Driver ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The original reason for the Windows GCC driver was to correct hard-coded paths in the GCC build from the `msys` project. The `msys2` builds we now exclusively use no longer have these issues. Which means 90% of the reason for the driver is gone. Given the recent issues with the driver. We can/should simplify things and drop it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13280: Consider deriving more Foldable methods
by GHC 18 Jun '18

18 Jun '18

#13280: Consider deriving more Foldable methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- We currently derive `foldMap` and `foldr`, but some others may deserve attention as well. * The most critical spots are probably `length` and `null`. Deriving these instead of using the defaults can change the orders of growth! Given `data Tree a = Bin !(Tree a) a !(Tree a) | Tip`, we surely don't want `null` to traverse the whole spine of the tree when it's quite immediately obvious that `Bin` is never null. And if a constructor contains a type with a very efficient `length` or `null` implementation (e.g., one that stores its own size), we certainly want to use that. * `foldl` typically ends up with rather different code than `foldr` (for a recursive type) even after simplification. We need to check whether this has a performance impact, but my bet is that it will in cases where the optimizer can't understand what's going on well enough. * `foldl'` and `foldr'` are a bit tricky. Ideally, if we have something like `data T a = C (G a) a | ...` then we'd like to be able to use `G`'s `foldl'` definition to define `T`'s. Unfortunately, different types in the wild have different `foldl'` semantics (and indeed the semantics for `[]` changed by mistake fairly recently). So we have to decide to what extent the derived semantics should depend on the choices of included types. I think we should probably just depend, because that seems likely what people will expect and want. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13280> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

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

18 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): To do: - turn on core linter - see if it still crashes when compiling with the stage1 compiler - compile nofib with -fno-state-hack, but with the "clean" compiler (compiled with state hack) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15272: Handle implied flags more intuitively
by GHC 18 Jun '18

18 Jun '18

#15272: Handle implied flags more intuitively -------------------------------------+------------------------------------- Reporter: tdammers | 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: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14963 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Many flags in GHC imply other flags. For example, enabling `-fdefer-type- errors` also enables `-fdefer-type-holes` and `-fdefer-out-of-scope- variables`: {{{ GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Prelude> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: Prelude> :set -fdefer-type -fdefer-type-errors -fdefer-typed-holes Prelude> :set -fdefer-type-errors Prelude> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fdefer-type-errors -fdefer-typed-holes -fdefer-out-of-scope-variables -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: }}} This is fine. Disabling previously enabled flags does not disable the implied flags: `-fno-defer-type-errors` does not also set `-fno-defer-type-holes` and `-fno-defer-out-of-scope-variables`. This is also fine in principle; otherwise, setting `-fdefer-type-holes -fno-defer-type-errors` would do the unintuitive thing of setting neither flag. But it does lead to unintuitive behavior when the implied flags have never been touched explicitly: setting `-fdefer-type-errors`, and then later `-fno-defer-type-errors`, leaves `-fdefer-type-holes` and `-fdefer-out-of- scope-variables` set, even though the user never asked for them: {{{ Prelude> :set -fdefer-type-errors Prelude> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fdefer-type-errors -fdefer-typed-holes -fdefer-out-of-scope-variables -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: Prelude> :set -fno-defer-type-errors Prelude> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fdefer-typed-holes <- These two are -fdefer-out-of-scope-variables <- unexpected! -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: }}} So we have a conundrum: when unsetting a flag, we may or may not need to unset the options it implies - neither is always correct, so in order to figure out what to do, we need to know *why* the flag was set. But it's even worse: if we have a flag X, and two other flags A and B, both of which imply X, and we first set A and B, and then unset B, we would have to keep X set, because otherwise we would break A. But if we then also unset A, we would have to also unset X. Tracking which option implicitly enabled which other option, and correctly resolving that, seems like terribly messy business. So I propose a different solution: 1. Maintain one set of `DynFlags` that holds only those flags that were requested explicitly. Setting `-fdefer-type-errors` would only set `Opt_DeferTypeErrors` in this set, but none of the implied flags; and `-fno-defer-type-errors` would simply unset `Opt_DeferTypeErrors`. 2. Maintain another set of `DynFlags` that holds the effective flags: we can always calculate these based on the explicit flags. We could either do this on the fly, just before running the actual compilation / evaluation, or we could keep the data structure around and only update it when the explicit flags have changed. This way, setting and unsetting flags will always do the right thing, and we don't throw away the information about which flags were set explicitly. This is probably more relevant in GHCi, because in plain GHC, one would typically just set all the needed flags at once and then never change them again until the next run; but in GHCi, modifying compiler flags between evaluations is a common thing to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4