- ghc-devs - Haskell.org

Re: Pattern match failure in StgCmmExpr.hs when adding new out-of-line primop
by Edsko de Vries 12 Nov '13

12 Nov '13

Hi Arash, On Tue, Nov 12, 2013 at 10:44 AM, Arash Rouhani <rarash(a)student.chalmers.se> wrote: > I'm really curious why you want a "catchRethrow". I'm tempted to add such > a primop myself since I'm working on problems with stack traces. I'm really > interested in what use-case you had in mind. > I'm working on dealing with problems with re-throwing asynchronous exceptions, especially in the context of using unsafePerformIO (see #8006 and the other tickets I reference there at the top). The catchRethrow I'm playing with is supposed to be used something like threadCode :: IO () threadCode = catch (print notReallyPure) outerHandler where outerHandler :: SomeException -> IO () outerHandler e = logMsg $ "Outer handler: " ++ show e notReallyPure :: Integer notReallyPure = unsafePerformIO $ catchRethrow (go 10) innerHandler where go :: Integer -> IO Integer go 0 = return 1234 go n = do logMsg (show n) threadDelay 100000 go (n - 1) innerHandler :: SomeException -> IO Integer -> IO Integer innerHandler e rethrow = do logMsg $ "Inner handler: " ++ show e rethrow logMsg :: String -> IO () logMsg str = do tid <- myThreadId putStrLn $ show tid ++ ": " ++ str Given this main: main :: IO () main = do a1 <- async threadCode a2 <- async threadCode threadDelay 500000 cancel a1 wait a2 return () It should be the case that when thread a1 gets interrupted, thread a2 can continue evaluating the notReallyPure thunk without getting either an exception and without redoing any work. In other words, the output of this main should look like ThreadId 2: 10 ThreadId 2: 9 ThreadId 2: 8 ThreadId 2: 7 ThreadId 2: 6 ThreadId 2: Inner handler: thread killed ThreadId 2: Outer handler: thread killed ThreadId 3: 5 ThreadId 3: 4 ThreadId 3: 3 ThreadId 3: 2 ThreadId 3: 1 1234 -E

1 0

Windows build
by Simon Peyton-Jones 12 Nov '13

12 Nov '13

Austin, or others, It would be SO GREAT if it was possible to validate on Windows again. Currently I'm using msys2, which builds GHC fine, but things fail badly in the testsuite. Traceback (most recent call last): File "../driver/runtests.py", line 144, in <module> raise Exception("Can't detect Windows terminal type") Exception: Can't detect Windows terminal type uname -s returns MINGW_NT-6.2 Changing the test from elif v.startswith("MINGW32"): to elif v.startswith("MINGW"): just produces a new error Traceback (most recent call last): File "../driver/runtests.py", line 155, in <module> mydll = ctypes.windll AttributeError: 'module' object has no attribute 'windll' ../mk/test.mk:242: recipe for target 'test' failed It's all very frustrating because I can't validate. Can anyone help? Simon

2 3

Things stopping pure Haskell code from having a cross-platform single semantics?
by Ryan Newton 12 Nov '13

12 Nov '13

Haskell isn't like Java byte code in having a single semantics for a program irrespective of where it is run. In particular, "Int" has a platform-defined width -- so the same (pure) code can yield different answers on different machines. numCapabilities was also a "leak" of platform information, which did not require IO. But, happily, now it does not appear in the [Trustworthy] module, Control.Concurrent. Ok, what else? What other holes are there that allow my pure functions to change their answer on different machines? I'm making a list of these in a paper and I want to make sure I give a full account. Thanks, -Ryan

2 1

Annotations
by Simon Peyton-Jones 08 Nov '13

08 Nov '13

I've just noticed that there is no GHC language extension for annotations http://www.haskell.org/ghc/docs/latest/html/users_guide/extending-ghc.html#… That feels like an oversight. Yes, they are in a pragma, but you may get an error message if you compile with a stage-1 compiler, for example. Plus, the language extensions should truthfully report what extra stuff you are using. I'm inclined to add a language extension "Annotations". * Without it {-# ANN ... #-} pragmas are ignored as comments * With it, they are treated as annotations Do you agree? I don't know whether this can (or even should) land in 7.8.1. Do you care either way? Guidance welcome Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

5 7

simd branch ready for review/merge
by Geoffrey Mainland 08 Nov '13

08 Nov '13

The SIMD branch, available as wip/simd, is ready for review/merge. It could use some review---Simon and Simon, I'd be especially grateful if you both had a quick look. Some major points: 1) I have added support for AVX 512, although this is necessarily untested. AVX and AVX2 are also both supported. 2) After the recent churn regarding patching LLVM's GHC calling convention, by default only 128-bit wide SIMD vectors are passed in registers, and then only on X86_64. There is a "hidden" flag, -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that assumes all vectors are passed in registers by LLVM. This can be used with a suitably patched version of LLVM, and if we get LLVM 3.4 patched, we can consider turning it on by default for LLVM 3.4+. This would mean that we couldn't mix LLVM <3.3-compiled object files with LLVM >3.4-compiled object files, but I don't see that as much of a problem. 3) utils/genprimcode has been hacked up to allow us to write vector operations once and have them instantiated at multiple vector types. I'm not thrilled with this solution, but after discussing with Simon PJ, what I've implemented seems to be the minimal reasonable solution to the problem of exploding primop boilerplate. The changes are documented in compiler/prelude/primops.txt.pp. 4) Error handling is sub-optimal. My patch checks to make sure that vector primops can be compiled efficiently based on the current set of dynamic flags. For example, if -mavx is not specified and the user tries to use a primop that adds together two 256-bit wide vectors of double-precision elements, the user will see an error message like: ghc-stage2: sorry! (unimplemented feature or known bug) (GHC version 7.7.20130916 for x86_64-unknown-linux): 256-bit wide floating point SIMD vector instructions require at least -mavx. This is because the only good place to check for this kind of error is during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we don't have much of an error handling infrastructure there in contrast to when we're working in the typechecking/renaming monad. If there is a better way/place to do this, please let me know. Thanks, Geoff

4 8

Possible bug related to stm and exceptions
by Andreas Voellmy 07 Nov '13

07 Nov '13

Hi all, I have a program that uses STM heavily and also performs lots of foreign calls. I've noticed that sometimes the program uses 100% CPU indefinitely and uses lots of memory - I see it go up to about 5GB before I kill it. I've grabbed some preliminary samples of stack traces and see lots stm related stuff (e.g. lots of stg_atomically_frame_info and stmCommitTransaction entries). I can pretty reliably get the behavior to happen now by closing a socket that my Haskell program is trying to recv from. When this causes an exception to be raised (something like "recv: resource vanished (Connection reset by peer)") , then this behavior gets triggered. I haven't pinned down the bug yet, but I'm suspecting it is STM related - somehow the exception causes some STM transaction to go wrong. Are there any known bugs that sound similar to this? BTW, this is with GHC 7.6.3 from a recent HP release on OS X. -Andi

4 6

windows agiain
by Simon Peyton-Jones 07 Nov '13

07 Nov '13

Austin I'm crashing in the testsuite as below. On Windows with the new msys. Any ideas? How do I set my "Windows terminal type"? Simon python2 ../../../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=0 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../config/ghc -e 'config.confdir="../../../config"' -e 'config.compiler="C:/code/HEAD/inplace/bin/ghc-stage1.exe"' -e 'config.ghc_pkg="C:/code/HEAD/inplace/bin/ghc-pkg.exe"' -e 'config.hp2ps="C:/code/HEAD/inplace/bin/hp2ps.exe"' -e 'config.hpc="C:/code/HEAD/inplace/bin/hpc.exe"' -e 'config.gs="gs"' -e 'config.platform="i386-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="i386"' -e 'config.wordsize="32"' -e 'default_testopts.cleanup=""' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../../../timeout/install-inplace/bin/timeout.exe"' -e 'config.exeext=".exe"' -e 'config.top="C:/code/HEAD/testsuite"' \ --only=T8037 \ \ \ \ \ \ Traceback (most recent call last): File "../../../driver/runtests.py", line 144, in <module> raise Exception("Can't detect Windows terminal type") Exception: Can't detect Windows terminal type ../../../mk/test.mk:242: recipe for target 'test' failed make: *** [test] Error 1 should_compile $

1 0

Windows linking
by Simon Peyton-Jones 07 Nov '13

07 Nov '13

Austin Ok with the new msys2 I get the too-many-symbols thing below. This didn't happen before. Maybe I can switch off dynamic linking? How? Simon Too many symbols in DLL compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll [5263] ghczm7zi7zi20131107_Var_zdfUniquableVar_closure [5264] ghczm7zi7zi20131107_Var_zdfUniquableVar_info [5265] ghczm7zi7zi20131107_Var_zdwsetVarUnique_closure [5266] ghczm7zi7zi20131107_Var_zdwsetVarUnique_info [5267] ghczm7zi7zi20131107_Var_zdwupdateTyVarKindM_closure [5268] ghczm7zi7zi20131107_Var_zdwupdateTyVarKindM_info [5269] ghczm7zi7zi20131107_Var_zdwzdcgmapMp_closure [5270] ghczm7zi7zi20131107_Var_zdwzdcgmapMp_info [5271] setHeapSize compiler/ghc.mk:472: recipe for target 'compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll' failed make[1]: *** [compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll] Error 1 make[1]: *** Deleting file 'compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll' Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 HEAD $

1 0

GHC error message on type mismatch
by Daniel Trstenjak 07 Nov '13

07 Nov '13

Hello, I don't know if I'm the only one struggeling with this GHC error message on type mismatches or it's because I'm not a full time Haskeller, or because I'm not a native english speaker. Couldn't match type `A' with `B´ Expected type: B Actual type: A My problem is with 'Expected' and 'Actual', that I'm often unsure if the compiler is "expecting" something or if I'm the expecting one and the same goes for "actual". I know that the compiler is the expecting one and that I'm given the actual thing, but it's quite often that I'm looking at this error and have to repeat this reasoning. It's strange, because normaly I can memorize such things quite good, but this one bothers me. Perhaps it would be easier for myself if 'Actual type' would be called e.g. 'Given type', I don't know, that just one of the two has a less generic meaning. Greetings, Daniel

1 0

Another CPP gotcha for the manual
by Mark Lentczner 07 Nov '13

07 Nov '13

Turns out that c pre-processing removes C style (/*…*/) comments. Of course, it will do this anywhere in the source. The following program can tell if it is compiled *-cpp* or not: module Main where (*/**) :: Double -> Double -> Double (*/**) a b = a / (2 ** b) howCompiled = if use > 1/16 then "normal" else "-cpp" where use = 1 */** 2 + 3 */** 4 main = putStrLn $ "compiled " ++ howCompiled When run: & runhaskell CppTest.hs compiled normal & runhaskell -cpp CppTest.hs compiled -cpp An example in the wild is in the package *wai-extra*, in the file *Network/Wai/Middleware/RequestLogger.hs* where the */* construct appears twice in the comments. Short of defining and implementing our own CPP-like preprocessing (something we might actually consider), I don't think there really is any fix for this, so the bug is that it should appear in the GHC documentation on CPP mode (§4.12.3), along with similar warnings about trailing back-slashes. Note that the way in which a multi-line comment is removed differs between *gcc* and *clang*. In *gcc*, the comment is removed and content of the line before the comment, and contents of the line after the comment are joined into a single line. In *clang*, the two line fragments are kept on separate lines. In both cases extra empty lines are added to keep the line count the same. The consequence of the *gcc* / *clang* difference is that neither the above code, nor wai-extra will compile with *clang*. Note: As far as I can tell this is not a *clang* bug, but a failure of specs: The C definition of comments and their removal is vague, and my guess is *gcc* choose its method based on historical use. The C++ definition makes it clear that comments are whitespace, even once removed, and so the *clang* method is correct. - Mark

7 10