April 2013 - ghc-devs

Restrictions on polytypes with type families
by Richard Eisenberg 13 Nov '13

13 Nov '13

Hi all, GHC doesn't allow type families to be used with polytypes: 1) The right-hand side of a type family instance cannot have a "forall". 2) A type family cannot be applied to a type containing a "forall". 3) A pattern in a type family instance is (oddly) allowed to contain "forall", but this is silly because of (2). Do these restrictions have known reasons for their existence? Or, are there any that are restricted because someone needs to think hard before lifting it, and no one has yet done that thinking? I know, for example, that the unify function in types/Unify.lhs will have to be completed to work with foralls, but this doesn't seem hard. I've run into two separate cases where I've hit this restriction, so this isn't just idle thought. Thanks, Richard

8 15

HEAD build fails on OS X
by Andreas Voellmy 28 Aug '13

28 Aug '13

I got a fresh copy of HEAD today, and the build failed. The failing command is: $ cd libraries && sh gen_contents_index --intree haddock: internal error: /Users/andreas/repos/temp-ghc-2/ghc-build/inplace/lib/html/Ocean.std-theme/hslogo-16.png: copyFile: does not exist (No such file or directory) I have not yet had time to look into this, but hopefully someone knows what happened here. -Andi

7 17

package installation woes with Template Haskell / dynamic libraries
by Richard Eisenberg 13 Jul '13

13 Jul '13

Hi all, --- tl;dr: cabal fails to install a package where one module in the package uses another module via Template Haskell, requiring a .dyn_o file. The compilation order, though, makes .o files before .dyn_o files, so installation fails. Is this my fault or cabal's? --- I've built and installed HEAD (as of Apr 8), on Mac OS 10.8.2, without specifying a build.mk file (i.e., using the defaults). I then tried to install the singletons package. This package has multiple modules, one of which uses another in some Template Haskell code. The TH code also uses the syb and mtl packages. - A simple `cabal install singletons` fails when compiling the module that uses TH, because there are no .dylib files for the syb or mtl libraries. I add 'shared: True' to my ~/.cabal/config file, "dangerous"ly reinstall mtl and syb and try again. - Now, `cabal install singletons` still fails during compilation, because the TH code looks for Singletons.dyn_o, which doesn't exist. The problem is that the vanilla build happens before the shared build, and TH seems to require the shared build. - I try `cabal install singletons --disable-library-vanilla`, and everything compiles, but then I get this: Installing library in /Users/rae/Library/Haskell/ghc-7.7.20130407/lib/singletons-0.8.5/lib cabal: dist/build/HSsingletons-0.8.5.o: does not exist - In the hopes that cabal kept the .dyn_o files around, I try regular `cabal install singletons`, but cabal seems to have discarded the .dyn_o files and I get the same error as before. - So, I `cabal unpack singletons`, go into the singletons folder, and run `cabal install --disable-library-vanilla`, and get the installation error as before. But, the compile worked and the .dyn_o files are kept! So, a final `cabal install` now works. Phew. I have a relatively weak understanding of cabal. My question is: Is the problem I've run into here based on local settings that need to be fixed? Is there a moving part somewhere that needs to be upgraded? Or, is this a real bug somewhere? If the problem isn't local, I see three separate bugs here: 1) I had to "dangerous"ly reinstall mtl and syb to get the shared libraries after updating my ~/.cabal/config. I think it should be possible to augment an existing package installation with a new "way" without reinstalling. 2) If a package uses TH and depends on another package, and if TH requires dynamic linking, cabal should automatically install dynamic versions of the library, overriding settings in ~/.cabal/config. Or, if overriding settings is a no-no, it should give a stern warning. It would make sense if this dependency were required to be stated in the package's .cabal file. 3) If a package uses TH and depends on itself, similar logic should apply (requiring a dynamic build), and the order of compilation should be fixed. I can understand (but, without more knowledge, would disagree with) an argument discarding 1) and 2) as natural consequences of a silly user, but 3) -- especially the compilation order -- seems more fundamental. I don't know of a way of installing singletons now without unpacking it and dancing around this problem. What do you think? Are these bugs? Am I a silly user? Or both? Thanks! Richard

2 1

Stage1Only
by Trevor Elliott 28 Jun '13

28 Jun '13

Hi Everyone, I've been trying to produce just a stage1 compiler by setting Stage1Only in my mk/build.mk. What I've been discovering, is that the build system seems to ignore this (or I haven't set it in the right place) and trys to build a stage2 compiler and its associated tools. What is the best way to stop the build system after stage1 + libraries has finished? Thanks! --trevor

4 14

atMost in GHC.Event.PSQ causes seqfault or bus error
by Kazu Yamamoto 31 May '13

31 May '13

Hi, threadDelay of GHC head causes seqfault or bus error on 32bit machine including Mac and Linux. This bug does not exist as least in GHC 7.4.2. This bug is due to atMost of GHC.Event.PSQ. After modifying libraries/base/base.cabal to export GHC.Event and building GHC head, the following code (compiled by the GHC head with -threaded) causes segfault or bus error: main :: IO () main = do s <- newSource ents <- replicateM 100 (entry s) let q = fold ents print $ Q.atMost 1.5 q fold :: [(Q.Key, Q.Prio)] -> Q.PSQ () fold [] = Q.empty fold ((u,r):xs) = Q.insert u r () $ fold xs entry :: UniqueSource -> IO (Q.Key, Q.Prio) entry s = do u <- newUnique s r <- randomIO return (u,r) But if I copy GHC.Event.PSQ and GHC.Event.Unique, modify their module names, and compile the above code with them, no segfault/bus error happens. I have been tracking this for a long time but I have no idea why this happens. Any advice would be highly appreciated. For more information, please refer to: http://hackage.haskell.org/trac/ghc/ticket/7715 --Kazu

2 2

--with-gcc does not work well
by Kazu Yamamoto 30 May '13

30 May '13

Hi, I'm trying to validate GHC head with GCC 4.7 on FreeBSD. I run "validate" without any modifications: % config_args="--prefix=/ghc-head --with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 --with-gcc-4.2=/usr/local/bin/gcc47 --with-system-libffi --with-ffi-includes=/usr/local/include --with-ffi-libraries=/usr/local/lib" THREADS=10 sh validate This caused an error: Configuring terminfo-0.3.2.5... configure: WARNING: unrecognized options: --with-compiler, --with-iconv-includes, --with-iconv-libraries, --with-gmp-includes, --with-gmp-libraries, --with-gcc checking for gcc... cc checking whether the C compiler works... no configure: error: in `/usr/home/kazu/work/ghc/libraries/terminfo': configure: error: C compiler cannot create executables For GCC, "cc" is guessed. This is because "mk/config.mk.in" does not use "gcc47" to CC_STAGE0. I don't know this is a correct way but I patched as follows: diff --git a/mk/config.mk.in b/mk/config.mk.in index 55f5756..51d3e96 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -487,13 +487,13 @@ GccLT34 = @GccLT34@ GccLT46 = @GccLT46@ CC = $(WhatGccIsCalled) -CC_STAGE0 = @CC_STAGE0@ +CC_STAGE0 = $(CC) CC_STAGE1 = $(CC) CC_STAGE2 = $(CC) CC_STAGE3 = $(CC) AS = $(WhatGccIsCalled) -AS_STAGE0 = @CC_STAGE0@ +AS_STAGE0 = $(AS) AS_STAGE1 = $(AS) AS_STAGE2 = $(AS) AS_STAGE3 = $(AS) After that, "validate" caused this error: gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -fno-stack-protector -Werror -Wall -Icompiler/stage1 -Icompiler/. -Icompiler/parser ... -Werror=unused-but-set-variable -Wno-error=inline -MM compiler/ghci/keepCAFsForGHCi.c -MF compiler/stage1/build/.depend-v.c_asm.bit cc1: error: -Werror=unused-but-set-variable: No option -Wunused-but-set-variable "gcc" is used instead of "gcc47". Note "gcc" is GCC 4.2 which does not accept -Wunused-but-set-variable. This is because that CPP is defined independently on --with-gcc. So, I had to specify CPP to configure: % config_args="--prefix=/ghc-head --with-gcc=/usr/local/bin/gcc47 ... CPP=cpp47 THREADS=10 sh validate Unfortunately, this also caused another error: "/usr/local/bin/ghc" -optc-Werror -optc-Wall -optc-isystem'/usr/home/kazu/work/ghc/compiler/stage1' ... -Wall -XHaskell98 -XNondecreasingIndentation -XCPP -XPatternGuards -fwarn-tabs -O -no-user-package-conf -rtsopts -c ghc/hschooks.c -o ghc/stage1/build/hschooks.o cc1: error: -Werror=unused-but-set-variable: No option -Wunused-but-set-variable Since I don't know how to pass "-pgmc gcc47", I gave up here. I think that the --with-gcc option for "configure" does not work well and we need to fix this. --Kazu

4 7

Safe Haskell validate failure
by Simon Peyton-Jones 10 May '13

10 May '13

When running validate I got these failures (below) from Safe Haskell. Unexpected failures: ghci/scripts Defer02 [bad stderr] (ghci) indexed-types/should_fail T7786 [stderr mismatch] (normal) perf/compiler T3064 [stat too good] (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) But when I manually did cd testsuite/tests/safeHaskell/check make all went fine. Everything passed. Could this be a parallel-make synch problem or something? Or a make-clean problem? Simon =====> ImpSafeOnly01(normal) 1163 of 3620 [0, 0, 0] cd ./safeHaskell/check/pkg01 && $MAKE -s --no-print-directory mkPackageDatabase.ImpSafeOnly01 VANILLA=--disable-library-vanilla PROF=--disable-library-profiling DYN=--enable-shared Wrong exit code (expected 0 , actual 2 ) Stdout: pdb.safePkg01/local.db: safePkg01-1.0 trusted: False M_SafePkg Stderr: pdb.safePkg01/dist/build/M_SafePkg.hi: openBinaryFile: does not exist (No such file or directory) make[3]: *** [safePkg01] Error 1 *** unexpected failure for safePkg01(normal) cd ./safeHaskell/check/pkg01 && $MAKE -s --no-print-directory cleanPackageDatabase.safePkg01 =====> ImpSafeOnly02(normal) 1164 of 3620 [0, 1, 0] cd ./safeHaskell/check/pkg01 && $MAKE -s --no-print-directory mkPackageDatabase.ImpSafeOnly02 VANILLA=--disable-library-vanilla PROF=--disable-library-profiling DYN=--enable-shared cd ./safeHaskell/check/pkg01 && '/5playpen/simonpj/HEAD/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c ImpSafeOnly01.hs -fpackage-trust -package-db pdb.ImpSafeOnly01/local.db -trust base >ImpSafeOnly01.comp.stderr 2>&1 Compile failed (status 256) errors were: ImpSafeOnly01.hs:4:1: Failed to load interface for ‛M_SafePkg’ There are files missing in the ‛safePkg01-1.0’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. *** unexpected failure for ImpSafeOnly01(normal)

5 5

Turning on -funbox-small-strict-fields by default in GHC 7.8
by Johan Tibell 10 May '13

10 May '13

Hi, I like to discuss enabling -funbox-small-strict-fields by default in GHC 7.8. First, a short description of the flag and why I added it. *What does the flag do?* The flag causes all strict, pointer-sized or smaller* fields to be unpacked, as if you preceded them by an UNPACK pragma. *Why does the flag exist?* The flag doesn't allow you to express anything you couldn't already express using UNPACK/-funbox-strict-fields. The purpose of the flag is twofold: - Allow for less clutter in source code. If you look at code tuned for performance, every single small field has an UNPACK pragma (e.g. see bytestring, text, containers, attoparsec, binary, etc). The extra UNPACK pragmas makes the data type declaration harder to read. - To give better performance by default for beginner and intermediate Haskellers. Almost any performance problem I diagnoes (e.g. on StackOverflow) involve telling the person to use UNPACK (and make the field strict). I'd like to only tell them to make the field strict and let compiler deal with the UNPACK. *How do we turn the flag on by default?* Before we turn the flag on by default, we should convince ourselves that it won't hurt performance (e.g. by causing re-boxing when an unpacked field is passed to a non-strict function). Here's my plan: - Look at all data declarations in some set of core libraries (e.g. the ones mentioned above) and see if there are any strict but not unpacked small fields in there. The presence of such fields suggests that the author decided that unpacking was not beneficial there. *Done:* there are no such fields in bytestring, text, binary, containers, or attoparsec. - Run the nofib suite, which now includes some code with strict fields from the language shootout suite, as a sanity check. - Benchmark some large program that isn't carefully tuned by using strictness in just the right places (like our core libraries tend to be), to make sure this change doesn't hurt performance there. I nomiate GHC as the candidate program for this test. Aside: If I recall correctly John Meacham said that JHC has always used this optimization. Does this sound like a reasonable plan? Does anyone have any input on whether this change makes sense? Simon? P.S. I know how to run nofib with and without the flag. How can I benchmark the impact of the flag on building GHC? Does anyone have a step-by-step recipe for using GHC as a benchmark? * This also includes Double, Int64, and Word64 on 32-bit platforms so the program space usage and performance doesn't change dramatically when switching platforms.

8 14

Handling of NaN
by Jan Stolarek 10 May '13

10 May '13

I need some help with my work on ticket #6135. Consider this program: {-# LANGUAGE BangPatterns, MagicHash #-} module Main where import GHC.Exts main = print $ nan## ==## nan## where !(D# nan##) = 0.0 / 0.0 This prints False, which is a correct implementation of IEEE754 standard. However when I compile this with my modified compiler that uses new comparison primops (they return Int# instead of Bool) I get True, whcih obviously is incorrect. I belive that the problem lies in this piece of code from prelude/PrelRules.hs: mkRelOpRule :: Name -> (forall a . Ord a => a -> a -> Bool) -> [RuleM CoreExpr] -> Maybe CoreRule mkRelOpRule nm cmp extra = mkPrimOpRule nm 2 $ rules ++ extra where rules = [ binaryLit (\_ -> cmpOp cmp) , equalArgs >> -- x `cmp` x does not depend on x, so -- compute it for the arbitrary value 'True' -- and use that result return (if cmp True True then trueVal else falseVal) ] It looks that equalArgs suddenly started to return True, whereas it previously returned False. On the other hand in GHCi I get correct result (False). Can anyone give me a hint why is this happening? Janek

3 9

DBCS encoding support on Windows
by Max Bolingbroke 09 May '13

09 May '13

Hi GHCers, I've implemented support in GHC for extra Windows code pages on the branch "dbcs" of the base library. The problem this solves is that currently users of Haskell on a Windows machine running in a locale which uses a double-byte code page such as CP936 (GBK) or CP950 (Big5) cannot properly interact with the Windows console in their native language. Unfortunately code page support is a prerequisite for getting this to work correctly because for all Microsoft's fine talk about Unicode being the future, the Windows console does not seem to support it properly - code pages are the only way to go for console input and output. As the standard Windows locale encodings in many regions, these code pages are also the predominant method of encoding text files in many countries, so they are useful outside the console. The solution is along the lines suggested in http://hackage.haskell.org/trac/ghc/ticket/3977, i.e. we create an iconv-like interface to Window's MultiByteToWideChar and WideCharToMultiByte APIs by the judicious use of binary search. In my branch, these APIs will be used whenever we don't have a built-in native Haskell TextEncoding for the code page (we used to fall back on using latin1 for such code pages). Unless there are any objections I'll merge this into the base library main branch next week. Cheers, Max

2 4