August 2016 - ghc-tickets

[GHC] #12437: 20% regression in max_bytes_used for T1969
by GHC 19 Mar '18

19 Mar '18

#12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.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: -------------------------------------+------------------------------------- This is 20% worse: {{{ =====> T1969(normal) 1 of 1 [0, 0, 0] cd "./T1969.run" && "/data/users/smarlow/ghc/inplace/test spaces/ghc- stage2" -c T1969.hs -dno-debug-output -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups +RTS -G1 -RTS +RTS -V0 -tT1969.comp.stats --machine-readable -RTS max_bytes_used value is too high: Expected T1969(normal) max_bytes_used: 15017528 +/-15% Lower bound T1969(normal) max_bytes_used: 12764898 Upper bound T1969(normal) max_bytes_used: 17270158 Actual T1969(normal) max_bytes_used: 18071064 Deviation T1969(normal) max_bytes_used: 20.3 % *** unexpected stat test failure for T1969(normal) }}} One of these patches is the culprit, but I can't tell from the build logs because the build was broken between these two points: {{{ commit 6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 Author: Ömer Sinan Ağacan <omeragacan(a)gmail.com> Bump Haddock submodule commit 8d4760fb7b20682cb5e470b24801301cfbbdce3b Author: Simon Peyton Jones <simonpj(a)microsoft.com> Comments re ApThunks + small refactor in mkRhsClosure commit 9c54185b26922d88e516942aad946f05f707d7ce Author: Simon Peyton Jones <simonpj(a)microsoft.com> Comments + tiny refactor of isNullarySrcDataCon commit a09c0e3e68c96882a1fb392c9dbeea84056bf32f Author: Simon Peyton Jones <simonpj(a)microsoft.com> Comments only commit 714bebff44076061d0a719c4eda2cfd213b7ac3d Author: Ömer Sinan Ağacan <omeragacan(a)gmail.com> Implement unboxed sum primitive type }}} The patch immediately preceding this sequence does not have the failure: https://phabricator.haskell.org/rGHC83e4f49577665278fe08fbaafe2239553f3c448e (follow the link to the build) and the final patch in this sequence *does* have the failure: https://phabricator.haskell.org/rGHC6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 (along with an improvement in T9675) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10933: REMOVED pragma
by GHC 19 Mar '18

19 Mar '18

#10933: REMOVED pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Say I have a function that's been deprecated for some time. Then I remove it. Some clients will still use the now-missing function. It would be nice to give a helpful error message, instead of a "symbol not found" error. I thus propose a `REMOVED` pragma. The syntax is identical to `DEPRECATED`, except for the name of the pragma. Whenever a `REMOVED` function is mentioned, the error message includes the string from the pragma. (This includes trying to define a `REMOVED` class method in an instance.) See Design/DeprecationMechanisms for more info and related efforts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11092: ApiAnnotations : make annotation for shebang
by GHC 19 Mar '18

19 Mar '18

#11092: ApiAnnotations : make annotation for shebang -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently a valid haskell file can have a first line of the form {{{#!lhs #!/usr/bin/env runhaskell }}} This does not end up as anything that can have an API Annotation, and so gets lost on round tripping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10640: Document prim-ops
by GHC 19 Mar '18

19 Mar '18

#10640: Document prim-ops -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently documentation is quite scarce for many primops (particularly the BCO operations). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally
by GHC 19 Mar '18

19 Mar '18

#10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the constructor. On the other hand, messages of GHC and GHCi indicate that a data constructor operator in a prefix form is promoted by putting `'` before the constructor! (as in `forall (k :: BOX) (k :: BOX). (':*)` below.) I believe that this is a matter of parsing. The parser should admit `(':*)` as well as `'(:*)` for the naturalness of the syntax. In a GHCi: {{{#!hs > :set -XDataKinds -XTypeOperators > data a :* b = a :* b > :kind! Int :* Int Int :* Int :: * = Int :* Int > :kind! Int ':* Int Int ':* Int :: * :* * = Int ':* Int > :kind! (:*) (:*) :: * -> * -> * = (:*) > :kind! '(:*) '(:*) :: k -> k1 -> k :* k1 = forall (k :: BOX) (k :: BOX). (':*) > :kind! (':*) <interactive>:1:3: parse error on input ‘:*’ }}} (By the way I assume that Template Haskell quotes (`'function` and `''Type`) are parsed by the same mechanism as the one for the explicit promotion syntax. I hope both styles of quotes for prefix operators will be admitted because currently only the `'(` `''(` style is admitted.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10506: SourceNotes are not applied to all identifiers
by GHC 19 Mar '18

19 Mar '18

#10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling {{{ module Foo where foo x = x + 1 bar y = foo y }}} with `-g` produces {{{ $ ghc -g -ddump-ticked test.hs [1 of 1] Compiling Foo ( test.hs, test.o ) AbsBinds [a_avC] [$dNum_avD] {Exports: [foo <= foo_amB <>] Exported types: foo :: forall a_avC. Num a_avC => a_avC -> a_avC [LclId, Str=DmdType] Binds: -- ticks = [src<test.hs:3:1-13>] foo_amB x_alA = src<test.hs:3:9-13> (+) src<test.hs:3:9> x_alA src<test.hs:3:13> 1} AbsBinds [a_avV] [$dNum_avW] {Exports: [bar <= bar_avN <>] Exported types: bar :: forall a_avV. Num a_avV => a_avV -> a_avV [LclId, Str=DmdType] Binds: -- ticks = [src<test.hs:5:1-13>] bar_avN y_amz = src<test.hs:5:9-13> foo (src<test.hs:5:13> y_amz)} }}} Note that neither the occurrence of `(+)` in `foo`, nor the occurrence of `foo` in `bar` have their own Ticks. Instead they are only covered by the Tick for the entire application `x + 1` (resp. `foo y`). I'm trying to use the new SourceNote infrastructure to map CoreExprs back to their original source location, but unfortunately I need these locations for each identifier in the source. Would it be reasonable to add a SourceNote to each occurrence of an identifier? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic
by GHC 19 Mar '18

19 Mar '18

#10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently in `base` we have * `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and `srcLocModule` * `Data.Typeable.Internals`: the data type `TyCon` contains `tyConPackage`, `tyConModule` and `tyConName. * `GHC.Generics`: the data type `Datatype` contains `dataTypePackage`, `dataTypeModule` and `dataTypeName` * `Data.Data`: the data type `DataType` (yes the capitalisation differs!) contains a field `tycon :: String`, and there are functions `tyconModule :: String -> String`, and `tyconUQname :: String -> String`, for parsing that string and extracting the module name and tycon name. * `GHC.StaticPtr`: the data type `StaticPtrInfo` contains `spInfoPackageKey`, `spInfoModuleName`, `spInfoName` (all `String`s). Oh, and `spInfoSrcLoc :: (Int,Int)` too! This is madness! Five different representations for the same information in one package! Let's fix this by defining some shared data types, for * `Module` = `ModuleName` + package * `Entity` = `Module` + unqualified name There would be a tiresome changeover period; but `Typeable` and `StaticPtr` are in flux anyway. Would anyone be willing to lead on this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11382: Optimize Data.Char
by GHC 19 Mar '18

19 Mar '18

#11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 7.10.3 Libraries | 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: -------------------------------------+------------------------------------- Many of the predicates in `Data.Char` do full Unicode category lookups which turns out to be quite expensive. Ideally we would handle some of the more common ASCII characters with cheaper tests before falling back to the full Unicode treatment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11260: Re-compilation tests fail on powerpc64
by GHC 19 Mar '18

19 Mar '18

#11260: Re-compilation tests fail on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- recomp011: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed] Linking Main ... 4343 +Linking Main ... 4343 }}} recomp015: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Running main... +Linking Main ... Running main... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1
by GHC 19 Mar '18

19 Mar '18

#11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- `TH_spliceE5_prof` looks like this: {{{ TH_spliceE5_prof:: $(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --make -v0 TH_spliceE5_prof.hs -c '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) --make -v0 TH_spliceE5_prof.hs -prof -auto-all -osuf .p.o -o $@ ./$@ }}} In 4905b83a2d448c65ccced385343d4e8124548a3b, Simon added that `$(ghcThWayFlags)` to the first compilation command. With a release compiler, `ghcThWayFlags` defaults to `-dynamic`. But compiling with `-dynamic` doesn't produce `.dyn_o` files (you need `-dynamic-too` for that, which is enabled by `-XTemplateHaskell`, but **not** when compiling with `-dynamic`), so the second compilation results in: {{{ TH_spliceE5_prof.hs:8:17: fatal: cannot find object file ‘./TH_spliceE5_prof_Lib.dyn_o’ while linking an interpreted expression make[1]: *** [TH_spliceE5_prof] Error 1 *** unexpected failure for TH_spliceE5_prof(normal) }}} Not passing `-dynamic` fixes the test. But in the function `failNonStd` in `compiler/ghci/Linker.hs` Simon suggests that passing `-dynamic`: {{{ Cannot load -prof objects when GHC is built with -dynamic To fix this, either: (1) Use -fexternal-interprter, or (2) Build the program twice: once with -dynamic, and then with -prof using -osuf to set a different object file suffix. }}} Some ideas for a solution: * change that message to not mention `-dynamic` * always turn on `-dynamic-too` when `-XTemplateHaskell` is on, also when using `-dynamic` * find the place where `.dyn_o` is expected, and teach it that `.o` might also be ok. * make `-fexternal-interpreter` the default. Delete the test and a whole bunch of other stuff. It's all such a mess. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7