March 2013 - ghc-tickets

[GHC] #7790: Add dummy undefined symbols to indicate ways
by GHC 13 Apr '13

13 Apr '13

#7790: Add dummy undefined symbols to indicate ways -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Component: Compiler Version: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Currently, "way" information is not recorded into object files; it is only recorded into 'hi' files. This means if you are using, say, rts/Linker.c (say, if you're GHCi or a dynamic plugins package), if you mess up and load an object file compiled the wrong way, you will be very sad. I think a cute trick we could play is to define a bunch of dummy symbols per-way, and add them as undefined symbols to objects, to indicate what way they were compiled, e.g. with the `-u` linker flag. Various RTS's export the symbols of ways they support, and attempting to link an object with an incompatible RTS results in a link error. Are there any problems with this scheme? If not, I'll go ahead and implement it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7789: GHCI core dumps when used with VTY
by GHC 13 Apr '13

13 Apr '13

#7789: GHCI core dumps when used with VTY -----------------------------+---------------------------------------------- Reporter: timthelion | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.4.2-rc1 | Keywords: core dump Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Load the attached script in ghci: {{{ $ghci ghci-coredumper.hs }}} (you need the vty-menu package from hackage) and type die {{{ >die }}} You may see a menu with a set of ten numbers. If you do press enter repeatedly. Eventually it will core dump(at least it does for me) Unfortunately I have been unable to collect this core dump, but here is the output at least: {{{ 7f7ad1fc4000-7f7ad1fc5000 rwxp 000fd000 00:10 2839271 /usr/lib/libm-2.17.so 7f7ad1fc5000-7f7ad2032000 r-xp 00000000 00:10 3028085 /usr/lib/libgmp.so.10.1.1 7f7ad2032000-7f7ad2231000 ---p 0006d000 00:10 3028085 /usr/lib/libgmp.so.10.1.1 7f7ad2231000-7f7ad2232000 r-xp 0006c000 00:10 3028085 /usr/lib/libgmp.so.10.1.1 7f7ad2232000-7f7ad223b000 rwxp 0006d000 00:10 3028085 /usr/lib/libgmp.so.10.1.1 7f7ad223b000-7f7ad2252000 r-xp 00000000 00:10 2839310 /usr/lib/libpthread-2.17.so 7f7ad2252000-7f7ad2451000 ---p 00017000 00:10 2839310 /usr/lib/libpthread-2.17.so 7f7ad2451000-7f7ad2452000 r-xp 00016000 00:10 2839310 /usr/lib/libpthread-2.17.so 7f7ad2452000-7f7ad2453000 rwxp 00017000 00:10 2839310 /usr/lib/libpthread-2.17.so 7f7ad2453000-7f7ad2457000 rwxp 00000000 00:00 0 7f7ad2457000-7f7ad245a000 r-xp 00000000 00:10 2839316 /usr/lib/libdl-2.17.so 7f7ad245a000-7f7ad2659000 ---p 00003000 00:10 2839316 /usr/lib/libdl-2.17.so 7f7ad2659000-7f7ad265a000 r-xp 00002000 00:10 2839316 /usr/lib/libdl-2.17.so 7f7ad265a000-7f7ad265b000 rwxp 00003000 00:10 2839316 /usr/lib/libdl-2.17.so 7f7ad265b000-7f7ad265d000 r-xp 00000000 00:10 2839280 /usr/lib/libutil-2.17.so 7f7ad265d000-7f7ad285c000 ---p 00002000 00:10 2839280 /usr/lib/libutil-2.17.so 7f7ad285c000-7f7ad285d000 r-xp 00001000 00:10 2839280 /usr/lib/libutil-2.17.so 7f7ad285d000-7f7ad285e000 rwxp 00002000 00:10 2839280 /usr/lib/libutil-2.17.so 7f7ad285e000-7f7ad2865000 r-xp 00000000 00:10 2839273 /usr/lib/librt-2.17.so 7f7ad2865000-7f7ad2a64000 ---p 00007000 00:10 2839273 /usr/lib/librt-2.17.so 7f7ad2a64000-7f7ad2a65000 r-xp 00006000 00:10 2839273 /usr/lib/librt-2.17.so 7f7ad2a65000-7f7ad2a66000 rwxp 00007000 00:10 2839273 /usr/lib/librt-2.17.so 7f7ad2a66000-7f7ad2ac0000 r-xp 00000000 00:10 3403181 /usr/lib/libncursesw.so.5.9 7f7ad2ac0000-7f7ad2cbf000 ---p 0005a000 00:10 3403181 /usr/lib/libncursesw.so.5.9 7f7ad2cbf000-7f7ad2cc3000 r-xp 00059000 00:10 3403181 /usr/lib/libncursesw.so.5.9 7f7ad2cc3000-7f7ad2cc5000 rwxp 0005d000 00:10 3403181 /usr/lib/libncursesw.so.5.9 7f7ad2cc5000-7f7ad2ce6000 r-xp 00000000 00:10 2839312 /usr/lib/ld-2.17.so 7f7ad2e39000-7f7ad2eba000 rwxp 00000000 00:00 0 7f7ad2ee4000-7f7ad2ee6000 rwxp 00000000 00:00 0 7f7ad2ee6000-7f7ad2ee7000 r-xp 00021000 00:10 2839312 /usr/lib/ld-2.17.so 7f7ad2ee7000-7f7ad2ee8000 rwxp 00022000 00:10 2839312 /usr/lib/ld-2.17.so 7f7ad2ee8000-7f7ad2ee9000 rwxp 00000000 00:00 0 7fff979b8000-7fff979d9000 rwxp 00000000 00:00 0 [stack] 7fff979fe000-7fff97a00000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Neúspěšně ukončen (SIGABRT) (core dumped [obraz paměti uložen]) }}} Sometimes it dumps immediately, sometimes it takes a while. Sometimes the errors are different: {{{ *** Exception: user error (Terminal does not define required capability "cup") *Main> }}} {{{ *** Exception: user error (Terminal does not define required capability "setab") *Main> <stdin>: hWaitForInput: end of file }}} But mostly it just core dumps. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7788: Recursive type family causes <<loop>>
by GHC 13 Apr '13

13 Apr '13

#7788: Recursive type family causes <<loop>> ----------------------------------------+----------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- This file: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} data Proxy a = Proxy foo :: Proxy (F (Fix Id)) -> () foo = undefined newtype Fix a = Fix (a (Fix a)) newtype Id a = Id a type family F a type instance F (Fix a) = F (a (Fix a)) type instance F (Id a) = F a main :: IO () main = print $ foo Proxy }}} Dies with `<<loop>>`. The type family is recursive, of course: {{{ *Main> :kind! F (Fix Id) F (Fix Id) :: *^CInterrupted. }}} But `<<loop>>` is still not the behavior I'd expect. The actual value is just `undefined`. In the file that this example came up, the situation was even worse -- there was a situation where {{{ moldMapOf l f = runAccessor . l (Accessor . f) main = print $ (flip appEndo [] . moldMapOf (ix 3) (Endo . (:)) $ testVal :: [Int]) -- <<loop>> main = print $ (flip appEndo [] . runAccessor . (ix 3) (Accessor . Endo . (:)) $ testVal :: [Int]) -- undefined }}} I.e. substitution can turn one program (which happens to be ⊥ here, admittedly, but that's not fundamental) into another (`<<loop>>`). This makes it very tricky to track down the recursive type family. If necessary I can hunt down a working test case and post it here -- it's a bit tricky to get working, though. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7785: Module-local function not specialized with ConstraintKinds
by GHC 13 Apr '13

13 Apr '13

#7785: Module-local function not specialized with ConstraintKinds ------------------------------------+--------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: specialisation Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- In the attached program, 'shared' is not exported and only used with f = [], but it doesn't get specialized in the core. On the other hand, shared', which does not involve !ConstraintKinds, gets correctly specialized. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7783: MultiWayIf should start a new layout
by GHC 13 Apr '13

13 Apr '13

#7783: MultiWayIf should start a new layout -----------------------------+---------------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #4359 -----------------------------+---------------------------------------------- Currently, MultiWayIf doesn't fully replace old {{{case () of _}}} form. This outputs 3: {{{ {-# LANGUAGE MultiWayIf #-} x = case () of _ | False -> case () of _ | False -> 1 | False -> 2 | True -> 3 main = print (x :: Int) }}} but this errors out: {{{ {-# LANGUAGE MultiWayIf #-} x = if | False -> if | False -> 1 | False -> 2 | True -> 3 main = print (x :: Int) }}} Every other syntax introducing guards starts a layout; MultiWayIf's current behavior leads to subtle logic bugs for those unaware that MultiWayIf is special. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7782: flag to run the demand analysis a second time
by GHC 13 Apr '13

13 Apr '13

#7782: flag to run the demand analysis a second time -----------------------------+---------------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 4941, 5302, 6087, 4962 -----------------------------+---------------------------------------------- There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others? Here's the effects on nofib. Run time didn't seem to change as drastically. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd/O2 late-dmd/late-dmd ------------------------------------------------------------------------------- cryptarithm2 25078168 +0.0% +8.0% nucleic2 98331744 +0.0% +3.2% cichelli 80310632 +0.0% -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +0.0% -2.6% k-nucleotide 4125102928 -0.0% -4.8% knights 2037984 +0.0% -3.7% mandel2 1041840 +0.0% -21.4% parstof 3103208 +0.0% -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -0.0% -1.0% }}} Note that it improves a couple tests significantly just via changes in the base libraries. For cryptarithm2, see my comments on #4941. This might indicate that #4962 should be re-opened. For nucleic2, in var_most_distant_atom, an inlined let grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue. The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7775: Mark intentionally omitted type class instances
by GHC 13 Apr '13

13 Apr '13

#7775: Mark intentionally omitted type class instances -----------------------------+---------------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.2 | Keywords: instance warning Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- In GHCi I get {{{ Prelude> 2+3::Char <interactive>:2:2: No instance for (Num Char) arising from a use of `+' Possible fix: add an instance declaration for (Num Char) In the expression: 2 + 3 :: Char In an equation for `it': it = 2 + 3 :: Char }}} In many cases users now actually try to implement the instance Num Char, but this is certainly not a good idea. I would like to tell the user whenever an instance is intentionally unimplemented and why it is missing. Like so {{{ {-# NOINSTANCE Num Char where "There is no sound arithmetic on characters." #-} }}} The syntax after NOINSTANCE should be like in an instance declaration. It shall be treated like a type class instance, e.g. it shall be checked whether the same instance already exists, or whether it is orphan, or whether it is not Haskell 98, and it should require to enable according extensions like MultiParamTypeClasses. If on resolution a non-instance is chosen then the compiler should print the custom warning "There is no sound arithmetic on characters." instead of "probable fix: add instance". -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7774: T5313 fails
by GHC 13 Apr '13

13 Apr '13

#7774: T5313 fails ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ T5313 fails {{{ =====> T5313(normal) 76 of 104 [0, 0, 0] cd . && '/home/ian/ghc/git/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T5313 T5313.hs -package ghc >T5313.comp.stderr 2>&1 cd . && ./T5313 "/home/ian/ghc/git/ghc/inplace/lib" </dev/null >T5313.run.stdout 2>T5313.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: T5313: <command line>: can't load .so/.DLL for: /home/ian/ghc/git/ghc/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.3.1.0-ghc7.7.20130316.so (/home/ian/ghc/git/ghc/libraries/ghc-prim /dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130316.so: undefined symbol: stg_newByteArrayzh) *** unexpected failure for T5313(normal) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7771: RTS should provide stg_sel_n_noupd_closure
by GHC 13 Apr '13

13 Apr '13

#7771: RTS should provide stg_sel_n_noupd_closure ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ In `StgStdThunks.cmm` we define info tables `stg_sel_1_upd_info`, etc, for "selector thunks", thus: {{{ #define SELECTOR_CODE_UPD(offset) \ INFO_TABLE_SELECTOR(stg_sel_##offset##_upd, offset, THUNK_SELECTOR, "stg_sel_upd", "stg_sel_upd") \ (P_ node) \ ...etc... }}} But we should ALSO define info tables for ''non-updatable'' selector thunks, thus `stg_sel_1_nonupd_info` etc. We didn't generate any such selectors before, but now I'm implementing cardinality analysis, we are. Would it be possible to beef up this macro to to generate both info tables? Simply omit the update for the `nonupd` version. (It wasn't quite obvious to me how to do this.) That would allow me to get rid of this hack in `CLabel` {{{ pprCLbl (RtsLabel (RtsSelectorInfoTable _upd_reqd offset)) = hcat [ptext (sLit "stg_sel_"), text (show offset), ptext (sLit "_upd_info") -- RTS only has updatable selector thunks at the moment -- so we use just them -- ptext (if upd_reqd -- then (sLit "_upd_info") -- else (sLit "_noupd_info")) ] }}} Thanks -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7768: "untracked content" in fresh clone of haskeline
by GHC 13 Apr '13

13 Apr '13

#7768: "untracked content" in fresh clone of haskeline -------------------------+-------------------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- This sequence of events happened today: {{{ ~> git clone http://darcs.haskell.org/ghc.git; cd ghc; ./sync-all --testsuite get ... ~/ghc> git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: libraries/haskeline (untracked content) # no changes added to commit (use "git add" and/or "git commit -a") ~/ghc> cd libraries/haskeline ~/ghc/libraries/haskeline> git status # Not currently on any branch. # Untracked files: # (use "git add <file>..." to include in what will be committed) # # "tests/dummy-I\314\202\302\274I\314\202\302\261I\314\210\302\203/" nothing added to commit but untracked files present (use "git add" to track) }}} It seems harmless, but I can't seem to make the problem go away. I'm on a Mac. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2