- ghc-tickets - Haskell.org

[GHC] #8144: Interface hashes include time stamp of included .h file when CPP is used
by GHC 26 Jun '15

26 Jun '15

#8144: Interface hashes include time stamp of included .h file when CPP is used -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- See https://github.com/nh2/ghc-bug-time-dependent-interface-hashes for a fast test case. Having '''Test.hs''': {{{ {-# LANGUAGE CPP #-} module Test () where }}} and an empty '''cabal_macros.h''', {{{ touch cabal_macros.h ghc -c Test.hs -optP-include -optPcabal_macros.h }}} will generate you a different interface hash ''most of the time'' in '''ghc --show-iface Test.hi'''. It looks like the modification time of the .h file makes it into the interface hash, but only at second resolution, and you get ''compilation IS NOT required'' if you manage to run it twice per second. I think the interface hash should be independent from the time stamp of the header file. This bug can trigger unnecessary recompilation and makes compilations with identical inputs non-deterministic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 26 Jun '15

26 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by rwbarton): I agree with jpbernardy that generating an empty case on (or equivalently forcing) the first argument would be more correct than producing a new error. However, it seems that in this case the "blame" could be assigned to jpbernardy, who wrote the original report with `instance Eq D where (==) = undefined` :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10552: round on negative fractionals causes a segfault
by GHC 26 Jun '15

26 Jun '15

#10552: round on negative fractionals causes a segfault -----------------------------------+---------------------------------- Reporter: mmirman | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+---------------------------------- "round (-1.5)" causes a segfault. Causes a runtime crash as well as a ghci crash. OS X 10.6.8 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10559: the 'impossible' happened while building stack
by GHC 26 Jun '15

26 Jun '15

#10559: the 'impossible' happened while building stack -------------------------------------+------------------------------------- Reporter: barnaby | Owner: 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: | -------------------------------------+------------------------------------- I ran stack update; stack install stack:latest It errored out and told me to mail you .. .... stack-0.0.3: build Completed all 122 actions. -- While building package stack-0.0.3 using: /Users/test/.stack/programs/x86_64-osx/ghc-7.10.1/bin/runhaskell -package=Cabal-1.22.2.0 -clear-package-db -global-package-db -package- db=/Users/test/.stack/snapshots/x86_64-osx/nightly-2015-06-21/7.10.1/pkgdb/ /var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/stack14231/stack-0.0.3/Setup.hs --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.2.0/ build Process exited with code: ExitFailure 1 Logs have been written to: "/private/var/tmp/haskell/Moodler/Moodler /.stack-work/logs/stack-0.0.3.log" Configuring stack-0.0.3... Building stack-0.0.3... Preprocessing library stack-0.0.3... [ 1 of 53] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Set/Monad.o ) [ 2 of 53] Compiling Network.HTTP.Download.Verified ( src/Network/HTTP/Download/Verified.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Network/HTTP/Download/Verified.o ) [ 3 of 53] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/Log.o ) [ 4 of 53] Compiling Data.Attoparsec.Combinators ( src/Data/Attoparsec/Combinators.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Attoparsec/Combinators.o ) [ 5 of 53] Compiling Data.Maybe.Extra ( src/Data/Maybe/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Maybe/Extra.o ) [ 6 of 53] Compiling Stack.New ( src/Stack/New.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/New.o ) [ 7 of 53] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/PagerEditor.o ) [ 8 of 53] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/Read.o ) [ 9 of 53] Compiling System.Process.Run ( src/System/Process/Run.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/Run.o ) [10 of 53] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Paths_stack.o ) [11 of 53] Compiling Path.IO ( src/Path/IO.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Path/IO.o ) [12 of 53] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Path/Find.o ) [13 of 53] Compiling Data.Aeson.Extended ( src/Data/Aeson/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Aeson/Extended.o ) [14 of 53] Compiling Network.HTTP.Download ( src/Network/HTTP/Download.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Network/HTTP/Download.o ) [15 of 53] Compiling Stack.Types.PackageName ( src/Stack/Types/PackageName.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/PackageName.o ) [16 of 53] Compiling Stack.Types.Docker ( src/Stack/Types/Docker.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Docker.o ) [17 of 53] Compiling Stack.Types.FlagName ( src/Stack/Types/FlagName.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/FlagName.o ) [18 of 53] Compiling Stack.Types.Version ( src/Stack/Types/Version.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Version.o ) [19 of 53] Compiling Data.Binary.VersionTagged ( src/Data/Binary/VersionTagged.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Binary/VersionTagged.o ) [20 of 53] Compiling Stack.Types.PackageIdentifier ( src/Stack/Types/PackageIdentifier.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/PackageIdentifier.o ) [21 of 53] Compiling Stack.Types.GhcPkgId ( src/Stack/Types/GhcPkgId.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/GhcPkgId.o ) [22 of 53] Compiling Stack.Types.BuildPlan ( src/Stack/Types/BuildPlan.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/BuildPlan.o ) [23 of 53] Compiling Stack.Types.Config ( src/Stack/Types/Config.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Config.o ) src/Stack/Types/Config.hs:12:1: Warning: The import of ‘<*>, pure, <$>’ from module ‘Control.Applicative’ is redundant [24 of 53] Compiling Stack.Constants ( src/Stack/Constants.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Constants.o ) [25 of 53] Compiling Stack.Types ( src/Stack/Types.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types.o ) [26 of 53] Compiling Stack.Package ( src/Stack/Package.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Package.o ) [27 of 53] Compiling Stack.Exec ( src/Stack/Exec.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Exec.o ) [28 of 53] Compiling Stack.Build.Types ( src/Stack/Build/Types.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Build/Types.o ) [29 of 53] Compiling Stack.GhcPkg ( src/Stack/GhcPkg.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/GhcPkg.o ) [30 of 53] Compiling Stack.PackageDump ( src/Stack/PackageDump.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/PackageDump.o ) src/Stack/PackageDump.hs:316:22: Warning: In the use of ‘S.breakByte’ (imported from Data.ByteString): Deprecated: "It is an internal function and should never have been exported. Use 'break (== x)' instead. (There are rewrite rules that handle this special case of 'break'.)" [31 of 53] Compiling Stack.Path ( src/Stack/Path.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Path.o ) [32 of 53] Compiling Stack.Build.Cache ( src/Stack/Build/Cache.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Build/Cache.o ) [33 of 53] Compiling Control.Concurrent.Execute ( src/Control/Concurrent/Execute.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Control/Concurrent/Execute.o ) [34 of 53] Compiling Stack.Build.Doc ( src/Stack/Build/Doc.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Build/Doc.o ) [35 of 53] Compiling Stack.Upload ( src/Stack/Upload.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Upload.o ) src/Stack/Upload.hs:29:1: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() [36 of 53] Compiling Stack.Docker.GlobalDB ( src/Stack/Docker/GlobalDB.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Docker/GlobalDB.o ) [37 of 53] Compiling Stack.Types.Internal ( src/Stack/Types/Internal.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Internal.o ) [38 of 53] Compiling Stack.Types.StackT ( src/Stack/Types/StackT.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/StackT.o ) [39 of 53] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/PackageIndex.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/ghc27479_0/libghc27479_197.dylib, 5): Symbol not found: _stackzu7QSuU95iv0I3hQSByROmsn_SystemziProcessziLog_showProcessArgDebug_closure Referenced from: /var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/ghc27479_0/libghc27479_197.dylib Expected in: flat namespace in /var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/ghc27479_0/libghc27479_197.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X
by GHC 25 Jun '15

25 Jun '15

#10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- joelteon encountered this issue in a rather complicated program, and we worked out the cause over IRC. Suppose that ghci needs to sequentially load three modules A, B and C, where B refers to symbols from A and C refers to symbols from both A and B. (For example modules B, C and another module D all contain Template Haskell that refers to the previous module(s).) The object code linker currently works like this: - Link the module `A.o` into a dylib `ghc_1.dylib` - Link the module `B.o` against `ghc_1.dylib` into a new dylib `ghc_2.dylib` - Link the module `C.o` against `ghc_2.dylib` into a new dylib `ghc_3.dylib` As a result, `ghc_2.dylib` ends up with a NEEDED (or whatever it's called in Mach-O) entry for `ghc_1.dylib`, and `ghc_3.dylib` ends up with a NEEDED entry for `ghc_2.dylib`. However, this apparently does not satisfy the OS X `dlopen` implementation, which complains about a missing symbol `_A_foo` referenced by `ghc_3.dylib` and which is defined in `ghc_1.dylib`. Apparently the dynamic loader only checks the direct dependencies when trying to resolve undefined symbols. (The Linux dynamic loader seems to be perfectly happy to use an indirect dependency to resolve an undefined symbol. But I found out that the linker [https://sourceware.org/bugzilla/show_bug.cgi?id=10238 gold] has the same sort of behavior as the OS X dynamic loader. I don't know whether there is any standard here, but it seems that we cannot rely on the Linux dynamic loader's behavior.) Presumably the fix is to keep track of all the previous temporary dylibs (rather than just one in `last_temp_so`) and link against all of them when building a new temporary dylib. I'm slightly worried about quadratic behavior here, but I think it's unlikely to be an issue in practice. I have a reproducer at http://lpaste.net/808723564239781888 (which I'll add to the test suite next) and oherrala ran the test on an OS X system with the following results: {{{ =====> Last(ghci) 1167 of 4480 [0, 0, 0] cd ./ghci/scripts && HC="/Users/oherrala/gits/ghc/inplace/bin/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history " "/Users/oherrala/gits/ghc/inplace/bin/ghc-stage2" -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci- history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <Last.script > Last.run.stdout 2> Last.run.stderr Actual stderr output differs from expected: --- /dev/null 2015-04-18 17:23:26.000000000 +0300 +++ ./ghci/scripts/Last.run.stderr 2015-04-18 17:23:34.000000000 +0300 @@ -0,0 +1,9 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.11.20150418 for x86_64-apple-darwin): + Loading temp shared object failed: dlopen(/var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib, 5): Symbol not found: _LastA_a_closure + Referenced from: /var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib + Expected in: flat namespace + in /var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + Actual stdout output differs from expected: --- ./ghci/scripts/Last.stdout 2015-04-18 16:26:55.000000000 +0300 +++ ./ghci/scripts/Last.run.stdout 2015-04-18 17:23:34.000000000 +0300 @@ -1,3 +1,2 @@ 3 4 -7 *** unexpected failure for Last(ghci) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #7650: can't use combining characters in identifiers
by GHC 24 Jun '15

24 Jun '15

#7650: can't use combining characters in identifiers -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => unicode * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7650#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)?
by GHC 24 Jun '15

24 Jun '15

#7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari * differential: => Phab:D1012 Comment: Seems to work. Opened a Differential. We'll see how it looks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7450#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)?
by GHC 24 Jun '15

24 Jun '15

#7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Indeed most of the time spent in the specialiser is spent in `consDictBind`. With respect to `snocDictBinds`: I believe `final_binds` in `specBind` actually can be of length greater than one. Seems worthwhile to keep it. Otherwise it seems fairly clear. I just hacked up a quick attempt; we'll see if it validates. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7450#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #229: Integer overflow in array allocation
by GHC 24 Jun '15

24 Jun '15

#229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gershomb): * cc: gershomb (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/229#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)?
by GHC 23 Jun '15

23 Jun '15

#7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ben, good work. I think you said that the culprit is `consDictBind`. Here are some ideas: * `snocDictBinds is only ever called with a singleton argument. Nuke it in favour of `snocDictBind`. * The calls to `snocDictBind` in `specBind` have just called `flattenDictBinds` which stupidly throws away all the free varaible information cached in the `DictBind`. Better to keep it! To achieve that * `snocDictBind` should take a `DictBind` not a `CoreBind` * `flattenDictBinds` should return a `DictBind` not a `CoreBind`. This is the place we are discarding the free var info. Instead, keep it! Does that make sense? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7450#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0