- ghc-tickets - Haskell.org

[GHC] #8436: Stack overflow when masked should still throw at interruptible operations or inner unmask
by GHC 11 Oct '13

11 Oct '13

#8436: Stack overflow when masked should still throw at interruptible operations or inner unmask -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Currently, to deal with #767, stack overflow exceptions are never emitted when exceptions are masked; e.g. if the thread unmasks and it is back under the stack limit, it will be as if the thread never stack-overflowed. However, it seems that we can be a bit more proactive about throwing the exception, in a way similar to asynchronous exceptions, wherein we add the stack overflow to the blocked exceptions list and let it be thrown at an interruptible point or if the exceptions get unmasked. Patch would be pretty simple, I'd like to check if people think this is a better idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3722: Haskeline Iconv needs HAVE_LANGINFO_H
by GHC 10 Oct '13

10 Oct '13

#3722: Haskeline Iconv needs HAVE_LANGINFO_H ----------------------------------------+------------------------------ Reporter: donn | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: libraries (other) | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Operating System: Other | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+------------------------------ Changes (by judahj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: This has been fixed in haskeline, which tests for HAVE_LIBCHARSET before HAVE_LANGINFO_H: https://github.com/ghc/packages- base/commit/b56d2e60a1141e9fc23d795b5b7222921670a285 If that does not resolve the issue for you, please let us know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3722#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7774: T5313 fails
by GHC 10 Oct '13

10 Oct '13

#7774: T5313 fails -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by gmainland): Yes it is, but the error is slightly different: {{{ =====> T5313(normal) 2009 of 3799 [0, 0, 0] cd ./driver && '/home/mainland/ghc/ghc-working-build/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 ./driver && ./T5313 "/home/mainland/ghc/ghc-working-build/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/mainland/ghc/ghc- working-build/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.3.1.0-ghc7.7.20131010.so (/home/mainland/ghc/ghc-working- build/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.3.1.0-ghc7.7.20131010.so: undefined symbol: stg_forkOnzh) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7774#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8434: dynflag dependency addition in TcRnDriver is not needed anymore
by GHC 10 Oct '13

10 Oct '13

#8434: dynflag dependency addition in TcRnDriver is not needed anymore -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: task | 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: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- The removed parts of the tcRnImports function in the attached patch says that there is a check in LoadIface.loadInterface and this is why it's needed to add the plugin dependencies to the EPS. But actually [[GhcFile(compiler/iface/LoadIface.lhs#L227)]] says that the check is no longer there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8432: clarify throwTo documentation
by GHC 10 Oct '13

10 Oct '13

#8432: clarify throwTo documentation -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- As discussed in the thread http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23889 the documentation of {{{GHC.Conc.throwTo}}} is not 100% clear on the provided atomicity guarantees. In http://article.gmane.org/gmane.comp.lang.haskell.libraries/20218 I proposed a patch for said documentation but it seems to have slipped through the cracks. Can somebody please have a look and - hopefully - apply it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8421: ghc build failure with template haskell on ghc head
by GHC 10 Oct '13

10 Oct '13

#8421: ghc build failure with template haskell on ghc head ----------------------------------+---------------------------------------- Reporter: schell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- It seems that it failed while building template haskell with this output: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-7.7.20131008 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP- DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.3.1 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.1 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/typecheck/TcSplice.lhs -o compiler/stage2/build/TcSplice.o -dyno compiler/stage2/build/TcSplice.dyn_o compiler/typecheck/TcSplice.lhs:1068:3: ‛qAddTopDecls’ is not a (visible) method of class ‛TH.Quasi’ compiler/typecheck/TcSplice.lhs:1099:3: ‛qAddModFinalizer’ is not a (visible) method of class ‛TH.Quasi’ compiler/typecheck/TcSplice.lhs:1103:3: ‛qGetQ’ is not a (visible) method of class ‛TH.Quasi’ compiler/typecheck/TcSplice.lhs:1109:3: ‛qPutQ’ is not a (visible) method of class ‛TH.Quasi’ make[1]: *** [compiler/stage2/build/TcSplice.o] Error 1 make: *** [all] Error 2 }}} Here is my gcc -v: {{{ schell@localhost:~/C/ghc:master$ gcc -v Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable- checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program- prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with- slibdir=/usr/lib --build=i686-apple-darwin11 --enable- llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst- llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx- include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) }}} I'm on Mac OS X 10.8.5. Before fast forwarding to HEAD I was encountering #8276 though I don't know if this build got further or less far :(. I'm attaching what I hope is the ghc fingerprint I got using ./utils/fingerprint/fingerprint.py create -o fingerprint.log... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8431: ghci freezes in multiline when passed a closing paren
by GHC 10 Oct '13

10 Oct '13

#8431: ghci freezes in multiline when passed a closing paren -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- {{{ Prelude> :set +m Prelude> ) }}} Never returns. Patch attached. John's code was buggy and reachable, apparently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8430: Literate haskell accepts spurious \end{code} lines
by GHC 10 Oct '13

10 Oct '13

#8430: Literate haskell accepts spurious \end{code} lines -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Easy (less than 1 | invalid program hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- In #8428 klao removed a spurious \end{code} from `TypeRep.lhs`. This made it clear that GHC has accepts spurious \end{code} lines in literate haskell code. This patch fixes the literate haskell preprocessor to issue an error in this case. Interestingly though, after this change nothing breaks except for klao's already merged patch, so this issue was not found in other .lhs files through GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8428: Incorrect type formatting in error messages
by GHC 10 Oct '13

10 Oct '13

#8428: Incorrect type formatting in error messages ------------------------------------+------------------------------------- Reporter: klao | 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: | ------------------------------------+------------------------------------- I've been trying to write a type signature to something completely analogous to `runST . runIdentityT`, and failing miserably for a long time. At some point I had the following: {{{#!haskell {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImpredicativeTypes #-} module Test where import Control.Monad.ST import Control.Monad.Trans.Identity runIdST :: IdentityT (forall s. ST s) a -> a runIdST = runST . runIdentityT }}} You can see that I was very confused about `forall` here (probably still am), but what makes it much worse is the error message with which this fails: {{{ src/Test.hs:10:19: Couldn't match type `forall s. ST s a' with `forall s. ST s a' Expected type: IdentityT (forall s. ST s) a -> forall s. ST s a Actual type: IdentityT (forall s. ST s) a -> forall s. ST s a In the second argument of `(.)', namely `runIdentityT' In the expression: runST . runIdentityT In an equation for `runIdST': runIdST = runST . runIdentityT }}} It says it couldn't match `forall s. ST s a` with `forall s. ST s a`. What's up with that?! This has lead me to a long diversion. Finally, we found the right type for this function (and discovered that the problem is also in the `(.)`, which doesn't have the same special treatment as `($)`), and afterwards we realized, that types in the above error message ''are'' actually different. One is `(forall s. (ST s)) a`, and the other is `forall s. ((ST s) a)`. But they are presented in exactly the same way! The issue is in the `instance Outputable Type`, which has too simplistic precedence rules, I guess. Thanks to `@errge` for help with debugging this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file
by GHC 09 Oct '13

09 Oct '13

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file --------------------------+------------------------------------------------ Reporter: errge | Owner: Type: | Status: patch feature request | Milestone: 7.8.1 Priority: | Version: 7.6.3 normal | Keywords: Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: 3725, 8337, 8340, 8397, 8398 Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Comment (by errge): The wiki page is ready. http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations All comments are welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7867#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0