- ghc-devs - Haskell.org

Bug names
by Ian Lynagh 25 Jan '13

25 Jan '13

Hi all, Would anyone mind if I were to rename all the numeric bug names, e.g. rename 1750 to T1750? I find names like 1750 a pain to search for in testlog, as they match lines like "=====> plugins01(normal) 1750 of 3403 [0, 6, 0]". Thanks Ian

4 3

seem to have some test suite failures for ghc 7.6.2rc on my mac
by Carter Schonwald 25 Jan '13

25 Jan '13

Hey all, the summary of a make test run on my macbook air is as follows is this a good outcome for running make test, or are any of these issues with the release candidate? (i'm just getting started with ghc dev related matters, so i'm not sure how to interpret this) thanks! -Carter OVERALL SUMMARY for test run started at Fri Jan 25 01:58:38 EST 2013 3402 total tests, which gave rise to 16608 test cases, of which 10 caused framework failures 13530 were skipped 2971 expected passes 50 had missing libraries 35 expected failures 1 unexpected passes 21 unexpected failures Unexpected passes: ../../libraries/directory/tests T4113 (normal) Unexpected failures: codeGen/should_run cgrun071 [bad exit code] (normal) dynlibs T3807 [bad exit code] (normal) llvm/should_compile 5486 [stderr mismatch] (optllvm) llvm/should_compile 5681 [stderr mismatch] (optllvm) perf/compiler T4801 [stat too good] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) safeHaskell/check/pkg01 ImpSafeOnly01 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly02 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly03 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly04 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly05 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly06 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly07 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly08 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly09 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly10 [exit code non-0] (normal) safeHaskell/check/pkg01 safePkg01 [bad exit code] (normal)

1 0

[Patch] Android cross compile support
by Nathan Hüsken 25 Jan '13

25 Jan '13

Hey, Appened is a patch that enables cross compilation to android. For the patch to work, config.guess and config.sub have to be updated to a newer version so that they recognize linux-android. For the libraries some additional patches are needed, I will send them also to this list. Will this patch be applied to ghc HEAD? Regards, Nathan

4 4

[PATCH] do not use -rpath-link linker option on Solaris
by Karel Gardas 25 Jan '13

25 Jan '13

This patch removes usage of -rpath-link option on Solaris OS since it is not supported by the Solaris' linker and its usage causes failures of a lot of `dyn' testcases --- compiler/main/DriverPipeline.hs | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index f47aea7..34d045c 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1752,7 +1752,16 @@ linkBinary dflags o_files dep_packages = do rpath = if gopt Opt_RPath dflags then ["-Wl,-rpath", "-Wl," ++ libpath] else [] - in ["-L" ++ l, "-Wl,-rpath-link", "-Wl," ++ l] ++ rpath + -- Solaris 11's linker does not support -rpath-link option. It silently + -- ignores it and then complains about next option which is -l<some + -- dir> as being a directory and not expected object file, E.g + -- ld: elf error: file + -- /tmp/ghc-src/libraries/base/dist-install/build: + -- elf_begin: I/O error: region read: Is a directory + rpath-link = if (platformOS platform) == OSSolaris2 + then [] + else ["-Wl,-rpath-link", "-Wl," ++ l] + in ["-L" ++ l] ++ rpath-link ++ rpath | otherwise = ["-L" ++ l] let lib_paths = libraryPaths dflags -- 1.7.3.2

2 1

LLVM build not working?
by Stephen Paul Weber 24 Jan '13

24 Jan '13

I just tried my LLVM unregistered build again against HEAD (for QNX ARM) and got this: make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -static -H64m -O0 -fllvm -package-name integer-simple-0.1.1.0 -hide-all-packages -i -ilibraries/integer-simple/. -ilibraries/integer-simple/dist-install/build -ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/dist-install/build -Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/. -optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package-name integer-simple -Wall -XHaskell98 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XNoImplicitPrelude -O -fllvm -no-user-package-db -rtsopts -odir libraries/integer-simple/dist-install/build -hidir libraries/integer-simple/dist-install/build -stubdir libraries/integer-simple/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/integer-simple/./GHC/Integer/Type.hs -o libraries/integer-simple/dist-install/build/GHC/Integer/Type.o when making flags consistent: Warning: Compiler unregisterised, so compiling via C /tmp/ghc30896_0/ghc30896_0.hc: In function 'c2pA_entry': /tmp/ghc30896_0/ghc30896_0.hc:3691:1: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] /tmp/ghc30896_0/ghc30896_0.hc:3691:17: error: expected ')' before numeric constant make[1]: *** [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] Error 1 make: *** [all] Error 2 You can clearly see that `-fllvm` *is* being passed, and I double-checked and I do have the quick-llvm build type selected... but it's trying via C? What? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

2 2

Darcs.haskell.org down again
by Simon Peyton-Jones 24 Jan '13

24 Jan '13

Ian, Paul It seems that 'abbott' is down again. Two days in a row suggests something is wrong. Is there anything either of you can do to help? Simon

4 4

-lrt and -lpthread order with static linking
by Anatoly Yakovenko 24 Jan '13

24 Jan '13

ghc places -lrt after -lpthread, causing pthread.a symbols to be missing when linking with -static and just for kicks it generates a .o in /tmp that it deletes on exit, so i cant relink. i think whoever added that owes me a beer. so in one shell i did a while true; do cp /tmp/*/*.o .; done and in another shell i ran the make command to grab that tmp file, then i was able to stick into the collect command i can grab from -optl--verbose and fully link the exe.

3 2

Stack smashing when using FunPtr wrappers on ARM
by Stephen Paul Weber 24 Jan '13

24 Jan '13

I just got my unregistered LLVM-based ARM cross-compiler to a working place, which means I can produce any binaries which do no crash. Yay! However, <http://hackage.haskell.org/trac/ghc/ticket/7621> when I try to use FunPtr wrappers, something smashes the stack. Would others working on ARM cross-compilers be willing to try this test and see if it works for you: {-# LANGUAGE ForeignFunctionInterface #-} module Main (main) where import Foreign.Ptr foreign import ccall "wrapper" wrap_refresh :: ( IO ()) -> IO (FunPtr ( IO ())) main :: IO () main = do wrap_refresh (return ()) return () -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

3 6

Today's validate failures
by Simon Marlow 24 Jan '13

24 Jan '13

Unexpected passes: perf/should_run T5113 (normal) Unexpected failures: cabal 1750 [bad stderr] (normal) cabal shadow [bad stderr] (normal) deriving/should_compile T1133 [bad exit code] (normal) deriving/should_fail T1133A [bad exit code] (normal) perf/haddock haddock.base [stat not good enough] (normal) polykinds T7594 [stderr mismatch] (normal) We know what the cabal failures are, and Simon PJ has said he'll be fixjng those. T1133 and T1133A look like a problem with spaces in pathnames: Stderr: make[3]: /home/simon/code-all/work/ghc-validate/bindisttest/install: Command not found make[3]: *** [T1133A] Error 127 *** unexpected failure for T1133A(normal) T7594 has been failing for a few days, I think: --- ./polykinds/T7594.stderr 2013-01-23 09:07:45.400727923 +0000 +++ ./polykinds/T7594.comp.stderr 2013-01-24 09:40:12.030265492 +0000 @@ -1,6 +1,3 @@ -h0 -h1 -h2 T7594.hs:25:11: Couldn't match type `b' with `IO ()' *** unexpected failure for T7594(normal)

3 3

ghc passing -undef to preprocessor and thereby eliminating OS specific defines
by Nathan Hüsken 24 Jan '13

24 Jan '13

Hey, I am trying to adapt some code in the libraries when compiling for android (i.E. because some things are different on android to other posix systems). So in C code I would just do "#ifdef __ANDROID__". While in the *.h and *.c files it seems to work, it does not work in *.hs files. I noted that the preprocessor is run like this: arm-linux-androideabi-gcc -E -undef -traditional -fno-stack-protector -DTABLES_NEXT_TO_CODE The "-undef" parameter is causing the __ANDROID__ define to be removed. Does it make sense to pass "-undef" to the preprocessor? Any other Ideas how I could adapt the code for android? Thanks! Nathan

2 1