May 2011 - Glasgow-haskell-users

16 May '11

If only 1% of an imported module is used, GHC will link in the entire module. Are there any plans, or at least some ideas, to rectify this? One severe example of this is qtHaskell, where importing the top-level module causes glacial compile (actually link) times and huge executables. Strip can fix the executable size (why does GHC not do this automatically?), but linking remains a problem.

5 9

testsuite results
by Daniel Fischer 16 May '11

16 May '11

Running the testsuite with today's HEAD (perf build, but without profiling to keep time bearable) resulted in: ==================== OVERALL SUMMARY for test run started at Do 12. Mai 13:34:13 CEST 2011 2765 total tests, which gave rise to 9300 test cases, of which 0 caused framework failures 1587 were skipped 7467 expected passes 229 expected failures 9 unexpected passes 8 unexpected failures ==================== Pretty cool, I can't remember having so few unexpected failures before. ==================== Unexpected failures: T5084(normal) That's the compiler not complaining about an INLINE-pragma on a class method without default implementation. Patch is in ghc-generics branch, not yet in master, according to #5084. Anyway it's nothing serious (was a feature request, not a bug). dph-diophantine-opt(normal,threaded1,threaded2) These are due to a missing Show instance for [:Int:], a library issue. dph-words-opt(normal) Fails with "dph-words-opt: libraries/vector/Data/Vector/Generic.hs:369 (slice): invalid slice (1,2,2)". No idea whether that's a library or a compiler issue. hpc_markup_multi_001(normal) hpc_markup_multi_002(normal) hpc_markup_multi_003(normal) Those are due to hpc looking in the wrong directory for the tix files, patch exists, but is not yet in the master branch, according to #5069. So, of the eight unexpected failures, six are due to trivia (they *might* fail for other causes when the trivia are fixed, but there's no reason to expect that), one is a feature request whose test reached testsuite/master before the implementation reached ghc/master and only one may (but need not) indicate a compiler bug at present, that's rather awesome. ==================== Unexpected passes: mc01(hpc,ghci) mc06(hpc,ghci) mc08(hpc,ghci) mc11(hpc) mc16(hpc) mc18(hpc) All these involve the new MonadComprehensions extension, they're expected to work and do so for the normal and optasm ways, maybe they should also be expected to work for hpc and ghci. Additionally, sometimes conc016(threaded2) passes unexpectedly; which thread first gets its exception to the other one is impossible to predict: -- NB. this test is delicate since 6.14, because throwTo is now always -- interruptible, so the main thread's killThread can be legitimately -- interrupted by the child thread's killThread, rather than the other -- way around. This happens because the child thread is running on -- another processor, so the main thread's throwTo is blocked waiting -- for a response, and while waiting it is interruptible. Summing up: Yay!

3 4

entries in profile results
by Kazu Yamamoto 16 May '11

16 May '11

Hello, I'm taking profile for my program with -auto-all -caf-all. I found that I don't understand what "entries" means. An IO function in my program should be called N times but "entries" shows 3N. I inserted putStrLn in that function and ensured that it was called just N times. Please tell me what "entries" mean exactly. --Kazu

2 1

Tracing idea
by Edward Z. Yang 12 May '11

12 May '11

I was thinking it might be useful if we had a per-thread circular buffer in memory for which we pushed a pointer to the info table we had just entered. In the event of a crash, you could dump the contents of the buffer to see what code had been recently executed. To reduce overhead, one might only need to record this information when we do a tail call, and not when the path can be reconstructed from the stack. (Obviously, you'd need to compile in debug mode, and you'd probably want to also add an RTS flag). What do people think? Cheers, Edward

3 4

ghc7, -rtsopts, and g++
by Evan Laforge 06 May '11

06 May '11

So as everyone probably knows, ghc7 requires -rtsopts to enable +RTS parsing. Apparently this makes it include various header files in rts/ when linking, because after upgrading to ghc7 I suddenly got syntax errors from headers there. Some investigation revealed that the problems were use of 'new' as a variable name in rts/storage/Block.h, and implicit conversion from a bool to an enum rtsBool in rts/ClosureMacros.h. These things are fine in C, but not in C++, and I'm linking with -pgmc g++ -pgml g++ so they were a problem. I was able to fix them by simply renaming 'new' and replacing the implicit conversion with explicit. But it makes me think setting g++ for the "C" compiler was incorrect. I'm linking with c++ code via a wrapper that uses 'extern "C" { ... }' to ensure the haskell FFI knows how to call it, and if I don't set pgmc then the link dies horribly and very verbosely when none of the c++ symbols are visible. So I arrived at that flag by guessing after my program wouldn't link without it, not because I saw documentation saying this is how to do it. Is there a better way to link to c++?

2 2

upgrading to 7.0.3 causes assembly errors
by Evan Laforge 05 May '11

05 May '11

So I just upgraded to 7, and on compiling I got: /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:43:0: suffix or operands invalid for `push' /var/folders/++/+++c0U++6+0++4RjPqRgNE++8+c/-Tmp-/ghc88373_0/ghc88373_1.s:47:0: suffix or operands invalid for `push' ... etc. Some digging revealed that it was actually in the compilation of a *_stub.c file, and the underlying problem is thus: This is OS X 10.6. For various reasons, my app is compiled 32 bit, and I'm explicitly passing '-optc-m32 -opta-m32 -optl-m32' to ghc. Previously, of course, this wasn't necessary since ghc always produced 32 bit code. But now there seems to be an issue with flag order. When ghc wants to compile the stub, it runs: g++ -x c ./Ui/RulerC_stub.c -o broken.s -m64 -fno-stack-protector -fno-common -U __PIC__ -D__PIC__ -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=700 -DTABLES_NEXT_TO_CODE -ggdb -m32 ... rest of my flags Then it wants to assemble it: /Developer/usr/bin/gcc -m32 -I./Ui -Ifltk -I. -c broken.s -o ./Ui/RulerC_stub.o -m64 -fno-stack-protector So it looks like when compiling, the user flags go last, overriding the new default -m64. But when assembling, they go first, and are overidden. This seems like an easy fix, I imagine it's just constructing the cmdline inconsistently. Is there a way for me to influence how it constructs the cmdline for gcc for stubs? I mean, without recompiling ghc. I'm supposed to be able to get ghc to compile 32 bit, right? It also seems odd to me that it's compiled and assembled separately, but I suppose there must have been some reason for that. I guess I should have upgraded sooner to catch this back when there was a new ghc 7 release every week...

2 3

Are FFI calls interruptible?
by Bas van Dijk 04 May '11

04 May '11

Hello, Quick question: are safe/unsafe FFI calls interruptible? Thanks, Bas

3 6

Elimination of absurd patterns
by C Rodrigues 03 May '11

03 May '11

I was experimenting with using GADTs for subtyping when I found something interesting. Hopefully someone can satisfy my curiosity. Here are two equivalent GADTs. My understanding was that GHC would translate "Foo" and "Bar" into isomorphic data types. However, GHC 6.12.3 generates better code for 'fooName' than for 'barName'. In 'fooName', there is no pattern match against 'FooExtra'. In 'barName', there is a pattern match against 'BarExtra'. What makes these data types different? data Tagdata TagExtra -------- data Foo a where Foo :: String -> Foo a FooExtra :: IORef String -> Foo TagExtra -- The cmm code for fooName does not match against 'FooExtra'fooName :: Foo Tag -> StringfooName (Foo s) = s -------- data Bar a where Bar :: String -> Bar a BarExtra :: a ~ TagExtra => IORef String -> Bar a -- The cmm code for barName will try to pattern-match against 'BarExtra'barName :: Bar Tag -> StringbarName (Bar s) = s

2 2

Broken ghc-7.0.3/vector combination?
by Daniel Fischer 03 May '11

03 May '11

Investigating the appearance of NaN in criterion's output, I found that NaNs were frequently introduced into the resample vectors when the resamples were sorted. Further investigation of the sorting code in vector-algorithms revealed no bugs there, and if the runtime was forced to keep a keen eye on the indices, by replacing unsafeRead/Write/Swap with their bounds-checked counterparts or by 'trace'ing enough of their uses, the NaNs did not appear. I could not reproduce the behaviour with ghc-7.0.1 (using exactly the same versions of the involved libraries), ghc-7.0.2 (different criterion release, the other libraries identical) or unoptimised compilation with 7.0.3 (no NaNs encountered in some 100+ testruns with varying input). So, is it possible that some change in ghc-7.0.3 vs. the previous versions caused a bad interaction between ghc-optimisations and vector fusion resulting in bad vector reads/writes?

9 14

Elimination of absurd patterns (reformatted)
by C Rodrigues 02 May '11

02 May '11

I'm re-sending this e-mail, hopefully with proper line breaks this time. I was experimenting with using GADTs for subtyping when I found something interesting. Hopefully someone can satisfy my curiosity. Here are two equivalent GADTs. My understanding was that GHC would translate "Foo" and "Bar" into isomorphic data types. However, GHC 6.12.3 generates better code for 'fooName' than for 'barName'. In 'fooName', there is no pattern match against 'FooExtra'. In 'barName', there is a pattern match against 'BarExtra'. What makes these data types different? data Tag data TagExtra -------- data Foo a where Foo :: String -> Foo a FooExtra :: IORef String -> Foo TagExtra -- The cmm code for fooName does not match against 'FooExtra' fooName :: Foo Tag -> String fooName (Foo s) = s -------- data Bar a where Bar :: String -> Bar a BarExtra :: a ~ TagExtra => IORef String -> Bar a -- The cmm code for barName will try to pattern-match against 'BarExtra' barName :: Bar Tag -> String barName (Bar s) = s

2 1