Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
Hello all! I'm extremely happy to report (thanks to invaluable help from Stephen) that my issues were my own dumb fault : ) — I was using LLVM 3.0's Clang but not its llc or opt. With some other tweaks to Stephen's above patch[1], we now have a perfectly working GHC-iOS on OS X 10.9 Mavericks. Hurray! Cheers Luke [1]Stephen's work: http://ghc.haskell.org/trac/ghc/ticket/8125 http://ghc.haskell.org/trac/ghc/ticket/8126 http://ghc.haskell.org/trac/ghc/ticket/8127 On Mon, Aug 12, 2013 at 1:44 AM, Luke Iannini lukex...@gmail.com wrote: Hi all, I tried this — building GHC HEAD configured to use the native code gen, and then building the cross compiler using that, and got the same errors as everything else thus far: https://gist.github.com/lukexi/02366ed57171400b961a 10.9 Mavericks is likely coming out in less than a month, along with iOS7 and Xcode5 final, so it's definitely worth sorting this out! Not quite sure what to try next though... Best Luke On Sun, Aug 11, 2013 at 3:18 PM, Carter Schonwald carter.schonw...@gmail.com wrote: What if you build a copy of head with the native code gen. Then build the cross compiler using head on head? On Sunday, August 11, 2013, Luke Iannini wrote: And the truly final word for the moment : ) — I built a tool to partially automate the indentation workaround for LLVM 3.0 and it yields the same co-processor offset out of range/unsupported relocation on symbol LCPI65_0 errors LLVM 3.3/3.4 did when it finally gets to integer-simple/GHC/Integer/Type.hs. On Sun, Aug 11, 2013 at 3:06 AM, Luke Iannini lukex...@gmail.comwrote: OK! So just to summarize: Building GHC HEAD with LLVM 3.0 or 3.2 (using GHC 7.6.3 as the bootstrap) on OS X 10.9 DP5/Xcode 5 DP5 exhibits very strange behavior wherein layout-based code along with mixed-tabs-and-spaces code fails to parse correctly, with issues in hundreds of files in the GHC HEAD tree. I don't have a 10.8 machine to check if this is a 10.9 exclusive issue, so I'd love if someone can try using these binaries to build GHC HEAD: http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz Building GHC HEAD with LLVM 3.3 or 3.4 works great as a regular compiler with the 10.9 workarounds I outlined in another thread, but fails when compiling as a cross-compiler (./configure --target=arm-apple-darwin10) with these errors: https://gist.github.com/lukexi/2b129f34fa027172c5ee So I'm between a rock and a hard place at the moment. The only (very tedious and slow) workaround I've found for the 3.0/3.2 bug is to manually expand tabs to spaces, and to transform do x y into do x y (similarly for where and let blocks) Cheers Luke On Sun, Aug 11, 2013 at 1:53 AM, Luke Iannini lukex...@gmail.comwrote: Argh, sorry for the confusion: 3.2 *does* exhibit the issue. 3.3 and 3.4 do not. On Sun, Aug 11, 2013 at 1:39 AM, Luke Iannini lukex...@gmail.comwrote: Further investigation: I grabbed 7.6.3 just to see if I somehow had a bad install of GHC, but the problem still occurred. The problem only occurs with LLVM 3.0. It is not related to cross-compilation or Stephen's patches: I tested this on multiple fresh clones with --with-gcc=clang. LLVM 3.2, 3.3 and 3.4 do not exhibit the issue. If anyone wants to try to reproduce, you can grab the LLVM 3.0 binaries here Clang Binaries for MacOS X/x86-64http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz and just drop them in your path. (Stephen, I'm now trying your patch with LLVM 3.2) Cheers Luke On Sat, Aug 10, 2013 at 8:11 PM, Luke Iannini lukex...@gmail.comwrote: The first error on a fresh checkout is /usr/local/bin/ghc -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.1 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hid ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Hoopl 3.9 not on hackage
Right - I made a lot of changes while working on the new codegen. Norman signed off on them (in principle at least) so it should be fine to upload the package. I should admit I did very limited testing outside of GHC's use case, and GHC even contains a copy of some of the hoopl code with its own specialisations (the core dataflow algorithm in particular). Cheers, Simon On 31/07/13 22:37, Simon Peyton-Jones wrote: No I think it's just oversight. Do upload it! thanks Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Thomas | Schilling | Sent: 31 July 2013 19:53 | To: ghc-devs@haskell.org | Subject: Hoopl 3.9 not on hackage | | 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Two Hoopl questions
On 26/07/13 22:56, Edward Z. Yang wrote: Thank you Edward. I am aware of these requirements - my problem is writing the code in which these will always hold (I'm optimizing Cmm and hand-written Cmm files tend to cause many problems that don't appear in automatically generated Cmm). Having a debugging tool in form of Fuel would be helpful for me, because instead of getting a freeze and seeing no output from -ddump-cmm I would see incorrectly transformed Cmm that would allow me to track bugs more easily. In that case, I would recommend taking a look at when -dopt-fuel got removed and seeing if you can put it back in. I quite liked this feature and it is too bad it is gone. Guilty. I got rid of the fuel (in GHC's version of the dataflow algorithm). I think removing it was worth a percent or two in compile-time performance - not a lot, but this was one of a whole heap of such things that I did to get the new codegen from about 100% to 5% overhead. I've no objection to the idea of optimisation fuel, but it should be an optional thing that doesn't cost anything if you don't use it. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Non-parallel version of GC
On 10/08/13 00:58, Edward Z. Yang wrote: How would people feel about an alternate GC implementation in GHC which is not parallel? A GC like this would be simpler to understand, maybe a little faster when parallel collection is not being used, and (most importantly for my case) easier to extend with interesting features. In particular, this implementation would not have gen_workspace or gc_thread; these would either be unnecessary or folded directly into the actual generation object. From my point of view I'd like such a thing to be as separate as possible from the rest of the GC code. However it might be hard to do that - you mentioned modifying the generation structure, for example. As with most things in the RTS, the GC is exactly as modular as it needs to be right now, which in practice means not quite modular enough for what I want to do next :-) So your first step might be to abstract some things so that the two GCs can coexist peacefully. But perhaps there's another way to achieve your goals - what are the interesting features you want to add? Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RTS option parsing
It's probably best not to rely on external libraries for this.
I'd be happy with representing the options as data rather than code,
along with a generic parser. Performance is very likely a non-issue,
but you could always do something really simple like bucketing the
options based on the first character.
Cheers,
Simon
On 10/08/13 02:54, David Laing wrote:
Hi Edward,
I was more worried about the effect that it would have on the 2nd tier
platforms, some of which don't have getopt_long_only - which I think is
desirable due to the two-character short options that need to be dealt
with.
My feeling is that writing and maintaining a correct getopt_long_only as
a fallback for those platforms - which I assume someone would have to do
- might take more effort than putting togther something less general /
more tailored to how the RTS parses the options.
I've been idly thinking about how to approach this problem enough that I
think I'm going to put some proof-of-concept code together just to test
the ideas / so my metaphorical teeth stop itching.
At the core of the idea is the options would be stored in an array of
structs of the form
{option-string, has_argument, is_safe, function_pointer_to_handler}
where the function pointer is probably of the form
int(RtsFlags*, some-error-info-struct*)
or possibly
int(RtsFlags*, some-cross-option-information-sharing-struct*,
some-error-info-struct*)
I've been in the C++ world for a while now, so I'll need to double check
the standard / idiomatic way to express that in C.
If options don't effect anything but the flags or the error state, it
seems to me that the overall complexity of the option parsing code would
drop. I don't know what the priority of option parsing performance is,
but there are quite a few optimisations available that wouldn't
complicate the code all that much.
If anyone has any thoughts on this, I'd love to hear them before I get
too far along.
Cheers,
Dave
On Sat, Aug 10, 2013 at 10:09 AM, Edward Z. Yang ezy...@mit.edu
mailto:ezy...@mit.edu wrote:
Hi David,
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.
That's not necessarily true; we target MingW for Windows compilation,
so if you can make sure it works there getopt_long may be viable. On
the other hand, maintaining backwards compatibility may be tricky.
Some investigation is probably necessary.
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Yet Another Hoopl Question
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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
HEADS UP! was: Re: New Git-commit-message - Trac-ticket interaction
Just in case there are other people (like me) who didn't notice this, the syntax for telling git that you want to update a Trac ticket in the commit log has changed. Read Herbet's message for details. I used to just mention the ticket number in the commit message blah blah (#1234), the new syntax for this is blah blah (see #1234). I have updated http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git to mention this, but it could probably do with more complete docs since the standard Trac docs don't take into account our local settings. Herbert, could you expand that please? Cheers, Simon On 10/08/13 10:57, Herbert Valerio Riedel wrote: On 2013-08-10 at 11:06:06 +0200, Herbert Valerio Riedel wrote: And finally, the changes resulting from the new Trac commit-hook integration is worth a separate posting of its own to follow shortly. The new post-receive hook for notifying Trac about new commits has been updated to use Trac's CommitTicketUpdater[1] One of the changes is the way commit messages are added to a ticket comment: - Previously, the commit message was put into a verbatim code block, as in http://ghc.haskell.org/trac/ghc/ticket/8121#comment:2 - Now, the commit message is wrapped in a code block using Trac's CommitTicketReference wiki processor which effectively interprets the commit message as Trac wiki markup[2]. This is more consistent with the way commit messages are exposed in other places throughout Trac and allows for proper Wiki and URL links in the ticket comment view. For instance, http://ghc.haskell.org/trac/ghc/ticket/8121#comment:3 As for *when* a Git commit is actually associated with a ticket: - Currently, only the 4 Git repos associated with GHC Trac (ghc,nofib,testuite,base; [3]) are scanned for ticket references. - Currently, only if a commit becomes reachable during a git push from the 'master' branch it gets scanned for trigger words. This is the simplest way to avoid duplicate commit messages getting added as comments to tickets (and avoid premature ticket closing).[4] - The ticket-referencing syntax explained below must be used, for the ticket reference to get recognized. To quote the documentation[1]: , | The basic syntax is of the form [command] [ticketreference]. A colon | between the command and the ticket reference is allowed. The | ticketreference also allows to list multiple ticket numbers separated by | spaces and/or comma. The word 'and' is also allowed between ticket | numbers. | | You can optionally refer to tickets with the following words | | ticket, issue, bug | Examples (note: not verified!): | | close #10 | closed: #10 | closes ticket #10 | closes ticket:10 | fixes #10 | fixes bug: #10 | see issue #5 | references #5, #6 | fixes bug #10 and #11 | | A fairly complicated example of what you can do is with a commit | message of: | | Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12. | | This will close #10 and #12, and add a note to #12. ` The command verbs currently recognized for referencing a ticket are currently: | addressing addresses re references refs see Trac ...and the verbs currently recognized for referencing *and* closing a ticket are | close closed closes fix fixed fixes Consequently, if you just write Fixes Trac #1234 in your commit (which occurs quite often in the git history), this will only reference the ticket but *not* close the ticket. If closing from commits is not desired or causes problems, we can move the close/fix verbs into the reference-only set of verbs and be done with it. If there's something you'd like to behave differently, please tell us. If accomplishable with reasonable effort, we're happy to implement it. The information from this posting may/should/shall/will be put on the GHC Trac Wiki as well for future reference. Cheers, hvr [1]: http://trac.edgewall.org/wiki/CommitTicketUpdater [2]: http://ghc.haskell.org/trac/ghc/wiki/WikiFormatting [3]: http://ghc.haskell.org/trac/ghc/browser [4]: Should the need arise, we can consider a more sophisticated approach can be used, which would consider commits in more than just the 'master' branch. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Non-parallel version of GC
But perhaps there's another way to achieve your goals - what are the interesting features you want to add? Yeah. The key thing I need to change is how the GC decides where live objects are evacuated to, to support a more efficient implementation of resource limits (think BiBoP for cost centers) where every user gets his own set of pages, and his objects are always evacuated to pages he owns. I don't know how to parallelize his, and even in the non-parallel case it requires quite a restructuring of the GC code. Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Yet Another Hoopl Question
On 13/08/13 13:03, Jan Stolarek wrote:
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?
Your transfer function is not monotonic, because each time you apply it
it gives a different result.
The next question is well how do I do this then?. I'm not quite sure,
maybe you need to use a deterministic name supply monad.
Cheers,
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Yet Another Hoopl Question
Forgive me for asking the classic question: What are you really trying to do?
Edward
Excerpts from Simon Marlow's message of Tue Aug 13 09:25:51 -0400 2013:
On 13/08/13 13:03, Jan Stolarek wrote:
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?
Your transfer function is not monotonic, because each time you apply it
it gives a different result.
The next question is well how do I do this then?. I'm not quite sure,
maybe you need to use a deterministic name supply monad.
Cheers,
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: NOTICE: Gitolite migration is complete.
What happened to the libraries repositories? ezyang@javelin:~/Dev/ghc-clean/libraries/binary$ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true [remote origin] fetch = +refs/heads/*:refs/remotes/origin/* url = git://ghc.haskell.org/libraries/binary pushurl = ssh://g...@ghc.haskell.org/libraries/binary [branch master] remote = origin merge = refs/heads/master ezyang@javelin:~/Dev/ghc-clean/libraries/binary$ git pull fatal: remote error: access denied or repository not exported: /libraries/binary Edward Excerpts from Herbert Valerio Riedel's message of Sat Aug 10 05:06:06 -0400 2013: Hello GHC Devs, Let me add some details and clarifications to yesterday's migration completion notice: On 2013-08-10 at 00:19:53 +0200, Austin Seipp wrote: Push access is now restored and Gitolite is in place! This brings some nice updates: * There's now access to the 'git' protocol for cloning anonymously. This lets you clone even the biggest repos extremely quickly, and is the fastest method for getting a copy of the tree. Consequently, if you are a developer (and not behind a firewall that filters port 9418) you should try out the following assymetric configuration: ./sync-all -r git://ghc.haskell.org remote set-url origin ./sync-all -r ssh://g...@ghc.haskell.org remote set-url --push origin This uses the unauthenticated low-latency git:// protocol for fetching repository data, and the authenticated encrypted high-latency ssh:// protocol for pushing into the GHC repositories. This setup has the advantage over using the GitHub GHC mirrors, that the fetch and push locations are really identical and never out-of-sync (e.g. if the Git mirroring breaks or lags for some reason) * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git, meaning it should be faster too! * We will soon have Gitweb available, once our git.haskell.org CNAME is in place. Eventually we'd like something akin to Small clarification: Smart HTTP Git transport is only enabled on http://git.haskell.org/; The legacy URLs at http://darcs.haskell.org/ are is still served dumbly. If you don't want to wait for the DNS CNAME entry, you can fake the DNS entry to point to ghc.haskell.org, e.g. by echo 88.198.224.241 git.haskell.org /etc/hosts (...and don't forget to remove that entry once the real DNS CNAME entry is in place) and then just point your browser to http://git.haskell.org/ The following people have had their keys re-added, and should be able to push and pull from the new setup. [...] You should all check your current permissions by invoking ssh g...@ghc.haskell.org info you should see something like , | hello $USERNAME, this is gitolite 2.3-1 (Debian) running on git 1.7.10.4 | the gitolite config gives you the following access: | @R W ghc | @R W ghc-tarballs | @R W git-sandbox | @R W haddock | [...] | @R W packages/unix | @R W packages/vector | @R W packages/xhtml | @R W testsuite ` Please make sure, *YOUR* username shows up in place of $USERNAME, to find out whether we mixed up your public keys. (See http://gitolite.com/gitolite/g2/info_expand.html#info, if you want to know more about the meaning of the output) Note: The current setup denies non-fast-forward and ref-deletion updates via git push. This will be relaxed once we reach an agreement over what the Git heads/tag refs namespace policy shall be (i.e. who is allowed to create/delete/non-fwd-update heads/tags (and which ones)). If you want to debug/test 'git push', feel free to push whatever you like to the 'git-sandbox' repository. Please direct any concerns to me, like if you need something off the server, need your shell account back, or need commit access. For technical problems with TracGit(olite) itself, please CC me as well; as I am in a different timezone from Austin, this may help reduce the response time for solving the issue at hand. Alternatively, you can also reach us on freenode's #haskell-infrastructure And finally, the changes resulting from the new Trac commit-hook integration is worth a separate posting of its own to follow shortly. Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Yet Another Hoopl Question
The next question is well how do I do this then?. I'm not quite sure, maybe you need to use a deterministic name supply monad. So why are Hoopl's rewrite functions specialized to UniqSM monad? My understanding so far was that this is precisely because we need access to Uniq supply to generate new labels and registers during rewriting. I'm guessing that nobody intended that these newly generated things will be added as facts? Forgive me for asking the classic question: What are you really trying to do? I'm doing copy (constant) propagation and one of my intentions is to minimize traffic to/from the stack when possible. Since I cannot propagate complicated_expr, I rewrite a store to a stack location with newReg1 = complicated_expr I32[(old + 4)] = newReg1 By recording second assignment as a fact it is now possible to replace references to I32[(old + 4)] with references to newReg1, which will effectively make I32[(old + 4)] = newReg1 assignment dead. So now information will be kept in registers instead of the stack. Of course it is still possible that there will be not enough registers and we'll have to spill some things to the stack. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Segfault on x86 with -O2
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Segfault on x86 with -O2
Kazu, What about 3e598fe0b01f4692f50c377ac91010040227e7ce in ghc? This was a calling convention bug that Geoffrey fixed. It looks like it is almost certainly the culprit. On Tue, Aug 13, 2013 at 10:14 PM, Kazu Yamamoto k...@iij.ad.jp wrote: 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Segfault on x86 with -O2
And just for the record, people reported this morning they couldn't reproduce #8103 anymore, and I'd bet this probably fixes that one, too. On Tue, Aug 13, 2013 at 10:17 PM, Austin Seipp ase...@pobox.com wrote: Kazu, What about 3e598fe0b01f4692f50c377ac91010040227e7ce in ghc? This was a calling convention bug that Geoffrey fixed. It looks like it is almost certainly the culprit. On Tue, Aug 13, 2013 at 10:14 PM, Kazu Yamamoto k...@iij.ad.jp wrote: 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671 -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Deriving clauses for EmptyDataDecls [was: request for reviews for my first patch -- ticket 7401]
On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg e...@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 e...@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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
