February 2014 - ghc-tickets

[GHC] #8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion
by GHC 02 Jul '14

02 Jul '14

#8704: Use GHC.Exts.build in randoms, randomRs to achieve fusion ------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.6.3 Keywords: fusion | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4218 | ------------------------------------+------------------------------------- randoms, randomRs could take advantage of list fusion. A commit is attached for consideration. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8787: compiler/ghc.mk: restore GhcHcOpts variable handling
by GHC 02 Jul '14

02 Jul '14

#8787: compiler/ghc.mk: restore GhcHcOpts variable handling ------------------------------------+------------------------------------- Reporter: slyfox | 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: | ------------------------------------+------------------------------------- wiki and mk/config.mk.in suggests setting GhcHcOpts for compiler-wide haskell flags. But it does not work for a while now. Proposed patch fixes it. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2)
by GHC 01 Jul '14

01 Jul '14

#8425: ghc-7.6.3: crossmodule inline leads to buggy code (-O2) ----------------------------------+------------------------------------- Reporter: slyfox | 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: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- The bug is found as a crash of gf-3.4 ('Grammatical Framework') package compiled with -O2. With some debugging I've come to roughly following minimal example: This code compiles incorrectly: {{{ import BuggyOpt() -- bug inducer! import qualified Data.Map as Map import Data.Array.IArray {-# NOINLINE mkLin #-} mkLin :: Array Int (Array Int Int) -> Map.Map (Array Int Int) Int -> Int -> (Map.Map (Array Int Int) Int, Int) mkLin mseqs seqs seqid = let seq_ = mseqs ! seqid -- lookup/insert pair. exactly as in 'BuggyOpt' module in case Map.lookup seq_ seqs of Just seqid' -> (seqs,seqid') Nothing -> let seqid'' = Map.size seqs seqs' = Map.insert seq_ seqid'' seqs in (seqs',seqid'') }}} And this works fine: {{{ --import BuggyOpt() -- bug inducer! import qualified Data.Map as Map import Data.Array.IArray {-# NOINLINE mkLin #-} mkLin :: Array Int (Array Int Int) -> Map.Map (Array Int Int) Int -> Int -> (Map.Map (Array Int Int) Int, Int) mkLin mseqs seqs seqid = let seq_ = mseqs ! seqid -- lookup/insert pair. exactly as in 'BuggyOpt' module in case Map.lookup seq_ seqs of Just seqid' -> (seqs,seqid') Nothing -> let seqid'' = Map.size seqs seqs' = Map.insert seq_ seqid'' seqs in (seqs',seqid'') }}} Attached minimal test tarball and my results on it are: {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","x86_64-pc-linux-gnu-gcc") ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl ,--reduce-memory-overheads") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","/usr/bin/llc") ,("LLVM opt command","/usr/bin/opt") ,("Project version","7.6.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib64/ghc-7.6.3") ,("Global Package DB","/usr/lib64/ghc-7.6.3/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory- overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ] RUN good [1 of 2] Compiling Susp ( good/Susp.hs, good/Susp.o ) [2 of 2] Compiling Main ( good/main.hs, good/main.o ) Linking good/main ... (fromList [(array (0,0) [(0,42)],0)],0) RUN bad [1 of 3] Compiling BuggyOpt ( bad/BuggyOpt.hs, bad/BuggyOpt.o ) [2 of 3] Compiling Susp ( bad/Susp.hs, bad/Susp.o ) [3 of 3] Compiling Main ( bad/main.hs, bad/main.o ) Linking bad/main ... main: Error in array index; 0 not in range [0..0) TEST FAILED in bad }}} What we see here is the test with useless import mysteriously fails: > main: Error in array index; 0 not in range [0..0) while without import it works fine: > (fromList [(array (0,0) [(0,42)],0)],0) The functions in both BuggyOpt and Susp modules contain suspiciously similar code: {{{ case Map.lookup seq' seqs of Just id' -> (seqs,id') Nothing -> let last_seq = Map.size seqs in (Map.insert seq' last_seq seqs, last_seq) }}} But in BuggyOpt ghc somehow deduces some arguments and applies that effect to (unrelated, but looking similar) Susp module. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8293: user001 spuriously fails if getGroupEntryForID correctly fails
by GHC 27 Jun '14

27 Jun '14

#8293: user001 spuriously fails if getGroupEntryForID correctly fails --------------------------+------------------------------------------------ Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 7.7 libraries/unix | Operating System: Linux Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: user001 Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ In some cases, a user's current group ID can be a number for a non- existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc/groups is not to be considered reliable. Unfortunately, the user001 has no way of telling that the failure is proper, and fails the test anyway. We ought to do something more robust. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8146: Library package cannot be found
by GHC 20 Jun '14

20 Jun '14

#8146: Library package cannot be found --------------------------------+------------------------------------------ Reporter: conradwt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Installing GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ {{{ ./sync-all get warning: libffi-tarballs already present; omitting == libffi-tarballs: running git config --local core.ignorecase true warning: utils/hsc2hs already present; omitting == utils/hsc2hs: running git config --local core.ignorecase true warning: utils/haddock already present; omitting == utils/haddock: running git config --local core.ignorecase true == running git clone https://github.com/ghc/packages/array.git libraries/array Cloning into 'libraries/array'... fatal: repository 'https://github.com/ghc/packages/array.git/' not found git failed: 32768 at ./sync-all line 119. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tar ball }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8667: sync-all doesn't work properly if you run from a fork on github
by GHC 20 Jun '14

20 Jun '14

#8667: sync-all doesn't work properly if you run from a fork on github ------------------------------------+------------------------------------- Reporter: schyler | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: | ------------------------------------+------------------------------------- The intuitive behaviour when working with projects on github is to make your own fork so that you can use the online interface (or GitHub for {windows,osx} apps). One would assume that this behaviour was endorsed because of the ~130 forks to the ghc repo, however forking the repo actually causes ./sync-all to stop working (it asks for a username and password to whomever@ github.com) It seems the only way for a person to work with the project from github is to clone directly from the original repo. This sounds like a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8753: Import constructor but not the data type
by GHC 09 Jun '14

09 Jun '14

#8753: Import constructor but not the data type ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- How do I import a constructor but not its data type? The constructor might have the name of a data type which I do not want to bring into scope. Use case: Library (A) defines a parametrized data type (D a) which I want to use in my code (B) in instantiated form (D Int) but with the same name (D). I want to pattern match against inhabitants of type D, so I need the constructor(s) in scope. Here is how it could look like if import lists let me specify whether I want to import a type or a constructor with name "D". module A where data D a = D a module B where import A (constructor D) import qualified A D = A.D Int f :: D -> Int f (D x) = x Haskell has different name spaces for type and constructors, but does not let the user talk about these name spaces where it matters, namely in import/export lists. At least I found no documentation instructing me how to do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling)
by GHC 03 Jun '14

03 Jun '14

#8768: Internal compiler error on haskell-src-exts 1.14.01 (profiling) ----------------------------------+--------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I'm configuring and building {{{haskell-src-exts}}} like this: {{{ runhaskell Setup configure -O -p --enable-shared \ -fbase4 runhaskell Setup build }}} It builds the ordinary bits just fine, but when it gets to compiling for profiling: {{{ [ 1 of 22] Compiling Language.Haskell.Exts.Annotated.Syntax ( src/Language/Haskell/Exts/Annotated/Syntax.hs, dist/build/Language/Haskell/Exts/Annotated/Syntax.p_o ) /tmp/ghc340_0/ghc340_8.s:1:0: internal compiler error: Segmentation fault .section .rodata ^ Please submit a full bug report, with preprocessed source if appropriate. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8475: Library docs: broken links to Foreign.ForeignPtr
by GHC 03 Jun '14

03 Jun '14

#8475: Library docs: broken links to Foreign.ForeignPtr ------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Documentation | 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: | ------------------------------------+------------------------------------- In the library docs at `http://www.haskell.org/ghc/docs/latest/html/libraries/index.html`, the `Foreign.ForeignPtr` module in the contents is the one from `haskell2010`, not `base`. This causes various problems, it seems. For instance: * the link from `ForeignPtr` to `Foreign.ForeignPtr` is broken * the link from `Foreign.Concurrent` to `Foreign.ForeignPtr` is broken there are probably other broken links too. We need to figure out what to do about overlapping modules properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8781: check if GNU nm is realy needed and if so let configure detect gnm
by GHC 03 Jun '14

03 Jun '14

#8781: check if GNU nm is realy needed and if so let configure detect gnm ----------------------------------+---------------------------------------- Reporter: maeder | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.1-rc1 Component: Build System | Operating System: Solaris Keywords: | Type of failure: Building GHC failed Architecture: x86 | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- building ghc-7.8.20140130 under Solaris fails with a non-GNU nm as follows: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/opt/csw/bin/gcc" --gcc-flag -U__i686 --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc- flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/ccs/bin/nm" Can't find "STD_HDR_SIZE" gmake[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 43