- ghc-devs - Haskell.org

Validation failures on master
by Dr. ERDI Gergo 12 Apr '14

12 Apr '14

The ultimate case of 'the pot calling the kettle black'[*]: I'm seeing validation errors on 'master' 7233638: Unexpected passes: arrows/should_fail arrowfail001 (normal) lib/integer integerConstantFolding (normal) [*] just to be clear, I mean me being the pot in this case:)

1 0

Defined but not used in TcPatSyn
by Joachim Breitner 12 Apr '14

12 Apr '14

Hi, someone introduced a validate error recently: compiler/typecheck/TcPatSyn.lhs:324:19: Warning: Defined but not used: `lit' compiler/typecheck/TcPatSyn.lhs:325:17: Warning: Defined but not used: `n' Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

3 4

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