July 2018 - ghc-tickets

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

03 Jul '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): Oh dear. It turns out my bash script that I used to automatically build the required GHC's and run nofib had a bug that caused it to silently ignore mistyped build flavours, so instead of "GHC compiled with -fno- state-hack", I got "GHC compiled with the default flavour". Which explains the whopping difference: where I thought I was comparing "GHC compiled with -prof -fno-state-hack vs. GHC compiled with -prof", I was actually comparing "GHC release build vs. GHC prof build". Fortunately, the nofib flags were correct, so the part about the effect of `-fno-state-hack` on the nofib suite remains valid. I'll re-run the tests for "GHC compiled with -fno-state-hack", and I'll also throw in "Boot libraries compiled with -fno-state-hack, GHC compiled normally". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

03 Jul '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 "module-size-comparison" added. Comparing module sizes in a GHC build tree -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

03 Jul '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): Replying to [comment:44 simonpj]: > * 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. I did some more analyzing, and unfortunately the answer is "it's complicated". I compared module sizes for every .o in the GHC build tree between the two versions, and I'm getting mixed results. Some modules get significantly smaller when disabling the state hack, on the order of 10-50%, with some outliers as high as 70%. On the other end of the spectrum, there are lots of modules that blow up by several megabytes per module, percentages typically somewhere between 25% and 80%. There is also a large number of modules where the difference is small or zero. The differences aren't isolated in libraries; in all 3 categories, modules are mostly from `/libraries`, `/bootstrapping`, and `/compiler`. So it's definitely not just the libraries that blow up; it seems that GHC actually produces larger modules, but not always. I have not managed to find a pattern to the increase yet. So here's the 30 modules with the biggest shrinkage: {{{ diff diff% hack no hack file -598704 -4% 14142232 13543528 compiler/stage2/build/HsInstances.o -232504 -36% 637000 404496 bootstrapping/Distribution/Simple/Utils.o -222928 -34% 638856 415928 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Utils.o -179816 -17% 1020496 840680 libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription/Check.o -177744 -17% 1015896 838152 bootstrapping/Distribution/PackageDescription/Check.o -144352 -24% 595592 451240 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Haddock.o -142432 -14% 968752 826320 bootstrapping/Distribution/Simple/Configure.o -137632 -14% 973336 835704 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Configure.o -136384 -23% 583088 446704 bootstrapping/Distribution/Simple/Haddock.o -131840 -13% 952160 820320 bootstrapping/Distribution/Simple/GHC.o -125008 -13% 955352 830344 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/GHC.o -117728 -27% 422008 304280 bootstrapping/Distribution/Simple/Build.o -116264 -27% 424320 308056 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Build.o -108816 -18% 579808 470992 bootstrapping/Distribution/Simple/GHCJS.o -103808 -11% 884696 780888 utils/ghc-pkg/dist/build/Main.o -103280 -17% 581736 478456 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/GHCJS.o -98288 -18% 532488 434200 utils/genprimopcode/dist/build/Main.o -92480 -16% 570120 477640 bootstrapping/Distribution/Simple.o -85024 -14% 573280 488256 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple.o -83632 -19% 433448 349816 utils/hsc2hs/dist/build/CrossCodegen.o -82520 -29% 281280 198760 bootstrapping/Distribution/Simple/SrcDist.o -81808 -28% 282832 201024 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/SrcDist.o -78920 -55% 141696 62776 bootstrapping/Data/Text/Internal/Lazy/Encoding/Fusion.o -77768 -43% 180664 102896 bootstrapping/Data/Text/Encoding.o -72824 -71% 102400 29576 bootstrapping/Data/Text/Internal.o -69456 -49% 140888 71432 bootstrapping/System/FilePath/Posix.o -66136 -39% 168512 102376 bootstrapping/Distribution/PackageDescription/Quirks.o -61280 -15% 392096 330816 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/PreProcess.o -59848 -35% 167816 107968 libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription/Quirks.o -58456 -15% 385944 327488 bootstrapping/Distribution/Simple/PreProcess.o }}} And the 30 worst offenders: {{{ diff diff% hack no hack file 242872 +42% 330888 573760 libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription/Parsec.o 252096 +18% 1130080 1382176 libraries/Cabal/Cabal/dist- boot/build/Language/Haskell/Extension.o 276872 +9% 2649696 2926568 libraries/containers/dist- install/build/Data/Sequence/Internal.o 282112 +50% 280448 562560 compiler/stage2/build/TcBackpack.o 286208 +21% 1039800 1326008 bootstrapping/Language/Haskell/Extension.o 293664 +43% 387048 680712 bootstrapping/Distribution/Types/GenericPackageDescription.o 295776 +42% 400880 696656 libraries/Cabal/Cabal/dist- boot/build/Distribution/Types/GenericPackageDescription.o 308792 +40% 462576 771368 libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Ppr.o 320800 +28% 786912 1107712 compiler/stage2/build/PPC/CodeGen.o 326400 +38% 520592 846992 libraries/text/dist- install/build/Data/Text/Lazy/Builder/RealFloat.o 350016 +32% 719512 1069528 compiler/stage2/build/PlatformConstants.o 410272 +2% 14146704 14556976 libraries/base/dist- install/build/HSbase-4.12.0.0.o 413960 +35% 748952 1162912 libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Haddock.o 430824 +27% 1157400 1588224 compiler/stage2/build/X86/CodeGen.o 450928 +29% 1078688 1529616 compiler/stage2/build/TcRnDriver.o 530216 +100% 0 530216 libraries/xhtml/dist- install/build/HSxhtml-3000.2.2.o 563744 +77% 166952 730696 bootstrapping/Distribution/Types/InstalledPackageInfo/FieldGrammar.o 581784 +77% 170552 752336 libraries/Cabal/Cabal/dist- boot/build/Distribution/Types/InstalledPackageInfo/FieldGrammar.o 583760 +44% 731800 1315560 libraries/ghci/dist- boot/build/GHCi/Message.o 593424 +12% 4286120 4879544 libraries/containers/dist- install/build/HScontainers-0.5.11.0.o 614096 +16% 3213320 3827416 libraries/text/dist- install/build/HStext-1.2.3.0.o 747024 +41% 1063368 1810392 libraries/ghci/dist- boot/build/GHCi/TH/Binary.o 952864 +27% 2503640 3456504 libraries/Cabal/Cabal/dist- boot/build/Distribution/SPDX/LicenseId.o 992784 +29% 2330808 3323592 bootstrapping/Distribution/SPDX/LicenseId.o 1004432 +43% 1328968 2333400 libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/GHC.o 1032072 +72% 382160 1414232 bootstrapping/Distribution/PackageDescription/FieldGrammar.o 1035032 +72% 392264 1427296 libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription/FieldGrammar.o 1212056 +29% 2905776 4117832 libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Syntax.o 2236208 +62% 1317096 3553304 libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Configure.o 4569096 +10% 38406248 42975344 libraries/Cabal/Cabal/dist- install/build/HSCabal-2.3.0.0.o }}} I'll attach the full comparison log. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 03 Jul '18

03 Jul '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): The bug as originally reported (`Invalid object in processHeapClosureForDead(): 60`) can't happen with modern GHCs as we handle closure 60 already, but the bug in comment:16 is fixed in Phab:D4928. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 03 Jul '18

03 Jul '18

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D4567 => Phab:D4928 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1262: RecursiveDo in Template Haskell
by GHC 02 Jul '18

02 Jul '18

#1262: RecursiveDo in Template Haskell -------------------------------------+------------------------------------- Reporter: philip.weaver@… | Owner: mgsloan Type: feature request | Status: patch Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/TH_recursiveDo Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1979 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1262#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10391: Ability to get contents of TH reified module
by GHC 02 Jul '18

02 Jul '18

#10391: Ability to get contents of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After using reifyModule, I'd like to be able to inspect the list of exports from that module. At first I thought that this could perhaps be done by changing from {{{#!hs data ModuleInfo = -- | Contains the import list of the module. ModuleInfo [Module] }}} to {{{#!hs data ModuleInfo = -- | Contains the import list and export list of the module. ModuleInfo [Module] [Name] }}} but I now wonder if this is the best plan, because `thisModule >>= reifyModule` might be expected to function as a time machine, allowing us to see declarations that may not have been made yet (in the case where this module's export list is implicit). Can anyone propose a type that would allow us to perform this inspection for modules that have already been baked, but not for "this" module? An intended use case would be in our dimensional types library. We have several modules that define a whole bunch of units. It's useful for the unit name parser to have access to a dictionary with all of those units in it, but maintaining the definition of such a dictionary is redundant. If this feature existed, a module in the parser could import the modules where units are defined, examine the export lists, reify the names in the export lists, determine which represent unit definitions, and emit a declaration of a dictionary that contains them all. (This is in some ways similar to #9699, though perhaps more difficult?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15302: TTG for IPBind wrong extension name
by GHC 02 Jul '18

02 Jul '18

#15302: TTG for IPBind wrong extension name -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: ttg | 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 standard[1] for extension naming is to use the `XC` prefix for the internal extension points, rather than for a new constructor. This is violated for `IPBind`, having {{{#!hs data IPBind id = IPBind (XIPBind id) (Either (Located HsIPName) (IdP id)) (LHsExpr id) | XCIPBind (XXIPBind id) }}} Swap the usage of `XIPBind` and `XCIPBind` [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow#Namingconve… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15327: Optimize remainders by powers of two for Integer and Natural
by GHC 02 Jul '18

02 Jul '18

#15327: Optimize remainders by powers of two for Integer and Natural -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14437 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that GHC does not optimise `even (n :: Integer)` to a bitwise check, as it does for `Int` and `Word` (#14437). Here is a benchmark: {{{#!hs import Data.Time.Clock evenRem :: Integer -> Bool evenRem n = fromIntegral n `rem` 2 == (0 :: Word) lim :: Integer lim = 100000000 main :: IO () main = do t0 <- getCurrentTime print $ maximum $ filter even [1..lim] t1 <- getCurrentTime putStrLn "even" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ filter evenRem [1..lim] t1 <- getCurrentTime putStrLn "evenRem" print $ diffUTCTime t1 t0 }}} {{{ $ ghc -O2 Even.hs [1 of 1] Compiling Main ( Even.hs, Even.o ) Linking Even ... $ ./Even 100000000 even 6.367393s 100000000 evenRem 4.35664s }}} The reason is that `even (n :: Integer)` results in `remInteger` call in CMM, which remains unoptimized. One possible solution is to add a special case of divisor 2 to `GHC.Integer.Type.remInteger`. Or perhaps even something like {{{#!hs remInteger n (S# d#) | isPowerOfTwo (I# d#) = fromIntegral (fromIntegral n `rem` I# d#) isPowerOfTwo :: Int -> Bool isPowerOfTwo d = d /= 0 && d .&. (complement d + 1) == d }}} Since `remInteger` is not inlined during Core pipeline, such implementation of `even` will pattern-match in runtime, which is a bit suboptimal. On my machine it benchmarks halfway between `even` and `evenRem` above. Alternative approach is to add new rules to `PrelRules.builtinIntegerRules` to avoid any possible runtime slowdown. Is is appropriate? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14529: Refactor ConDecl
by GHC 02 Jul '18

02 Jul '18

#14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 `ConDeclGADT` constructor in `ConDecl` is awful; all the information is buried. Refactor it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13