- ghc-tickets - Haskell.org

[GHC] #13215: Panic: push_bang_into_newtype_arg
by GHC 14 Feb '17

14 Feb '17

#13215: Panic: push_bang_into_newtype_arg -------------------------------------+------------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just for fun I tried to compile Agda using `-XStrict`. Result: {{{ [...] [235 of 324] Compiling Agda.Syntax.Translation.InternalToAbstract [...] ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for i386-unknown-linux): push_bang_into_newtype_arg {} }}} To reproduce (using GHC 8.0.2): {{{ git clone https://github.com/agda/agda.git cd agda git checkout f8a24fe9ed50e4287bc7308e2b3da4615db87aa8 cabal install --ghc-options=-XStrict --constraint=EdisonCore==1.3.1.1 --constraint=EdisonAPI==1.3.1 --constraint=base==4.9.1.0 --constraint=ghc- prim==0.5.0.0 --constraint=rts==1.0 --constraint=integer-gmp==1.0.0.1 --constraint=mtl==2.2.1 --constraint=transformers==0.5.2.0 --constraint=QuickCheck==2.9.2 --constraint=containers==0.5.7.1 --constraint=array==0.5.1.1 --constraint=deepseq==1.4.2.0 --constraint=random==1.1 --constraint=time==1.6.0.1 --constraint=template- haskell==2.11.1.0 --constraint=ghc-boot-th==8.0.2 --constraint=pretty==1.1.3.3 --constraint=tf-random==0.5 --constraint=primitive==0.6.1.0 --constraint=binary==0.8.3.0 --constraint=bytestring==0.10.8.1 --constraint=boxes==0.1.4 --constraint=split==0.2.3.1 --constraint=data-hash==0.2.0.1 --constraint=directory==1.3.0.0 --constraint=filepath==1.4.1.1 --constraint=unix==2.7.2.1 --constraint=edit-distance==0.2.2.1 --constraint=equivalence==0.3.1 --constraint=STMonadTrans==0.3.4 --constraint=transformers-compat==0.5.1.4 --constraint=geniplate- mirror==0.7.4 --constraint=gitrev==1.2.0 --constraint=process==1.4.3.0 --constraint=hashable==1.2.5.0 --constraint=text==1.2.2.1 --constraint=hashtables==1.2.1.0 --constraint=vector==0.11.0.0 --constraint=haskeline==0.7.3.0 --constraint=terminfo==0.4.0.2 --constraint=ieee754==0.7.9 --constraint=monadplus==1.4.2 --constraint =murmur-hash==0.1.0.9 --constraint=parallel==3.2.1.0 --constraint=regex- tdfa==1.2.2 --constraint=parsec==3.1.11 --constraint=regex-base==0.93.2 --constraint=strict==0.3.2 --constraint=unordered-containers==0.2.7.2 --constraint=xhtml==3000.2.1 --constraint=zlib==0.6.1.2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9562: Type families + hs-boot files = unsafeCoerce
by GHC 13 Feb '17

13 Feb '17

#9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider the following bundle of modules: A.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module A where type family F a b }}} B.hs-boot: {{{#!hs module B where import A oops :: F a b -> a -> b }}} B.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module B where import A import C type instance F a b = b oops :: F a b -> a -> b oops = const }}} C.hs: {{{#!hs module C (oops) where import {-# SOURCE #-} B }}} D.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module D where import A import C type instance F a b = a unsafeCoerce :: a -> b unsafeCoerce x = oops x x }}} Main.hs: {{{#!hs module Main where import D ( unsafeCoerce ) main = print $ (unsafeCoerce True :: Int) }}} When loading these into GHCi, we quite reasonably get a type family instance overlap error. But, separate compilation leads to disaster: {{{ rae:01:49:47 ~/temp/bug> ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 rae:01:49:49 ~/temp/bug> ghc -c A.hs rae:01:49:53 ~/temp/bug> ghc -c B.hs-boot rae:01:49:58 ~/temp/bug> ghc -c C.hs rae:01:50:09 ~/temp/bug> ghc -c B.hs rae:01:50:13 ~/temp/bug> ghc -c D.hs rae:01:50:17 ~/temp/bug> ghc Main.hs -o Unsafe [6 of 6] Compiling Main ( Main.hs, Main.o ) Linking Unsafe ... rae:01:50:23 ~/temp/bug> ./Unsafe 2882303761534249061 }}} Yikes! Proposed (terrible) solution: hs-boot files '''must''' list all type instance declarations in the corresponding modules. It may also be a good idea to require all normal instance declarations in the hs-boot file as well, because this same trick can be used to introduce incoherence (I think -- haven't tested). This bug persists even if `Main` declares that it is `Safe`. I've attached a tarball of the files for ease of testing. (Credit to Edward Yang and Geoff Mainland, whose discussion provoked the line of inquiry that led to this discovery.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 13 Feb '17

13 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:61 simonmar]: > make won't necessarily rebuild your libraries, due to GHC's recompilation avoidance. Oh I see... Thank you for the tip! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:62> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 13 Feb '17

13 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): > (I had stage=2 in build.mk. I removed it and typed make. Is it not sufficient to cause a full build?). make won't necessarily rebuild your libraries, due to GHC's recompilation avoidance. It knows about changes in the source code and the flags, but it doesn't know about changes in GHC itself. So when I'm making measurements like this, I always delete the library object files manually: ``` find libraries/*/dist-install | grep 'o$' | xargs rm ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:61> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 13 Feb '17

13 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): It seems like the above results were bogus because it used libraries compiled with the wrong compiler (I had `stage=2` in build.mk. I removed it and typed `make`. Is it not sufficient to cause a full build?). After a clean build, the allocation numbers look very good: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- compress2 +2.0% -0.9% 0.170 0.170 -3.7% fft2 +1.0% -0.2% 0.078 0.078 0.0% fluid +2.1% -0.4% 0.006 0.006 0.0% gamteb +0.4% -4.5% 0.032 0.032 0.0% gcd +0.7% -21.4% 0.046 0.046 0.0% infer -0.1% -1.2% 0.054 0.054 0.0% integer +1.0% -1.5% -15.0% -15.0% 0.0% mandel +1.0% -24.4% 0.051 0.051 0.0% rfib +1.0% -0.3% 0.012 0.012 0.0% solid +0.4% -6.6% 0.130 0.131 0.0% -------------------------------------------------------------------------------- Min -0.2% -24.4% -21.1% -21.3% -3.7% Max +2.1% +0.1% +39.3% +39.3% +17.3% Geometric Mean +0.2% -0.7% -4.9% -4.9% +0.1% }}} Should I worry about the increase in the code size? If not I'll clean up the branch and submit a Diff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13270: Make Core Lint faster
by GHC 13 Feb '17

13 Feb '17

#13270: Make Core Lint faster -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not using `-dcore-lint` makes the validate build 25% faster overall. See https://perf.haskell.org/ghc/#compare/639e702b6129f501c539b158b982ed8489e3d…. We should at least profile it and check for anything egregiously inefficient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13259: cross-endian GHC generates invalid .hi files
by GHC 13 Feb '17

13 Feb '17

#13259: cross-endian GHC generates invalid .hi files -------------------------------------+------------------------------------- Reporter: slyfox | Owner: 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: -------------------------------------+------------------------------------- I've reproduced the bug in the following setup: {{{ ./configure \ --enable-unregisterised \ --host=x86_64-pc-linux-gnu \ --target=m68k-unknown-linux-gnu }}} m68k is a 32-bit big-endian machine. {{{ $ LD_BIND_NOW=1 inplace/bin/ghc-stage2 --show-iface libraries/base/dist- install/build/System/IO.hi Magic: Wanted 129742, got 3472490752 magic number mismatch: old/corrupt interface file? (wanted 129742, got 3472490752) $ printf "%08X - %08X\n" 129742 3472490752 0001FACE - CEFA0100 }}} Reverting changeset:fbcef83a3aa130d976a201f2a21c5afc5a43d000 restores .hi loading and ghc-stage2. I'm still not sure what exactly breaks. WORDS_BIGENDIAN looks suspicious. I guess it breaks ghc-stage1 endianness understanding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] Trac email verification for user: SherrylGayman9
by GHC 13 Feb '17

13 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=3ZAICY_g> Username: SherrylGayman9 Verification Token: 3ZAICY_g -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Trac email verification for user: KellePurton2
by GHC 13 Feb '17

13 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=CWs7ydsz> Username: KellePurton2 Verification Token: CWs7ydsz -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13274: GHC library is accumulating exported symbols at a very rapid rate.
by GHC 12 Feb '17

12 Feb '17

#13274: GHC library is accumulating exported symbols at a very rapid rate. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #5987 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On `20160617` libHSghc had `49610` exported symbols. This was gotten by doing `nm -g $5 | sed -nr 's/^[a-z,A-Z,0-9]+\s([A-Z])\s(.+)$/\1 \2\n/p' | sed -r 's/^.+:.*$//g' | sed '/^\s*$/d' | sort | uniq -u` on all object files given to link `libHSghc`. After rebasing on newer commit `20161015` 4 months later it now has `124966` exported symbols. This is an explosive increase in symbol count of nearly 300%. On `20170208` this is now even higher `147927` which is another big increase. Unfortunately it's not easy for me to go back to the first build since my git has been pruned. But I do have the list for the latest jump. Should be investigated why. This rate will be problematic for #5987 as it means we'll keep adding DLLs. Currently with the current head it needs to split in 3 DLLs, and it's not far from a 4th. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1