April 2014 - ghc-devs

RFC: provide patch-level information at __GLASGOW_HASKELL__
by Herbert Valerio Riedel 11 Apr '14

11 Apr '14

Hello, I know this has come up various times. So this is mostly an attempt to see what the current position is on this topic: The current scheme is documented as ,---- | The value of __GLASGOW_HASKELL__ for a major release x.y.z is the | integer xyy (if y is a single digit, then a leading zero is added, so | for example in version 6.8.2 of GHC we would have | __GLASGOW_HASKELL__==608). `---- This has lead to confusion in the past, e.g. the following two values __GLASGOW_HASKELL__ == 702 __GLASGOW_HASKELL__ == 704 were sometimes confused (by me at least) to mean 7.0.2 and 7.0.4 respectively. And sometimes when writing conditionals, it also happened that '__GLASGOW_HASKELL__ >= 722' was written to mean >= 7.2.2. Moreover, when GHC 7.2.2 came out, it would have been useful to be able to discriminate 7.2.1 vs 7.2.2 easily, as some SafeHaskell properties changed between 7.2.1 and 7.2.2. Therefore, I'd propose to extend this constant by a patch-level digit for future GHC versions (starting with 7.10.1), i.e. __GLASGOW_HASKELL__ == 7090 -- 7.9 branch __GLASGOW_HASKELL__ == 7100 -- 7.10.1 release candidates __GLASGOW_HASKELL__ == 7101 -- 7.10.1 __GLASGOW_HASKELL__ == 7102 -- 7.10.2 __GLASGOW_HASKELL__ == 7121 -- 7.12.2 NB: this ensures that __GLASGOW_HASKELL__ retains its ordering relation. There's just a steeper jump from 7.8.1 to 7.10.1, but existing code using conditionals such as #if (__GLASGOW_HASKELL__ >= 708) && (__GLASGOW_HASKELL__ < 709) for currently existing GHC versions will continue to work as expected. Alternative ideas: - Define a __GLASGOW_HASKELL_PATCHLEVEL__ containing only the patch-level number. (c.f. GNU GCC's __GNUC_PATCHLEVEL__ constant) This one might have the least impact, as its existence can be ignored safely, and we could even use this starting with GHC 7.8.2 with low risk of affecting users. - define a __MIN_VERSION_GHC__(x,y,z) macro in the style of Cabal's MIN_VERSION_<pkgname>() macros While this has the most structure, this has also the issue of backward compatibility, as for earlier GHC versions you'd have to check for the existence of the macro before using it to avoid compile-time errors. Cheers, hvr

7 7

Breaking bug in 7.8.1
by Simon Peyton Jones 11 Apr '14

11 Apr '14

Austin, Simon (and others) As you'll see from https://ghc.haskell.org/trac/ghc/ticket/8978, I succeeded in introducing a new bug into 7.8.1 post RC2, when fixing #8913. And it seems to matter. (Because of the windows seg-fault saga, RC2 was active for a long time, and none of our regression tests showed up this bug.) It looks to me that we have little choice but to push out 7.8.2, more or less immediately, and advise everyone to ignore 7.8.1. Do you agree? Sorry about this. Simon

3 4

GHC HQ on Launchpad
by Edward Z. Yang 11 Apr '14

11 Apr '14

Hello all, I've created a GHC team on Launchpad to manage the code imports and build recipes https://launchpad.net/~ghc Why? I recently was playing around with Launchpad's build recipes service, and realized that this could be another helpful source of builds for GHC (resulting in proper Ubuntu packages which then can be directly installed by installing a PPA). If you're not interested, you can just ignore (or remove yourself) from the group. Conversely, if I didn't find your Launchpad identifier, please ask to be added. Cheers, Edward

6 5

Compiling GHC with Clang
by Herbert Valerio Riedel 11 Apr '14

11 Apr '14

Hello *, I've been trying to compile GHC with Clang instead of GCC on Ubuntu, by configuring the build with CC=/usr/bin/clang ./configure --with-gcc=/usr/bin/clang but then, 'make' runs into ,---- | "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name ghc-7.8.0.20140401 -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.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -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.2 -package transformers-0.3.0.0 -package unix-2.7.0.1 -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 -O0 -fasm -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/stage2/build/Lexer.hs -o compiler/stage2/build/Lexer.o -dyno compiler/stage2/build/Lexer.dyn_o | | compiler/stage2/build/Lexer.hs:2426:41: | Couldn't match expected type ‘[Char]’ with actual type ‘Int#’ | In the first argument of ‘(>=)’, namely ‘offset’ | In the expression: (offset >= "0#") | | compiler/stage2/build/Lexer.hs:2426:41: | Couldn't match expected type ‘Int#’ with actual type ‘Bool’ | In the expression: (offset >= "0#") | In the first argument of ‘(&&)’, namely | ‘(tagToEnum# (offset >= "0#"))’ | In the expression: | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) | | compiler/stage2/build/Lexer.hs:2426:73: | Couldn't match expected type ‘[Char]’ with actual type ‘Int#’ | In the first argument of ‘(==)’, namely ‘check’ | In the expression: (check == "ord_c") | | compiler/stage2/build/Lexer.hs:2426:73: | Couldn't match expected type ‘Int#’ with actual type ‘Bool’ | In the expression: (check == "ord_c") | In the second argument of ‘(&&)’, namely | ‘(tagToEnum# (check == "ord_c"))’ | In the expression: | (tagToEnum# (offset >= "0#")) && (tagToEnum# (check == "ord_c")) | make[1]: *** [compiler/stage2/build/Lexer.o] Error 1 | make: *** [all] Error 2 `---- the versions of happy & alex were: ,---- | $ happy --version | Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow | | $ alex --version | Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow `---- ...anyone know why this happens when using Clang instead of GCC, or better yet, what I need to do in order to build GHC with Clang on Linux?

3 9

Validate failures (perf, ghc-7.8)
by Edward Z. Yang 10 Apr '14

10 Apr '14

I've got perf failures on Linux 64-bit on ghc-7.8 (and master too, I think). Please take a look. Unexpected results from: TEST="T4801 T3064 T5837 T6048" OVERALL SUMMARY for test run started at Thu Apr 10 15:33:27 2014 PDT 0:02:52 spent to go through 3920 total tests, which gave rise to 12853 test cases, of which 9274 were skipped 26 had missing libraries 3491 expected passes 58 expected failures 0 caused framework failures 0 unexpected passes 4 unexpected failures Unexpected failures: perf/compiler T3064 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm)

1 0

Website repository
by Austin Seipp 10 Apr '14

10 Apr '14

Hello all, While making the release the other day, one thing I found odd is that the GHC website is still under Darcs version control on the website. I'm not sure how many people are generally aware of this, however, but you should just be able to darcs get http://haskell.org/ghc I'm wondering if we should move this somewhere else more public. I've wanted someone to perhaps look into updating the website to something a little more modern an easier to update for a while now.* Right now it's just a bunch of SHTML pages stamped together, and it could probably be a lot easier to maintain. I don't necessarily propose we put it in the GHC repository (the LLVM folks do this, but I think it would make actually *updating* the website somewhat confusing), just somewhere more public. Does anyone have any inputs? My first inclination is to just put it on git.haskell.org, but perhaps the github.com/haskell organization is a better place (a bit more public). Just wondering if anyone has thoughts. * If someone out there is interested in doing this that would be excellent, by the way, and I'm sure everyone would appreciate it :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 3

Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-, citeproc / highlighting-kate
by Michal J. Gajda 10 Apr '14

10 Apr '14

Dear Devs, On 04/10/2014 09:09 AM, ghc-devs-request(a)haskell.org wrote: > Filed the reproducer as a new ticket: > https://ghc.haskell.org/trac/ghc/ticket/8980 > > [ Looks like highlighting-kate asks to be added to > compiler performance benchmarks (are there such ones?) > It tends to stress ghc all the time: > http://hackage.haskell.org/trac/ghc/ticket/3664 > ] Please consider adding hPDB too, if you want to stress the optimizer. It shows GHC optimizer at its best, with at least 10-20% improvement in every major version of the compiler since 6.12. Unfortunately at cost of very long compile times. Please let me know if I should submit a driver code for automatic benchmarks it (it is in hPDB-examples.) Thanks! >> > SpecConstr is too aggressive: it sometimes blows up the program badly and we have no good solution. See Trac #7898, #7068, #7944, #5550, #8836. And #8960, where GHC runs out of memory. (Only in 7.8.) Should be easy to reproduce by just `cabal install hPDB`. >> > I notice that the latter three are actually fixed in 7.8, so worth trying that. If it still fails, do add instructions to reproduce to one of the above open tickets, or make a new one. >> > >> > Meanwhile you can use -fno-spec-constr to simply switch it off for offending modules. That should get you going. -- Best regards Michal

1 0

Re: Trac seems to think I'm a spambot...?
by Kyle Van Berendonck 10 Apr '14

10 Apr '14

Hmm. I just got flagged as a spambot trying to reply to a ticket too. It did give me a captcha option though.

9 14

ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc-citeproc / highlighting-kate
by Sergei Trofimovich 09 Apr '14

09 Apr '14

Hello! I have noticed the problem in ghc-7.6.3 first when tried to build all haskell userland with -O2 opt level. It led to amazing bugs! Here is one of those (highlighting-kate hackage package): > [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) > stack overflow: use +RTS -K<size> to increase it How to reproduce it: 1. Download a bundled file (6.6MB): http://code.haskell.org/~slyfox/selfcontained-eater-ghc-7.8-rc2.tar.gz 2. Unpack and run there: ./mk.sh The script is designed to plug any built ghc version w/o external depends. Command will fail as: $ ./mk.sh ... [281 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting-kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) stack overflow: use +RTS -K<size> to increase it On ghc-7.6.3 it will progress a bit more: down to 452 file and will crash there similar way. I've 'cabal unpack'-ed all sources and configured/de-.hsc-ed them manually/added needed -DWhatever / added {-# LANGUAGE CPP #-} around. Nothing else. It's very hard to shrink such large thing manually down to 2-3 files. Would be cool if ghc (and cabal) would be able to spit something self-sufficient (like 'gcc -i' does) for devs to reproduce. Adding '-v' shows such log: ... *** Simplifier: Result size of Simplifier iteration=1 = {terms: 21,973, types: 21,838, coercions: 1,842} Result size of Simplifier iteration=2 = {terms: 21,952, types: 21,819, coercions: 1,842} Result size of Simplifier = {terms: 21,950, types: 21,817, coercions: 1,842} *** SpecConstr: Result size of SpecConstr***<CRASH> Thanks! -- Sergei

2 3

Avoiding bumping the major version of base in every release
by Johan Tibell 09 Apr '14

09 Apr '14

Hi! Bumping the major version number of base creates a bunch of work for package maintainers. Some times this work is justified, when there were actual non-backwards compatible API changes and maintainers need to fix their code. Often the work is busy work, as there were no real breakages and maintainers need to update their version bounds and make a new release. When bumps to the major version leads to busy work, maintainers often express a desire to get rid of version bounds altogether. While that might be a natural reaction, I don't think that's actually a good idea and it will lead to more breakages in the end*. All this is to say, we should try to avoid major version bumps to base. Here's my suggestion *Short term* - Make sure we only bump the major version number when we actually make a breaking change. We don't need to bump base because the major GHC version number changed. - Try harder to not make breaking changes. Breaking changes has a very high cost to users and are seldom worth it to them. For example, avoid renaming functions just because the new name feels cleaner. Just add a new function and have the old function call the new function. All successful languages do this. *Medium term* - Break up base a bit. There are several other good reasons to do this, but having a monolithic base means that breaking changes to the most obscure modules cause a major version bump for the package as a whole. * But in the case of missing upper bounds, the breakages and extra work falls on the users of libraries, not on their maintainers. That's really bad as the users are not really in a position to deal with the breakages. -- Johan

4 6