- ghc-devs - Haskell.org

Yet Another Hoopl Question
by Jan Stolarek 15 Aug '13

15 Aug '13

I have yet another Hoopl question. One of my rewrites allocates a new unique local register and this register is later added as a fact. So I have Cmm code that looks like this: I32[(old + 4)] = complicated_expr which is rewritten to: newReg1 = complicated_expr I32[(old + 4)] = newReg1 and then I add { I32[(old + 4)] = newReg1 } as a fact. When Hoopl reaches end of the iteration it realizes it has learned some new facts, so it keeps the facts (including fact about a new unique register) and discards rewritten graph (including said new register). In the next iteration it performs the rewrite again, allocating a different new register and adding fact about this different register. At the end of this iteration same thing happens again: facts are kept, rewrite is discarded. And so my code falls into an infinite loop, because every time I'm allocating a different register and every time hoopl thinks it learned sth new and discards the rewritten graph. How can I perform this rewrite and avoid falling into a loop? Janek

4 5

RE: [GHC] #7574: Register allocator chokes on certain branches with literals
by Simon Peyton-Jones 15 Aug '13

15 Aug '13

Austin thanks for adding the test. But don't forget to populate the "Test case" field of the ticket; I've done it for this one. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of GHC | Sent: 14 August 2013 07:44 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7574: Register allocator chokes on certain branches with | literals | | #7574: Register allocator chokes on certain branches with literals | ---------------------------------------+----------------------------------- | Reporter: thoughtpolice | Owner: thoughtpolice | Type: bug | Status: new | Priority: highest | Milestone: 7.8.1 | Component: Compiler (NCG) | Version: 7.7 | Resolution: | Keywords: ncg, codegen | Operating System: Unknown/Multiple | Architecture: | Type of failure: Compile-time crash | Unknown/Multiple | Test Case: | Difficulty: Unknown | Blocking: | Blocked By: 7573 | | Related Tickets: #7571,#7534 | ---------------------------------------+----------------------------------- | | Comment (by Austin Seipp <aseipp@…>): | | In [changeset:647875eacb313b97af5525dc92df98ec32171d16/testsuite]: | {{{ | #!CommitTicketReference repository="testsuite" | revision="647875eacb313b97af5525dc92df98ec32171d16" | Add a failing test, see #7574. | | Signed-off-by: Austin Seipp <aseipp(a)pobox.com> | }}} | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7574#comment:19> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

2 1

Re: primitive package with new Int# primops
by Jan Stolarek 15 Aug '13

15 Aug '13

Hi Luite, I applied my patches only to primitive package stored as a boot library in GHC repositories. My changes should probably be ported upstream to main repo of primitive package, but I admit I don't know what the workflow for this is. If you desperately need latest version of primitive working with GHC HEAD you can port my changes manually - it's only three lines of code! Janek Dnia środa, 14 sierpnia 2013, napisałeś: > hi Jan and Roman, > > I'm trying to install the primitive package with the latest GHC HEAD, > however the version available at > > https://github.com/ghc/packages-primitive > > which includes the primops changes, appears to be based on version 0.4 and > is missing setByteArray. The code.haskell.org repository does have > setByteArray but not the primops updates. Is there an updated version 0.5 > somewhere available? > > cheers, > > Luite

2 1

config.status: error: cannot find input file: `include/HsTimeConfig.h.in'
by Peter Simons 15 Aug '13

15 Aug '13

Hi guys, I have trouble building recent snapshots of the compiler, despite the fact that the build bot says they ought to build fine. The error I'm getting is this one: configure: creating ./config.status config.status: error: cannot find input file: `include/HsTimeConfig.h.in' make[1]: *** [libraries/time/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 A complete build log is at <http://hydra.cryp.to:8080/build/7563/nixlog/2/>. Is this a known issue? Best regards, Peter

2 1

Deriving clauses for EmptyDataDecls [was: request for reviews for my first patch -- ticket 7401]
by Austin Seipp 14 Aug '13

14 Aug '13

On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > My proposal below doesn't really give different behavior for EmptyDataDecls in the two scenarios… the available constructs are the same under either H98 or H2010. It's just that the "distance" from the spec is different. > > Personally, I'm loathe to stray from a well-defined note in a standard for this. You're right, sorry about that. I suppose we can let someone else weigh in on this note. > I see my proposal below as a feasible solution to #7401, but I would actually favor not implementing any change here, because the workaround -- using standalone deriving -- is so easy and doesn't seem to have any real drawbacks (e.g. performance). Hmmm, I'm sort of ambivalent at this point. Looking at the user manual[1], the relevant point for -XStandaloneDeriving is that "Unlike a deriving declaration attached to a data declaration, GHC does not restrict the form of the data type..." At the same time, from a user POV, I'd think it's reasonably annoying to reject: data Foo deriving (Eq, Show, Ord) in favor of: data Foo deriving instance Eq deriving instance Show deriving instance Ord with an extra extension - and if you happen to mention a type variable, then it gets even longer since the context isn't inferred. Also, given that EmptyDataDecls in its current form is now standard in H2010, but StandaloneDeriving is not, this makes for longer code for people who do want to be standards compliant to write the trivial instance. And as a user of H2010, I'd see an empty data type as "a data type" - and not an extension. So I might expect deriving to work consistently with it, like with any other H2010 data type. This, I suppose, is what I was alluding to when I talked about 'inconsistency' earlier. Although, then it is a question of the standard itself! And then maybe it should be under an extra flag. I think there are legitimate points on all sides here. But, I think this is pretty squarely a 'user interface problem'. It's easy for us no matter what. So, I have CC'd glasgow-haskell-users - I think there's room for voices on this note, and I'd really appreciate users and developers weighing in. [1] http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/deriving.html > Richard > > On Aug 12, 2013, at 12:55 AM, Austin Seipp wrote: > >> On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >>> But, instead of creating a new extension for this feature, what about just co-opting EmptyDataDecls? More concretely, I propose this: >>> >>> Under H98: EmptyDataDecls allows both the declaration of empty data decls and deriving instances for them. >>> >>> Under H2010: EmptyDataDecls allows deriving instances for empty data decls. >>> >>> This proposal brings the annoyance that H2010 no longer implies EmptyDataDecls. >>> >>> Thoughts? >>> >>> Richard >>> >> >> IMHO, I'd find this inconsistency in extension behavior much more >> annoying than just going against the standard on this note. But that's >> just my 0.02c. >> >> -- >> Regards, >> Austin - PGP: 4096R/0x91384671 > -- Regards, Austin - PGP: 4096R/0x91384671

2 1

Segfault on x86 with -O2
by Kazu Yamamoto 14 Aug '13

14 Aug '13

Hi, Some changes in the last 8 days fixed segfault on 32bit x86 with -O2: http://ghc.haskell.org/trac/ghc/ticket/7953 I read recent log messages but I cannot guess which commits fixed this bug. Does anyone guess? P.S. Thanks to this, now I started running Mighty with multicore IO manager on mew.org. I'm watching whether or not multicore IO manager works stably in the real world. --Kazu

3 5

RTS option parsing
by David Laing 13 Aug '13

13 Aug '13

Hi, I'm brand new to GHC development, and have been looking at: http://ghc.haskell.org/trac/ghc/ticket/4243 I was initially thinking of something like getopt_long_only, as per: http://linux.die.net/man/3/getopt_long however it looks like the portability of that function isn't the greatest, and from looking at rts/RtsFlags.c:procRtsOpts(...) it might not be the best solution. Unless I've missed something, it seems that the processing of each flag is independent of the others, at least once we get into procRtsOpts(...), and the processing of a flag either mutates the RtsFlags variable or results in an error. If that's not likely / wanted to change I think there are some nifty ways to abstract that, as long as function pointers aren't frowned on in the RTS code :) Since it looks like it would be a sizeable patch, should I put together a proof-of-concept and ask for feedback sooner rather than later? I'd hate to emerge from my codecave with a fully-formed but unacceptable solution. While I'm at it - does anyone have any thoughts or wishlists for a cleaned up option parser? Cheers, Dave

3 3

Two Hoopl questions
by Jan Stolarek 13 Aug '13

13 Aug '13

I have two questions about using Hoopl: 1) I'm debugging some Hoopl transformations that often fall into an infinite loop. Probably the easiest way to find the cause would be to allow only a limited number of iterations and then examining the rewritten output. I think that optimization fuel was designed exactly with this scenario in mind, but Compiler.Hoopl module in hoopl library does not re-export functions needed to use Fuel (e.g. runWithFuel). Why are these functions hidden? Is there another interface for using fuel? 2) In my algorithm I need to initialize all of the blocks in a graph with bottom element of a lattice, except for the entry block, which needs some other initial values. I've written something like this: cmmCopyPropagation dflags graph = do let entry_blk = g_entry graph g' <- dataflowPassFwd graph [(entry_blk, (Top , Top))] $ analRewFwd cpLattice cpTransfer cpRewrite return . fst $ g' cpLattice = DataflowLattice "copy propagation" (Bottom, Bottom) cpJoin However, it seems that Bottom values passed to cpLattice are ignored - I could replace them with `undefined` and the code would still run without causing an error. Is there something obviously wrong in the way I pass initial fact values to dataflowPassFwd, or should I look for the problem in other parts of my code? Janek

4 15

Hoopl 3.9 not on hackage
by Thomas Schilling 13 Aug '13

13 Aug '13

I just noticed that the latest version of hoopl (shipped with 7.6.3) is not on Hackage. Is there a reason for this (other than oversight)? / Thomas

4 4

Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
by Luke Iannini 13 Aug '13

13 Aug '13

Hi Stephen/all, I got LLVM 3.0 installed and started building again but hit a very strange problem now wherein tons of layout-based code (as in http://en.wikibooks.org/wiki/Haskell/Indentation) is suddenly erroring out, e.g. compiler/coreSyn/CoreUnfold.lhs:481:2: parse error (possibly incorrect indentation or mismatched brackets) (some files also seem to be triggered by mixed tabs and spaces) I can fix the errors one by one by converting the code to use more concrete indentation (like do thing1 thing2 ) but it's all over the tree. Anyone have any idea what might cause this? Cheers Luke On Fri, Aug 9, 2013 at 6:14 AM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen(a)blacksapphire.com> wrote: > Luke, > > Try llvm version 3.0 - that's what I'm using, and it definitely worked > before. llvm-3.1 is broken for GHC+ARM. As for llvm >= 3.2, I'm not sure if > it's been fixed yet, but it wasn't working last time I tried a couple of > months ago. I think this was because llvm is getting fussier about its > input and GHC hasn't been "tightened up" yet. > > It's really easy to build llvm from source. > > > Steve > > > On 09/08/13 20:35, Luke Iannini wrote: > >> v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1f<https://gist.github.com/lukexi/7ca55b36269703236f1f> >> >> >> On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <lukexipd(a)gmail.com >> <mailto:lukexipd@gmail.com>> wrote: >> >> OK, that got me past that one. >> >> Now I'm stuck here during compilation of integer-simple: >> https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9<https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9> >> >> ("unsupported relocation on symbol"/"co-processor offset out of >> range") >> >> >> On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini <lukexipd(a)gmail.com >> <mailto:lukexipd@gmail.com>> wrote: >> >> OK, I'm underway on this. >> >> First roadbump was: >> >> >> "inplace/bin/ghc-stage1" -static -H32m -O -Iincludes >> -Iincludes/dist -Iincludes/dist-**derivedconstants/header >> -Iincludes/dist-ghcconstants/**header -Irts -Irts/dist/build >> -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts >> -irts/dist/build -irts/dist/build/autogen -Irts/dist/build >> -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o >> rts/dist/build/Apply.o >> >> >> >> >> You are using a new version of LLVM that hasn't been tested yet! >> We will try though... >> /usr/local/bin/llc: : error: unable to get target for >> 'arm-apple-darwin10', see --version and --triple. >> >> >> which I figured out were because the homebrew LLVM 3.4 only >> includes host platforms by default (x86/x86-64) >> Reinstalling it with all-targets enables them all: >> brew install llvm --with-clang --all-targets --HEAD >> >> Trying again now. >> >> >> >> >> On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini <lukexipd(a)gmail.com >> <mailto:lukexipd@gmail.com>> wrote: >> >> Update: I've got GHC HEAD building on 10.9 again, tonight >> I'll dive into the iOS patch! >> Cheers >> Luke >> >> >> On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald >> <carter.schonwald(a)gmail.com >> <mailto:carter.schonwald@**gmail.com<carter.schonwald(a)gmail.com>>> >> wrote: >> >> if you're on 10.8, just DL the 4.6 CLI tools to get >> things working again. >> >> If you're on 10.9, you'll need to use recent GHC head + >> CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI >> tools may have all the needed clang patches, but thats >> still needing its own validation, orthogonal to the IOS >> related issues ) >> >> >> On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini >> <lukexipd(a)gmail.com <mailto:lukexipd@gmail.com>> wrote: >> >> Hi Stephen, >> >> I installed 10.9 for another project and thus am in >> the middle of fixing up my system to be able to >> build GHC again, but I think I'm close — as soon as >> I have it going I'll try this. >> >> In the meantime someone still on 10.8 should >> definitely try the patch! >> >> Hope you're great! >> Luke >> >> >> On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath >> [to GHC-iPhone] >> <likeliest.complexions.**stephen(a)blacksapphire.com<likeliest.complexions.stephen(a)blacksapphire.com> >> <mailto:likeliest.complexions.** >> stephen(a)blacksapphire.com<likeliest.complexions.stephen(a)blacksapphire.com> >> >> >> >> wrote: >> >> Hi all, >> >> A couple of months ago I got some patches >> applied to GHC mainline for the ability to cross >> compile to iOS. I've been doing other things and >> now I want to test those changes. The trouble >> is, I am having Apple trouble and I can't get >> Xcode to work. >> >> If anyone is interested in testing it for me, >> I'd appreciate it. >> >> The patch attached here needs to be applied to >> GHC head. Using this, I was able to get the >> cross compiler to build. The instructions are >> here: >> >> http://ghc.haskell.org/trac/__** >> ghc/wiki/Building/__**CrossCompiling/iOS<http://ghc.haskell.org/trac/__ghc/wiki/Building/__CrossCompiling/iOS> >> >> <http://ghc.haskell.org/trac/**ghc/wiki/Building/ >> **CrossCompiling/iOS<http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS> >> > >> >> >> Steve >> >> ______________________________**_________________ >> iPhone mailing list >> iPhone(a)haskell.org <mailto:iPhone@haskell.org> >> >> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >> >> >> >> ______________________________**_________________ >> iPhone mailing list >> iPhone(a)haskell.org <mailto:iPhone@haskell.org> >> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >> >> >> >> >> >> >>

2 8