February 2014 - ghc-tickets

[GHC] #8336: Sinking pass does not
by GHC 19 Nov '14

19 Nov '14

#8336: Sinking pass does not ------------------------------+-------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Compiling this program: {{{ {-# LANGUAGE BangPatterns, MagicHash, CPP #-} {-# OPTIONS_GHC -O2 -funbox-strict-fields #-} module HashStr where import Foreign.C import GHC.Exts import Data.Word #define hASH_TBL_SIZE 4091 hashStr :: Ptr Word8 -> Int -> Int -- use the Addr to produce a hash value between 0 & m (inclusive) hashStr (Ptr a#) (I# len#) = loop 0# 0# where loop h n | n GHC.Exts.==# len# = I# h | otherwise = loop h2 (n GHC.Exts.+# 1#) where !c = ord# (indexCharOffAddr# a# n) !h2 = (c GHC.Exts.+# (h GHC.Exts.*# 128#)) `remInt#` hASH_TBL_SIZE# }}} produces following Cmm code for `hashStr` function: {{{ {offset cut: goto cux; cux: _stC::I64 = R3; _stB::I64 = R2; _stF::I64 = 0; _stE::I64 = 0; goto stD; stD: if (_stF::I64 == _stC::I64) goto cuH; else goto cuI; cuH: R1 = _stE::I64; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cuI: _stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091); _stF::I64 = _stF::I64 + 1; _stE::I64 = _stM::I64; goto stD; } }}} The problem here is that three last assignments: {{{ _stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091); _stF::I64 = _stF::I64 + 1; _stE::I64 = _stM::I64; }}} could be optimized as: {{{ _stE::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091); _stF::I64 = _stF::I64 + 1; }}} We should improve sinking pass so that it can optimize such cases. See Note [dependent assignments] in CmmSink. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8372: enable -dcmm-lint by default for .cmm input files
by GHC 18 Nov '14

18 Nov '14

#8372: enable -dcmm-lint by default for .cmm input files ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm finding it's quite easy to write `.cmm` files with subtle errors that cause ghc to emit code that wasn't what I wanted! For example, I wrote a comparison between two arguments of different integer sizes and the code generator picked the wrong size. After tracking down the bug, I tried `-dcmm-lint` and it caught my error right away. It makes sense not to have `-dcmm-lint` enabled by default for Cmm produced from Stg, but I've seen here on the GHC wiki that `-dcmm-lint` is advised for hand-written `.cmm` files. But `integer-gmp`, and probably many other packages, don't build `.cmm` files with `-dcmm-lint`. Is there a reason we can't/shouldn't just make it the default? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8388: forall on non-* types
by GHC 18 Nov '14

18 Nov '14

#8388: forall on non-* types ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This code {{{ {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} x = Nothing :: (forall a. Maybe) Int }}} gives {{{ Couldn't match type `Maybe' with `forall a. Maybe' Expected type: forall a. Maybe Int Actual type: Maybe Int }}} which does not seem correct. There are two options: Option A: We allow this. Option B: We reject this as ill-kinded and allow `forall a. T` only when `T` has kind `*`. I prefer this option; in theory this can break existing code, but I am not aware of any code that uses forall on non-* type (please correct me if I'm wrong), and e.g. this means `forall a. a` inhabits every kind, for example `Bool`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld
by GHC 18 Nov '14

18 Nov '14

#8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld ----------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8294 | ----------------------------+--------------------------------- Much like #8294. Here is the error messages from the debug output: {{{ /usr/bin/ld: dynamic variable `base_GHCziBase_zdfMonadIO_closure' is zero size /usr/bin/ld: dynamic variable `ghczmprim_GHCziTuple_Z0T_closure' is zero size /usr/bin/ld: dynamic variable `base_GHCziTopHandler_runMainIO_closure' is zero size /usr/bin/ld: C.o(.text+0x59): unresolvable R_386_32 relocation against symbol `base_GHCziBase_zdfMonadIO_closure' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8398: reify module list in TH
by GHC 18 Nov '14

18 Nov '14

#8398: reify module list in TH -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: #8337 | Test Case: | Blocking: 7867 -------------------------------------------+------------------------------- This patch is for the use-case detailed in #7867. The added Q monad method provides the ability to get a list of module names in a format that is compatible with the module annotation reification in #8337. The patch contains a helper method that depends on #8337, so that should be applied first. If this is problematic, it's easy to separate this patch into one that doesn't depend on #8337 and an other that does. Then we can add the latter later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8401: parsec issues
by GHC 18 Nov '14

18 Nov '14

#8401: parsec issues ----------------------------------+--------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Built ghc-7.7 using BuildFlavour quick under Fedora 18 Linux and I encounter a problem after installing parsec and trying to load example ch16/csv9.hs from RealWorldHaskell: Could not find module 'Text.ParserCombinators.Parsec' Perhaps you haven't installed the "dyn" libraries for package parsec-3.1.3 There are also Warnings while installing parsec: Data/Text/Lazy/Builder/Int.hs:52:11: Warning: Rule "decimal/Int" may never fire because ‛decimal’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‛decimal’ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8401> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8404: Default to turning on architecture specific optimizations in the codegen
by GHC 18 Nov '14

18 Nov '14

#8404: Default to turning on architecture specific optimizations in the codegen ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- LLVM defaults to turning on whatever architecture specific optimizations are supported on the user's machine (e.g. `-msse4.2`). This makes programs run faster during testing and generally gives users a better perception of the compiler. If the user wants to compile for some more portable subset (e.g. when cross-compiling) he/she adds `-march`, `-mcpu`, etc flags on the command line. To implement this we'd have to detect what CPU type is used etc and initialize our `DynFlags` based on that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8415: GHC bug using darcs on Kubuntu 13.04
by GHC 18 Nov '14

18 Nov '14

#8415: GHC bug using darcs on Kubuntu 13.04 ----------------------------------+------------------------------------- Reporter: JoeAquilina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I was trying to push a darcs patch when it failed with a GHC error. This is the text of the error message on the console: darcs: internal error: evacuate: strange closure type 536064 (GHC version 7.6.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) Not sure if this is exactly what is required when reporting a bug, I am very new to this and am unsure of the procedures involved regarding GHC bug reporting. Thanks in advance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8419: add rawSystem variant that takes an environment
by GHC 18 Nov '14

18 Nov '14

#8419: add rawSystem variant that takes an environment -------------------------------------+------------------------------------- Reporter: dagit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- rawSystem properly handles the case of ^C while waiting. Instead of requiring people to recreate this behavior when using runProcess, it would be good if we add and export a rawSystemWithEnv or directly export syncProcess. See for example: https://github.com/haskell/cabal/issues/1448 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8419> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8420: Spurious dynamic library dependencies
by GHC 18 Nov '14

18 Nov '14

#8420: Spurious dynamic library dependencies ------------------------------------+--------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- It should be possible to have an executable A that depends on dynamic library B which in turn depends on dynamic library C, without A directly depending on C. {{{ A --> B --> C }}} Unfortunately, GHC 7.6.3 does not seem to allow this. Instead it copies the dependencies of B to dependencies of A, so that we get {{{ A -> B,C and B --> C }}} This is unfortunately, because running A will cause the loader to locate C based on the rpaths (assuming we are using rpaths to locate dynamic libraries), whereas only B should know how to get to C from B. The problem seems to be that ghc copies all the library dependencies of B (presumably from the package specification of B) as library dependencies of the A. I verified the problem in GHC 7.6.3, but haven't tried in HEAD yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4