September 2016 - ghc-tickets

Re: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch
by GHC 05 Sep '16

05 Sep '16

#4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.2 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Can someone provide a simple set of instructions for how to reproduce this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4820#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12555: bindist configure checks involving the compiler are broken
by GHC 05 Sep '16

05 Sep '16

#12555: bindist configure checks involving the compiler are broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- Commit 6554dc60304bbd4b2edb93be7e1658bff237e067 added this code to `distrib/configure.ac.in`: {{{ BinDistNeedsLibdw=@HaveLibdw@ if test "x$BinDistNeedsLibdw" = "xyes" ; then AC_CHECK_LIB(dw, dwfl_attach_state, [HaveLibdw=YES], [AC_MSG_ERROR([Binary distribution was built with libdw support but target system doesn't have supported libdw version (needs at least 0.158)])] )]; fi }}} It occurs before any other autoconf command involving the compiler. So apparently the expansion of `AC_CHECK_LIB` includes the code responsible for checking how to invoke the compiler, checking the object file suffix, etc. (Yes, this is a crazy way to do it.) Since the official bindist has `BinDistNeedsLibdw=NO`, none of that code ever actually runs. Later (in `FPTOOLS_SET_HASKELL_PLATFORM_VARS`) the configure script uses ` AC_COMPILE_IFELSE` to check for features of the compiler like non- executable stack support, but these checks are broken because autoconf never actually determined basic information about the compiler. So the 8.0.1 bindist produces binaries with executable stacks, which is a problem on some systems. It would be better anyways to move this `AC_CHECK_LIB` later in `distrib/configure.ac.in`, to after where we select flags to be used when invoking the compiler. There are also some other bugs in this code: there is an extra `];` and the correct value of `BinDistNeedsLibdw` is `YES` (not `yes`) so the code currently can never run anyways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures
by GHC 05 Sep '16

05 Sep '16

#12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the following program: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE FlexibleInstances #-} import Control.Monad.Reader newtype AppM a = AppM (ReaderT Int IO a) deriving (Functor, Applicative, Monad, MonadReader) }}} The `MonadReader` deriving declaration should be `MonadReader Int`. GHC produces the following error message: {{{ • Expecting one more argument to ‘MonadReader’ Expected kind ‘* -> Constraint’, but ‘MonadReader’ has kind ‘* -> (* -> *) -> Constraint’ • In the newtype declaration for ‘AppM’ }}} This error message is confusing to me. The kind of `MonadReader` is `* -> (* -> *) -> Constraint`, as the error message states, which makes sense. However, the error message states that it expects kind `* -> Constraint`, despite the fact that `MonadReader Int` is actually of kind `(* -> *) -> Constraint`. ,,(This description is adapted from [http://stackoverflow.com/q/39172590/465378 this Stack Overflow question].),, -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12497: Make runtime linker be able to find POSIX functions under their deprecated name.
by GHC 05 Sep '16

05 Sep '16

#12497: Make runtime linker be able to find POSIX functions under their deprecated name. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.2 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: newcomer | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With GHC 8.0.1 the new runtime linker stopped re-exporting posix symbols under their deprecated names and instead follows the names on MSDN. Unfortunately there seems to be far more libraries than expected using these deprecated names. (Rather, far more libraries using posix functions and it happening to work on Windows). These are all broken now, and while we're doing the right thing, for the sake of compatibility with mingw-w64's behavior and allowing all these packages to work then we should re-export these symbols. e.g. rexport `strdup` as a forward from `_strdup`. We don't have to actually re-export them. just forward them in `RtsSymbol.c`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12066: Symbol not found: _stg_ap_0_upd_info
by GHC 05 Sep '16

05 Sep '16

#12066: Symbol not found: _stg_ap_0_upd_info -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling project for which `double-conversion` is a dependency: {{{ [ 1 of 12] Compiling Models.TH ( src/Models/TH.hs, dist/build/Models/TH.o ) <command line>: can't load .so/.DLL for: /nix/store /m8whp07czawywfis99bfqpjmfy3vj1bf-double-conversion-2.0.1.0/lib/ghc-8.0.1 /double-conversion-2.0.1.0/libHSdouble-conversion-2.0.1.0 -CatAMVNq05S8lUOKX28ozh-ghc8.0.1.dylib (dlopen(/nix/store /m8whp07czawywfis99bfqpjmfy3vj1bf-double-conversion-2.0.1.0/lib/ghc-8.0.1 /double-conversion-2.0.1.0/libHSdouble-conversion-2.0.1.0 -CatAMVNq05S8lUOKX28ozh-ghc8.0.1.dylib, 5): Symbol not found: _stg_ap_0_upd_info Referenced from: /nix/store/m8whp07czawywfis99bfqpjmfy3vj1bf-double- conversion-2.0.1.0/lib/ghc-8.0.1/double-conversion-2.0.1.0/libHSdouble- conversion-2.0.1.0-CatAMVNq05S8lUOKX28ozh-ghc8.0.1.dylib Expected in: flat namespace in /nix/store/m8whp07czawywfis99bfqpjmfy3vj1bf-double- conversion-2.0.1.0/lib/ghc-8.0.1/double-conversion-2.0.1.0/libHSdouble- conversion-2.0.1.0-CatAMVNq05S8lUOKX28ozh-ghc8.0.1.dylib) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12216: GHC 8.0.1 panics when compiling JuicyPixels-repa 0.7.1
by GHC 05 Sep '16

05 Sep '16

#12216: GHC 8.0.1 panics when compiling JuicyPixels-repa 0.7.1 -------------------------------------+------------------------------------- Reporter: cgo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This just happened on macOS 10.11.5: Configuring JuicyPixels-repa-0.7.1.0... Building JuicyPixels-repa-0.7.1.0... Preprocessing library JuicyPixels-repa-0.7.1.0... [1 of 1] Compiling Codec.Picture.Repa ( Codec/Picture/Repa.hs, dist/dist- sandbox-94652cd7/build/Codec/Picture/Repa.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): filterImports/combine (Array, Array{Array, AByteString, ACursored, ADelayed, AForeignPtr, AInterleave, ASmall, APart, AUnboxed, AUndefined, AVector, cursoredExtent, loadCursor, makeCursor, shiftCursor}, Nothing) (Array, Source{Source, Array, deepSeqArray, extent, index, linearIndex, unsafeIndex, unsafeLinearIndex}, Nothing) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory '/var/folders/lj/5d92khf937120qgs9xccbn400000gn/T /cabal-tmp-24887/JuicyPixels-repa-0.7.1.0' Updating documentation index -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info'
by GHC 05 Sep '16

05 Sep '16

#12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info' -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | 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 basically the same thing as #11155 but triggered differently. {{{ -- M.hs {-# OPTIONS_GHC -O0 #-} module M(f) where import GHC.Exts {-# NOINLINE z #-} z = () f :: () -> () f _ = let x = lazy z in g x x {-# NOINLINE g #-} g :: () -> () -> () g _ _ = () -- MM.hs import M main = f `seq` return () }}} On GHC 8.0, I get: {{{ ezyang@sabre:~$ ghc-8.0 --make MM.hs -fforce-recomp [1 of 2] Compiling M ( M.hs, M.o ) [2 of 2] Compiling Main ( MM.hs, MM.o ) Linking MM ... ./M.o: In function `r2aD_info': (.text+0x4a): undefined reference to `stg_ap_0_upd_info' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) }}} Error goes away when you turn on optimization. My understanding is that removing `lazy` in `CorePrep` is too late, because there's no pass afterwards that eliminates the trivial thunk assignment. This is blocking Phab:D2211, where the insertion of a `noinline` (which is optimized out similarly to `lazy`) triggers a stage 2 linker failure when you don't compile with optimization (unfortunately, this is NOT caught validate since we build GHC with optimization... but with this test it will be!) Perhaps there should be an ASSERT in the codegen so it doesn't create this symbol? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12076> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12472: "lazy" is not optimized away
by GHC 05 Sep '16

05 Sep '16

#12472: "lazy" is not optimized away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Consider: {{{ import GHC.Magic {-# INLINE f #-} f x = True g = lazy f False }}} Two things should happen: (1) f should not be inlined, but (2) lazy should not be present in final STG (having been eliminated in core prep). I thought this was briefly working on HEAD, but apparently it never worked at all: {{{ ezyang@sabre:~$ ghc-8.0 -c test.hs -ddump-stg -fforce-recomp -O2 ==================== STG syntax: ==================== Test.f [InlPrag=INLINE (sat-args=1)] :: forall t_axB. t_axB -> GHC.Types.Bool [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <L,A>, Unf=OtherCon []] = \r srt:SRT:[] [eta_sHD] GHC.Types.True []; Test.g :: GHC.Types.Bool [GblId, Str=DmdType] = \u srt:SRT:[] [] GHC.Magic.lazy Test.f GHC.Types.False; }}} Clearly it has not been eliminated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12472> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler'
by GHC 05 Sep '16

05 Sep '16

#12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' -------------------------------------+------------------------------------- Reporter: DanielG | 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: -------------------------------------+------------------------------------- GHC used to export 'defaultCleanupHandler' going back as far as 7.4, starting with 8.0 no equivalent function seems to be exported. Please consider exporting 'withCleanupSession' as a replacement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 05 Sep '16

05 Sep '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott <ryan.gl.scott@…>): In [changeset:"34010dbe77ac405da6c671c3feb3573d0d025379/ghc" 34010db/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34010dbe77ac405da6c671c3feb3573d0d025379" Derive the Generic instance in perf/compiler/T5642 Summary: For some inexplicable reason, the `Generic` instance in `perf/compiler/T5642` is written out entirely by hand. This is not only strange, since Trac #5642 is about derived `Generic` instances, but it also annoying to maintain, since it requires manually changing a bunch of code whenever the algorithm behind `deriving Generic` changes. (See D2304 for a recent example of this.) It seems more sensible to just derive the `Generic` instance. It shifts the goalposts of what allocations we're measuring a bit, since we no longer have to parse a large amount of code (and as a knock-on effect, the allocations go down a bit). But I think this program is morally equivalent to what we were benchmarking before, so it's not too unreasonable to change. Test Plan: make test TEST=T5642 Reviewers: austin, thomie, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D2511 GHC Trac Issues: #5642 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0