- ghc-tickets - Haskell.org

Re: [GHC] #3458: Allocation where none should happen
by GHC 06 Jan '14

06 Jan '14

#3458: Allocation where none should happen ---------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+---------------------------------- Comment (by nomeata): Just for the record: The code {{{ #!haskell f x = let g y = if y then x else g y in case g x of True -> False False -> True }}} in comment:5 would also be improved by the common context transformation proposed here: http://www.haskell.org/pipermail/ghc- devs/2013-December/003481.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3458#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#)
by GHC 04 Jan '14

04 Jan '14

#8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) ------------------------------+-------------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.8.1 Priority: normal | Version: 7.7 Component: libraries | Operating System: Unknown/Multiple (other) | Type of failure: Runtime performance bug Keywords: integer- | Test Case: gmp | Blocking: Architecture: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- In the course of a recent [discussion on reddit](http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_with_in… it was highlighted, that `integer-gmp` doesn't try to demote `J#` to the more efficient `S#` if even though they would fit. The attached proof-of-concept patch introduces a "smart" `J#` constructor which constructs a `S#` instead if possible: {{{ #!hs -- | Demote 'J#' to 'S#' if possible. See also 'smartJ#'. toSmall :: Integer -> Integer toSmall i@(S# _) = i toSmall (J# 0# _) = S# 0# toSmall (J# 1# mb#) | isTrue# (v ># 0#) = S# v where v = indexIntArray# mb# 0# toSmall (J# -1# mb#) | isTrue# (v <# 0#) = S# v where v = negateInt# (indexIntArray# mb# 0#) toSmall i = i -- | Smart 'J#' constructor which tries to construct 'S#' if possible smartJ# :: Int# -> ByteArray# -> Integer smartJ# s# mb# = toSmall (J# s# mb#) }}} And replaces a couple of `J#`-constructions which are likely to produce a `S#`-fitting `Integer`. A `nofib` comparison for vanilla GHC HEAD vs patched GHC HEAD is attached for further discussion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #5361: regSpill: out of spill slots!
by GHC 04 Jan '14

04 Jan '14

#5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: regSpill panic Operating System: Linux | impossible Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: http://hackage.haskell.org/package/SHA| Related Tickets: Blocking: | -------------------------------------+------------------------------------- Comment (by monoidal): This is a workaround, but does it mean the ticket is fixed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5361#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8
by GHC 04 Jan '14

04 Jan '14

#7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 --------------------------------------+--------------------------------- Reporter: chak | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.5 Resolution: | Keywords: Mountain Lion Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------------- Changes (by George): * status: new => infoneeded Comment: issue with integer-gmp on Mavericks with Xcode 5 is ticket 8497, https://ghc.haskell.org/trac/ghc/ticket/8497, so this ticket is specifically for what the subject says: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 which brings us back to my earlier question above: is this a problem with the 64 bit versions of ghc 7.4.2 on 10.8? with either the 32 bit or 64 bit version of ghc 7.6.3 on 10.8? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7011#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8
by GHC 04 Jan '14

04 Jan '14

#7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 --------------------------------------+--------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.5 Resolution: | Keywords: Mountain Lion Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------------- Comment (by George): yes I did: $ gcc --version gcc-4.8 (GCC) 4.8.2 I'm basically following the instructions here: http://d.hatena.ne.jp/kazu- yamamoto/20131028/1382921924 When I use integer-simple instead it fails with "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist- install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP- DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.0 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O -fasm -no-user-package-db -rtsopts -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist- install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist- install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o Loading package ghc-prim ... linking ... done. Loading package integer-simple ... linking ... done. Loading package base ... <command line>: can't load .so/.DLL for: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/libiconv.dylib (dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/libiconv.dylib, 9): no suitable image found. Did find: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/libiconv.dylib: mach-o, but wrong filetype) make[1]: *** [libraries/vector/dist- install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1 make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7011#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5361: regSpill: out of spill slots!
by GHC 04 Jan '14

04 Jan '14

#5361: regSpill: out of spill slots! -------------------------------------+------------------------------------- Reporter: markwright | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: regSpill panic Operating System: Linux | impossible Type of failure: Compile-time | Architecture: x86_64 (amd64) crash | Difficulty: Unknown Test Case: | Blocked By: http://hackage.haskell.org/package/SHA| Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * status: new => closed * resolution: => fixed Comment: SimonM said in http://www.haskell.org/pipermail/ghc- devs/2014-January/003611.html {{{ So, avoiding -fregs-graph should work around this with 7.8. }}} I verified that this is true. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5361#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8643: Silent name shadowing
by GHC 03 Jan '14

03 Jan '14

#8643: Silent name shadowing ------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5288 | ------------------------------------+------------------------------------- I have code like: {{{ let baseTex = (getTexPropNode nodes . NC.properties . NC.av $ geometry) >>= baseTex >>= (flip Map.lookup texs) . NC.tdSource }}} which gives me error: {{{ Games/secunda/Graph.hs:224:23: Couldn't match expected type `TexProperty -> Maybe a0' with actual type `Maybe b0' In the second argument of `(>>=)', namely `baseTex' In the first argument of `(>>=)', namely `(getTexPropNode nodes . NC.properties . NC.av $ geometry) >>= baseTex' In the expression: (getTexPropNode nodes . NC.properties . NC.av $ geometry) >>= baseTex >>= (flip Map.lookup texs) . NC.tdSource }}} However if I try to get type of expressin on the right hand side of {{{let baseTex = ...}}} in ghci then I get no error. Problem is that I am importing module with function {{{baseTex :: TexProperty -> Maybe TexDesc}}} and that function is shadowed by {{{let}}} expression which should have type of {{{Maybe Texture}}}. I tried to use {{{ghc-options: -Wall -fwarn-name-shadowing}}} in Cabal with no effect. From above error I conclude, that I made a type error. So I try to get type of expression in ghci which results in correct type - that makes my confusion. While I am trying to concentrate on type error, I am missing that I shadowed function by variable. This is not for the first time I've done same mistake. I would appreciate to get warnings about name shadowing since they makes me belief that I am using names of different type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8
by GHC 03 Jan '14

03 Jan '14

#7011: 32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8 --------------------------------------+--------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries (other) | Version: 7.5 Resolution: | Keywords: Mountain Lion Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+--------------------------------- Comment (by carter): did you try making sure the gcc in your path points to a real gcc too? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7011#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci
by GHC 03 Jan '14

03 Jan '14

#5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci -------------------------------+------------------------------------------- Reporter: dmwit | Owner: bennofs Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: As far as I know, there's no easy to way to test Ctrl-C with current infrastructure, so I left it without a test. Thanks for the patch! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5209#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci
by GHC 03 Jan '14

03 Jan '14

#5209: ^C doesn't correctly reset the prompt from within multiline commands in ghci -------------------------------+------------------------------------------- Reporter: dmwit | Owner: bennofs Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by Krzysztof Gogolewski <krz.gogolewski@…>): In [changeset:"4d70840db82065bf19767a5f7231a9b1a3f56e38/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4d70840db82065bf19767a5f7231a9b1a3f56e38" Fix #5209: Reset GHCi prompt in multiline mode GHCi didn't reset the multiline prompt when an exception (in particular, the UserInterrupt exception) occured. This commit uses `finally` to reset the prompt in all cases. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5209#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0